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 > [email protected] > https://www.redhat.com/mailman/listinfo/redhat-lspp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
