[redhat-lspp] LSPP Development Telecon 06/19/2006 Minutes
Ted
txtoth at gmail.com
Tue Jun 20 19:23:54 UTC 2006
Can anyone point me to a good source of information on namespaces in
general and network namespaces specifically. Are network namespaces
something that could be utilized through xinetd to get polyinstantiated
port functionality?
On Mon, 2006-06-19 at 19:20 -0500, Loulwa Salem wrote:
> 6/19/2006 lspp Meeting Minutes:
> ===============================
> Attendees
>
> Janak Desai (IBM) - JD
> George Wilson (IBM) - GW
> Loulwa Salem (IBM) - LS
> Michael Thompson (IBM) - MT
> Lawrence Wilson (IBM) - LW
> Thiago Jung Bauermann (IBM) - TB
> Nikhil Gabdhi (IBM) - NG
> Stephen Smalley (NSA) - SS
> Al Viro (Red Hat) - AV
> Steve Grubb (Red Hat) - SG
> Irina Boverman (Red Hat) - IB
> Dan Walsh (Red Hat) - DW
> Paul Sutherland (Red Hat) - PS
> Chris Runge (Red Hat) - CR
> Lisa Smith (HP) - LMS
> Linda Knippers (HP) - LK
> Amy Griffis (HP) - AG
> Matt Anderson (HP) - MA
> Paul Moore (HP) - PM
> Klaus Weidner (Atsec) - KW
> Chad Hanson (TCS) - CH
> Darrel Goeddel (TCS) - DG
> Venkat Yekkirala (TCS) - VY
> Bill O'Donnel (SGI) - BO
> Ted Toth - TT
>
>
> Tentative Agenda:
>
> Kernel update
> ==============
> GW: Al, if you can give us an update, that would be great.
> AV: Last week there were several fixes. 2.6.17 got opened this weekend.
> Today I have a patch series I hope to feed to Linus. That is pretty much
> everything that went on Linux audit and got into the tree, the only
> exceptions that I still don't want to push is the last patch from Amy.
> The only thing that won't go is filterkey, the rest will hopefully go in
> today.
> GW: ok great ..
> AV: once it is in the tree we are back into getting stuff into our tree
> first and then feeding it to Linux. only difference is now we have a
> deadline for major patches going upstream. Now we know when the window
> closes; and things that touch more than audit related files are
> particularly important to get in time.
> LK: when will the window be closed
> AV: Window should close in two weeks
> SG: I'll also roll a new kernel out sometime over night, also there was a
> patch that was sent by Andrew Morton on task watcher, it is touching our
> code. I don't know if anyone looked into what it is doing, but we need
> to keep an eye on it
> GW: I sent a note to Matt about that, asking if he did any work testing it,
> considering it was included with out an ACK from audit list. I haven't
> heard back from him yet. He is in Beaverton, hopefully will hear
> something this afternoon or evening, I'll let you know.
> SG: also I sent an email, but no response either. If it lands in 2.6.19,
> it's ok, but if it lands in 2.6.18 that will affect us.
> AV: We can live with that and we can work around whatever breakage gets
> introduced. I don't like it, I don't like the idea itself, but we'll
> see, at least it is localized.
> GW: Serge was worried about performance impacts. He said it is the first
> thing we need to do when we test scalability next.
> AV: For what it is worth, I suspect audit won't be main part of the
> performance impact.
> GW: what I want him to do is post additional information to list and get
> more debate. There is no debate as of now and no ACK. He might have
> taken your comments as an ACK, but it is not. He works in Beaverton, so
> we don't know him
> AV: I really don't like it. I wonder how it went into -mm. What this guy is
> trying to do is provide a way for 3rd party modules to attach to a task
> struct. if these guys are working with somebody like a bunch of
> anti-virus scam artists, that's where this sort of thing comes from.
> GW: like I said we don't know him and don't fully understand the purpose of
> his patch, so we need more comments and debate about this on the list.
> That's all I can do for it right now
> AV: Ok
> GW: I was gonna try to get him to this meeting, maybe next week.
>
> AuditFS/inotify completion
> ==========================
> GW: As best as I can tell, inotify is substantially complete minus the one
> patch that is not ready yet. We need to do testing, we recovered well
> from that. Anything else Amy or Steve you like to talk about
> AG: I don't have anything
> GW: thanks for hanging in there
> SG: Just to double check where we are now. One of the patches was to remove
> a watch where there was no audit record. When there is a task being
> watched and you add task to audit record, it isn't watched, and the last
> one is cleanup of child watches.
> AG: yes that is resolved. All are resolved except for one.
> SG: all resolved but the one that Amy is still working on, I need to go too
> and make the changes to audit as well to use the -k option.
>
>
> LSPP kernel issues
> ==================
> GW: Anything we need to discuss for lspp kernel
> AV: I Want to start doing performance testing again.
> GW: I'll see if I can get time with Jose. Also get a kernel with cache
> poisoning turned off.
> SG: ok, I'll turn debug off in the next kernel
> GW: Alright, now that I know it's coming, I'll schedule time for that. I'll
> make this a high priority item.
> SG: I need to update syscall mappings too, in 2.6.17 few new syscalls got
> added.
> GW: so we should expect new audit coming out soon.
> SG: Yes. later in the week.
>
>
> Audit userspace
> ================
>
>
> Audit failure action inquiry function
> ======================================
> GW: Lisa, anything new on the failure action inquiry
> LMS: I sent out a patch last week. I had a request to change the code to
> match the style and functionality in auditd.conf; I am working on that
> now.
> GW: ok, thanks much for the update.
>
>
> Print
> =====
> MA: I started using raster image format, it seems to be working well. I need
> to verify the header and footer banner images are applied correctly.
> Few concerns came up, the spool queue files are in SystemLow.
> KW: if you have a user space process in SystemHigh, then a process is
> downgrading the file, which process is doing that?
> MA: that would be cupsd
> KW: so cupsd has the override. I don't like it unless you have appropriate
> DAC. It's better if files stay at same level.
> MA: The problem I'm running into is it seems functions for manipulating
> contents take two different data types and it doesn't modify ranges
> separately. You can get into some weird situation were content wasn't
> really specified by policy
> KW: still need to do investigation. It makes things easier from a design
> perspective that you have small piece of code running in override rather
> than the whole of cupsd
> MA: you can have small program that does that as another solution
> KW: if you don't have MAC override, the files couldn't end up in SystemLow.
> So something is happening to downgrade them.
> MA: cups doesn't have the MAC downgrade in its policy, it is only creating
> files and dumping data in them
> KW: This looks like another problem then, need to have easy way to do that
> MA: Well, I need to put it in enforcing mode then try that
> KW: can be that it is working now because it is not in enforcing mode, and
> might not work in enforcing
> MA: another thing is the lpq?
> GW: shouldn't see jobs you dominate.
> KW: you shouldn't be able to see job info you don't have access to
> MA: the queue files are not queried to see what jobs are there, it is only
> coming from cups memory
> KW: you should not be seeing any file names for print jobs you don't have
> access to
> MA: is this a good way to determine dominance on things
> SS: [missed this part]
> MA: I want to do string compare, and wonder if I need to query policy to do
> that.
> SS: [missed this part]
> MA: I can look at that
> SS: there is a number of user programs instrumented to get those checks
> DG: I think we have something similar used to device allocator.
> MA: fundamentally they are all similar types of access
> SS: you might want to segregate the services, whether you want to do that
> based on target contents or not, I think we need the drill down more on
> this to figure out the specifics
> MA: Well .. generally, I still need to implement some dominance checks for
> lpq. Other than that, things look good
> GW: where do we want to resolve the dominance issue, on the list, or talk it
> out here?
> MA: I need to look into device allocator stuff and see how it fits with
> cups, I'll look into that first and then post on list to start a
> discussion on this.
> GW: I am also hearing we need to try this in enforcing mode and see what
> happens
> MA: If we are having a separate program do the actual downgrade then it
> shouldn't be a problem
> LK: but I think it's a good point to test in enforcing mode, we should be
> doing that by now.
> GW: Yes. It's painful, but we are doing it here too, and it's the best way
> to flush out bugs.
> MA: the printer I am using now is running enforcing, but been having
> problems.
> GW: We also have an intern who will be testing this stuff in near future ..
> Fernando, he is not here today, but he will be testing this soon ..
> alright .. thanks
>
>
> SELinux base update
> ===================
> GW: I don't know if Dan is on, is there anything we need to discuss about
> selinux?
> DW: I'm here. Major development is figuring out how to work on new roles.
> Came up with the webadm, httpadm user role. Someone on fedora now is
> attempting to build a backup role. As we play with these roles, we're
> gonna find limitations; surprisingly it's easy, we can create a webadmin
> role.
> GW: glad, we needed that badly, to know that we can do that. Have you tried
> the dominance operator
> DW: no
> GW: I didn't try it in a while either .. the last time I did it was broken.
> DW: stephen you know if that works
> SS: didn't know it was broken
> DW: one problem with adding new roles, we will have to add additional types.
> The more roles are added, the more types are added and the more
> complicated the policy becomes.
> GW: The question is how is your level of tolerance
> KW: As a side note, why not use groups to edit config files? Not necessarily
> you need roles to do that
> DW: we need root privileges but only on certain groups of files
> KW: give files to appropriate group and use ACLs on them. You can restrict
> root roles to things the need the root override. Thanks for looking into
> this. I posted response about the RBAC requirement question, I am
> looking into more flexible ways to do that.
> DW: I came up with my own response to that as well simultaneously.
> GW: to what extent can we prevent it from tainting main policy. we assume
> non malicious admins. This is more a question of what do RH folks want
> to support, what is your tolerance level?
> SG: Really, we are not in a position to answer that I think
> GW: This will decide how we can use this flexible mechanism. I was actually
> composing a post about what klaus said. I don't know the extent to how
> we can isolate it to make it acceptable to RH.
> DW: we are treading on new territory here. I'm not sure who'll make the
> decision on this, it's a difficult problem. if you ship with policy, and
> it breaks, it'll be hard to figure out what went wrong if user is
> changing things too.
> KW: would there be something like a tool that can check if you are only
> using permitted constructs to make sure you are not breaking something a
> system depends on
> DW: there is something like that
> KW: if you add a policy module, is there a way to check that you don't break
> any of existing constraints.
> DW: you shouldn't be able to get around constraints, but you can add
> modifications
> KW: can you ensure that any constraints in place will remain active
> SS: semanage has ability to run verifier program to do that. you can write a
> checker to do that. you can do those checks .. strongly enforcing them
> requires use of the policy manager that is coming soon.
> KW: are there documents or examples about how these checkers work
> SS: not really.. we can talk about it more on the list
> GW: I think we need to do that quickly. I remember you mentioned semanage
> when we were looking at integrity of policy.
> SS: not sure if that is necessarily useful for your focus, cause you are
> concerned with MLS, and modules can take care of type enforcement (TE).
> KW: if we are sure that the modules will not mess up current constraints,
> then we are ok for certification purpose. MLS constraints that specify
> what people can/cannot do must remain the same
> DW: you saying you can't change constraints but can add capabilities to
> existing types.
> KW: yes
> DW: I don't see how you can change constraints on a loadable module, Stephen
> you know?
> SS: I have to check on that
> GW: as long as they further restrict, we can make an argument. Ok that might
> not be as bad as it originally sounded. Now that we scoped the work, it
> maybe easier for decision makers to make the right decision
> KW: other part of that, make sure people don't modify existing roles, but
> add new roles. This greatly helps in debugging as well
> GW: yes. if you can crisply draw a line, it makes it easier.
> DW: One more thing, I've been working on device allocator, sent out patches
> last
> week. Few things to make it acceptable to fedora extras. The problem is
> it doesn't build on i386.
> CH: we incorporated your patch
> DW: I am at 5.4, I'll reissue this patch for 5.5
> CH: sounds good, we'll get that put in
> GW: anything else Dan
> DW: I've been having discussion with Michael, regarding testing roles. He
> wants to use scripts to run tests, and they need to be accessible by
> many users. I showed him how to do that.
> MT: I haven't actually experimented with that yet. Is there a type that
> everyone can read.
> DW: bin_t is closest one that allows you to do that
> MT: as far as I know the test code doesn't have to be secure.
> DW: yeah, use bin_t.
> CH: I think there is a 5.6 for the device allocator
> DW: ok, I'll base on 5.6. and resend it. I'll be gone for next two weeks to
> Florida for vacation.
>
> MLS policy issues
> =================
> Roles
> =====
> CIPSO
> =====
> GW: anything on cipso
> PM: Everything is on the mailing list. There is a headache on how to deal
> with accept, I posted what I think is a reasonable solution to that.
> SS: did you look into what Venkat posted?
> PM: When do we need to start worrying about the labels. Because of where LSM
> hooks are, it's easier to do things and only be concerned with where
> things are at. worse case is you'll go ahead initiate a tcp connection,
> do handshake, both sides start talking, but once you start talking you
> then get errors saying "hey, I don't like this MLS label" .. this is the
> path of least resistance to get this into kernel.
> SS: I think the other way is better, but probably more invasive.
> PM: that's my concern, it'll be too invasive and the network people won't
> like that.
> VY: I'm going to get a patch out tonight.
> SS: At what point is the stuff going to show up on netdev
> VY: I think this time I'll include netdev as well, unless you don't think I
> should
> SS: I think it's reasonable to put them on netdev now, and get wider
> exposure
> GW: Venkat, did Serge ever contact you?
> VY: yes, and he sent me the transform user patch, and I'll include it
> GW: great.. didn't know if you were in touch, hopefully that was helpful
> VY: yes .. it was
> GW: Joy is unavailable now .. she is away on personal business and is
> unreachable.
>
>
> IPsec: MLS, UNIX domain secpeer, xinetd
> =========================================
> GW: Catherine posted the secpeer unix domain patch, few comments but pretty
> good to go. As far as xinetd goes, Joy was going to incorporate the
> comments, but Steve I believe you wanted to change parts of it yourself?
> SG: yes, I've got about half of it changed to conform to what I need. My
> goal this week is to get the patch that trent posted to conform to the
> style then visit irc logs between Joy and I to get those things we
> talked about in place
> GW: thanks for taking that on Steve.
> SG: also seems like I have one minor patch to add to ipv6. You want me to
> post patches to the mailing list, or just put daemon out to rawhide.
> GW: whatever is easiest to get it out to community
> TT: I like to see it
> GW: yes Ted mentioned that issue of polyinstantiated ports
> GW: I thought we'll use something out of iptables that will remap on the fly
> to a real port
> GW: yeah, I remember that now ... about 6 months ago we talked about it.
> James talked about it then. I can dig that up.
> SG: that was my recollection that we were gonna tackle it through iptables.
> not sure if secmark was gonna handle it.
> SS: I thought the port redirection was what we will use. haven't the TCS
> people used that.
> GW: I'll dig that discussion. Ted you can live with that, or you need the
> polyinstantiation ports?
> SS: Is anyone watching the network name spaces work going on?
> GW: I haven't looked at it, or talked to Serge about it either. I'll talk to
> Serge about it
> TT: as long as it gets on the radar I'll be happy
> GW: I'll try to dig that out, and repost something about it.
>
>
> ipsec-tools: SPD dump and racoon base + MLS
> =============================================
> GW: I understand this will end up as a patch in rawhide since IPsec tools
> are BSD centric.
>
>
> Device allocation
> =================
> GW: Dan said he made some patches to device allocator, anyone has anything
> else?
> SS: I just looked at the code for that, and it is doing process_get_attribute
> check for some reason. Either way it is fine depending if it is caching
> results. This is more directed to people doing cups work.
> MA: ok, I'll take a look at that
> SS: is TCS maintaining that
> CH: yes we are maintaining that.
> DG: you think we need a class for device allocator. We need a translation
> daemon to be put in there.
> CH: the checks in device allocator right now are very convoluted things. It
> relies on things like policy to be there ... we should definitely look
> into getting some classes in there. you know what the work is like to get
> classes into user space
> SS: right now we are still in a mode were you need a patch for that.
> GW: any other device allocator issues?
>
>
> Self tests
> ===========
> GW: I need to get the self test done. I'll commit to have new iteration of
> that by end of week.
>
> VFS polyinstantiation
> =====================
> GW: Janak, anything for polyinstantiation?
> JD: Nothing major. for pam namespace, I posted a patch to redo some work to
> get X working, I updated man pages and put example to get gdm working. I
> posted a patch, and there were some spelling mistake comments from Tim,
> I fixed those. If people can give it a try and let me know. it is in
> rawhide, except for the last patch, you would need to get the rawhide
> stuff, then apply the last patch.
> SG: I got an email from pam maintainer, he'll be unavailable for Wednesday
> and Thursday, so it won't be until then before it gets in rawhide.
> GW: so cron is in rawhide?
> SG: that's different. Regarding that I talked to Jason and he is re-working
> vixie cron, but he is concerned about the patch being invasive, he'll
> look into it when he gets back, but If we want I'll build a cron and put
> it in the lspp repository so we can test it before he gets back and we
> can flush bugs before he is ready to merge. I'll go ahead and put out an
> iteration like I do for lspp kernel so we can test it.
> JD: ok, one of our QA guys will test it as well.
> SG: unfortunately Jason has been working hard on vixie cron, and his
> reservation is that alot of code is written to the old code, so he has
> to remap it.
> JD: tell him to contact me, and I can help him merge it with new code.
> SG: meantime, I'll build it and put in repository
>
> GW: Any other issues? ... ok .. kernel work needs to go into 2.6.18. we are
> making good progress, and we just need to keep pushing to get the last
> bit in. Thanks everyone, let's adjourn the meeting.
>
>
> Approximately 90% complete, 80% upstream
> All kernel work needs to be in 2.6.18
> Remaining tasks.
>
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
More information about the redhat-lspp
mailing list