[redhat-lspp] LSPP Development Telecon 06/05/2006 Minutes

Loulwa Salem loulwas at us.ibm.com
Tue Jun 6 19:41:28 UTC 2006


6/05/2006 lspp Meeting Minutes:
===============================
Attendees

    Matt Anderson (HP) - MA
    Amy Griffis (HP) - AG
    Steve Grubb (Red Hat) - SG
    Chad Hanson (TCS) - CH
    Linda Knippers (HP) - LK
    Paul Moore (HP) - PM
    Loulwa Salem (IBM) - LS
    Al Viro (Red Hat) - AV
    Dan Walsh (Red Hat) - DW
    George Wilson (IBM) - GW
    Janak Desai (IBM) - JD
    Klaus Weidner (Atsec) - KW
    Darrel Goeddel (TCS) - DG
    Venkat Yekkirala (TCS) - VY
    Michael Thompson (IBM) - MT
    Irina Boverman (RH) - IB
    James Antel (Red Hat) - JA
    Lawrence Wilson (IBM) - LW
    Lisa Smith (HP) - LMS
    Fernando Medrano (IBM) - FM
    Nikhil Gandhi (IBM) - NG
    Trent Jaeger (PSU) - TJ

Kernel update
=============
     Gw: Now that AL is on call. Al would you like to give us an update about
	what is going on with the kernel?
     AV: Most of this stuff is in -mm tree. It became possible after Andrew took
	Amy's patches. Most recent updates as soon as they get testing in lspp
	kernel, they are going to -mm as well. 2.6.17 is still not open and
	there are still rather unpleasant pending issues.
     GW: Is that the bug cleanup that might happen
     AV: We may have potential sec problems, and we might or might not have
	fixes, may or may not have fixes in 2.6.17. Then the decision is up to
	Linus, he might decide to release without those and apply fixes after
	release. Hopefully it will be fixed by the stable series. May decide to
	put them into tree before fix, which means giving it time to stabilize.
	Right now it's rather indefinite so I don't know. Too much depends on
	what Linus decides about delaying. There are reasons to delay, on the
	there hand, they may not be considered sufficiently serious to hold.
	It's embargoed, can't discuss.
     GW: sure we understand that
     AV: In general we are on track getting things into -mm. The longer it takes
	to release 2.6.17 the better. After it is released, stuff in -mm will
	probably go in a week or 2. Then we better hope the rest of our stuff
	will remain in kernel audit and friends; probably it will.
     GW: sounds pretty good. the networking stuff is not confined to audit. You
	must have seen the IPsec patch it is pretty invasive ...
     AV: what do linux folks say about it?
     GW: Stephen says unless something quick happens on it, it is not small
	 enough to make 2.6.18. It's public and needs to be reviewed.
     VY: I only sent out the patch to few people. I'll have it to lspp and maybe
	net list. I was trying to get initial feedback. Based on feedback so
	far, I'll clean it up and send it out on lspp and net dev this week.
     SG: I want to reiterate, we need to get it into 2.6.18. if it is not there,
	it is not guaranteed to get in Rhel 5
     CH: Those secmark changes desired to be used in rhel are different to what
	they have been previously.
     GW: Stephen was talking about everything using that mechanism as well, but
	it's a lot of work. We came to the conclusion that it is in fact going
	to be enabled in rhel5, secmark that is.. right?
     SG: probably, see how it goes upstream
     GW: can we operate outside of it, things like local protection. This throws
	a big change very late in the game.
     LK: if it doesn't go upstream, would RedHat(RH) carry it in a patch?
     DW: don't know?
     SG: don't know?
     LK: I'm curious to know what would RH do if it doesn't make it upstream?
     GW: there is a ripple effect, you and I Linda see that. the later we do that
	the more we jeopardize our end date.
     SG: well delay is part of the product plan, and it's a moving target.
     KW: as a side note, I saw a note that rhel5 will be delayed until Xen is
	finished.
     DW: we think of Xen as the guiding light for RH, if Xen is not working we
	are not shipping.
     SG: James is working on secmark patch, he intends to push it upstream on
	2.6.18. not sure how successful he's been, but it's his plan as far as I
	know.
     GW: I did want to touch on several of these issues later in the call as
	well.

AuditFS/inotify completion
==========================
     GW: So regarding auditfs/inotify work, any updates Amy?
     AG: It's going pretty well .. inotify patches were pulled into -mm kernel
	last Monday, so they are getting more testing. also been acknowledged by
	the inotify people. Things are looking good for merging with 2.6.18. for
	audit stuff, I've been stabilizing it to go into -mm, I don't think it
	is in yet. last week I posted fix for missing audit records for deleting
	files/directories. Also fixed a bunch of other bugs. I am now working on
	adding code for getting records for directories. What I have left is
	filterkey and map operations.
     GW: Great .. thanks Amy for hanging in there, continuing on with this work
	and seeing it to completion. We need to continue testing on kernels. Is
	Al on yet? Ok, well if anyone has issues please bring them up on lspp
	list.
     SG: I'll be putting out a new kernel tomorrow. lspp.35 should have the patch
	amy talked about, and Al also has some patch that he added. it's based
	on the more recent rc5.git11.
     GW: good, we'll get some test time on that. I was gonna post Jose's
	performance results but they were not interesting. He didn't do a
	profiling run, he just tested and determined the problem was fixed. I'm
	trying to set up some hardware for him and get him to do more profiling
	runs.
     SG: I think it would be interesting to check and exercise the filesystem,
	see what results we get when the watch system is active.
     GW: I can post the results if you like to see them, but they were not as
	detailed as I want . I'll wait for something more meaningful and post
	those.
     SG: Also see performance for disk access during a match to see if some
	function calls are not needed. This happened to us before with selinux,
	so it would be nice to see if we are doing the same thing now.
     GW: that kind of thing can help sanity check we are doing the right thing.
	I'll get some time on a 64-way to get some results. what kernel do I
	need to run. Cache poisoning is on since .27 right?
     SG: I'll need to provide you with a kernel for that, maybe let the .35 run
	for a day or so.
     GW: Ok, I'll get a run scheduled
     SG: Do we know what kind of hits we have with labeled networking.
     GW: Joy did some bench marking for that. I thought she posted the results on
	the list. she was looking for useful tests to test the scalability. She
	also looked at performance with regards to nodes. Joy is back now, so
	hopefully Thursday she'll be back in the office. I'll ask her, see if
	she can post the results.
     GW: I have one more memory leak that I intend to work on. should hopefully
	be the last thing to do on that

LSPP kernel issues
==================


Audit userspace
================
     GW: Steve, anything new with audit?
     SG: I'm taking care of the null filename issue we discussed on the list a
	long time ago. Also there were 1 or 2 patches from mike that I merged. I
	 might put another one out towards end of week.

Audit failure action inquiry function
=====================================
     GW: Lisa, how is audit failure action inquiry going?
     LMS: doing well. I ran into problems with netlink not available when we get
	errors, and that's what I need; so I'm back to my design to use user
	space config file in order to use the tunable.
     SG: Just curious, what program couldn't read the netlink?
     LSM: No one in particular. When I go to get the tunable, I need the
	netlink, and it is not available for the query function
     SG: but you do get a well defined ERRNO if kernel compiled without audit
	support.
     LK: but it is when audit is in the system
     LSM: I still couldn't get the tunable value.
     DW: if you can't audit how you would respond. is that the tunable you are
	asking about?
     LSM: right
     LK: if you can issue and audit record you can read a file in directory. I
	think it could be a policy issues.
     SG: the ability to issue an audit record?
     GW: are you also gonna have issues with the MLS policy
     DW: all you need is support ability to access the file. but the netlink
	concern is more related to kernel. it's a performance query
     GW: if netlink is toast, we are toasted anyway.
     LK: depends on which netlink socket is toasted, we can't issue an audit
	record.
     GW: seems like this is a case where you should give up
     SG: you wouldn't stop the program... just decide on the action
     LK: we decide if we need to halt the system
     MA: we should be able to access one file
     SG: we can move audit config stuff to an /etc audit directory.
     DW: make it world readable. The problem of moving it to audit directory is
	that it adopts permissions of the directory which is currently readable
	by auditadm only. Put it into /etc instead.
     KW: would it preferred in /etc/security
     DW: not really. is this an MLS thing?
     LK: not really .. not even CAPP.
     KW: If audit is not running, then certain programs will not run
     DW: that's when the login program would stop working for example.
     AG: we need to go one way with audit failure. Because of the packaging for
	Rhel there might be people with audit who don't want the system to fail
	for some unforeseen reason if you can't audit.
     Dw: I think you don't want that at all
     KW: what CAPP says, the intention requires options to fail if audit is not
	working, but not necessarily it is the only option.
     DW: put the option in audit.conf
     AG: we'll discuss this further on list
     GW: are we happy with having it in /etc?
     LK: No one seems to mind.



Audit of service discontinuity
==============================
     GW: I think this is already taken care of. Wait, no, this is where we need
	audit record when init is not around.
     DW: there is no audit system when init is starting up
     GW: there is a requirement for system discontinuity to be audited. this is
	almost like early boot message capture thing
     SG: we need to get messages, how do we get this through the kernel? We need
	to get init to put a message out.
     GW: This is the only place left we need audit message as far as I know. Is
	there a message in syslog now when it fails.
     DW: yes
     GW: I wonder if that is enough to meet the requirement
     DW: if selinux is in enforcing, it crashes the system. if not enforcing, it
	sends out a message.
     KW: we only care about enforcing. we need it to be in audit log, syslog is
	not audit so it's not enough
     DW: it sends message saying that " it can't load policy and halting system"
     GW: So it gives user an informative message about what is happening, but
	just to syslog.
     KW: when you get a fail in system operation, and you can say at this early
	stage in booting, it is not really operating.
     GW: I hear that we can remove this item off the list. we'll argue that the
	system is not really operating at that early point.

Print
=====
     GW: saw your patch Matt.. thanks.
     MA: I should also have sent a .spec file. the src.rpm will build correctly
	and had to create additional file that wasn't there. I  need to do a
	.spec file update and fix that bug. I want to test with usb printer.
	I'll will send new version to list. Hope to have it out to the list this
	week. I got a message from IBM that someone will start doing some
	testing as well.
     GW: that would be Fernando.
     FM: Yes.. I started looking at the cups daemon for testing.
     JD: are you updating man pages Matt as well.
     MA: We need to do that, but I haven't gotten to any documentation. anything
	specific you care about?
     JD: Well, besides being useful to the testing team, I was looking from a HLD
	perspective. Send it my way if you have something. otherwise one of our
	guys will go through your patch and write stuff up.
     MA: the programs are the same mostly. The place of most docs changes is in
	the cupsd man page. Mike you on the call?
     MT: yes
     MA: system group or auth class is what you need to modify in your file.
     MT: if it is working for you, then I might have changed my file wrong
     LK: Probably it is a good idea to clarify and configurations and identify
	those issues
     MA: I'll roll those up this week
     GW: have you tried it with dev allocator
     MA: Not specifically. dev allocator is on my system, but they don't seem to
	collide with each other
     GW: great .. thanks... I appreciate your work on this patch Matt.

SELinux base update
===================
     DW: I was at RH summit last week, so most stuff is still in the works as dev
	allocator is getting updated. I will push this week to get this all
	done, and will answer this question better next Monday. I also need to
	know why they are ignoring dev allocator, need to start yelling at
	someone.
     GW: ok, I hate to be at the receiving end of that :) .. thanks Dan.

MLS policy issues
=================
     GW: Michael you had some questions about the policy?
     MT: Yes .. the definition between sec and sys adm somewhat settled down. I
	sent email to you Dan about different utilities, did you get chance to
	see that yet.
     DW: looking at it right now actually. I'll respond to the email. Most are
	correct, most the restriction are on the target not the application.
	we'll try to break it up more that way. Is this something we need
	documented?
     MT: if we can solidify that and post somewhere, I'd like to do that for
	testing purpose
     DW: I'll look through your list, and make changes and clarifications.
     MT: I think we are on .43 version of policy now. so my list is outdated, but
	as long as we have the main issues resolved.
     DW: certain applications will blow up otherwise it will run. I mean this is
	different than roles based access where you can't run at all.
     MT: that's what the email is about, regarding roles mostly
     GW: If no more issues with MLS policies, let's move to keyring


Restriction of kernel keyring
=============================
     SG: there has been alot of work on NSA mailing list.


CIPSO
=====
     GW: CIPSO went in and out of kernel. Paul any updates on that
     PM: I am still working on it. James and Steve sent comments. I put James
	comments, and looking at steve's comments
     SG: out of curiosity is it on track for 2.6.18?
     PM: you tell me Steve. I keep posting, and I'm getting lots of comments, but
	I feel alot of peoeple need to approve this. I am not experienced in
	this process
     SG: I think you'll find it's an iterative process, you keep posting and
	fixing
     PM: that's what I've been trying to do.
     SG: people will keep testing, and see if major issues happen. I think we
	need a patch sometime this week to put into a build so we can put it
	infront of poeple again.
     PM: as far as syscontrol variable I can throw that in again, but I think
	here is another solution. I can change that and push a patch out
	tomorrow if you want. there are more changes, but if you want it fast, I
	can put in temporary fixes.
     LK: let's get a version running in the lspp kernel.
     SG: at least fix the capability checking.
     PM: then that's not gonna be tomorow
     SG: should be a a small patch
     PM: might be .. but I havn't looked at it. if you want a temp fix for lspp
	testing it's fine, but I don't feel comfortable signing off on that as
	final solution for upstream kernel.
     SG: I'll build a kernel with Amy's latest changes. then I'll build another
	one with your changes. so if something breaks, we have someting to fall
	back on. Also too many changes makes it hard to debug.
     PM: I'll send it to lspp list tomorrow. if I run into problems I'll send an 	
	email and let you know.
     GW: great. we like to try it as well.


IPsec:  MLS, secmark, UNIX domain secpeer, xinetd
==================================================
     GW: Trent and Venkat are on the call. First item is the MLS patch. There has
	been comments and Venkat will post to public list. We need it out to see
	the light of day. Joy posted some comments, looks like it needs to be
	broken up, and needs to go to net dev. how can we fast track it, get
	review and comments so it is acceptable?
     VY: I'll break it into small patches and get it out in the next couple of
	days
     GW: can RH give some help in getting reviews .. how hard is it to get James
	time, he and maybe Herbert?
     SG: This is the ipsec patch? James thinks that Trent is reviewing it.
     TJ: it looks reasonable, but we need Herbert to look at it. We seem well
	along with the patch so Herbert needs to be brought in soon
     GW: can we get some of his attention Steve?
     SG: if it is in public, I'll have something to point to
     GW: ok, so Venkat needs to post it, then you can bother Herbert a bit
     SG: the de-compisition is important, how do you plan to de compose it?
     VY: I'll look through the docs for submitting patches, and it'll be more
	like an official patch when I get it out.
     GW: We will be hard pressed to make the date, but we'll keep pushing.
     GW: I saw that katherine posted patch to do delete authorizations, we need
	one more patch to do the datagram. Thanks Trent for working with her to
	get those authorization.

ipsec-tools:  SPD dump and racoon base + MLS
============================================
     GW: how to integrate the ipsec labeling with sec mark. we seem to have large
	question marks here
     KW: feedback from users planning to use the system would be useful here
     GW: get feedback from UTCS.
     PM: one question about secmark it does not address outband issues. I suspect
	ipsec must have same issues
     VY: I sent an email about that, solution to fix this is to prioritze the
	outband, and use outbound rule as a filter.
     PM: I saw your email. I like the seperation of labeling. There is more work
	to be done on outbound side than that. for CIPSO and RIPSO, you need to
	attach IP action, and I don't see that happening.
     VY: can you elaborate on that. are you talking about outband traffic?
     PM: I'm attaching IP action to socket and that is not something secmark
	makes use of. Relying sololy on secmark field is not enough
     DW: instead of populating that with content of IP table, we would
	prioritize. We can modify that on way out.
     VY: where in the outbound currently should the check happen?
     DW: let's put this discussion on list. Stephen is on vacation now.
     GW: we'll have a fair ammount of discussion to get this done. Moving to
	xinetd. Trent's student posted a patch, but it is not up to the way
	xinetd operates.
     SG: xinetd has option on how to tell daemon to reject packet. there are 2
	sets of config options how to reject connection and how to set up
	environment. admins should have control over ranges of what to allow
	connection.
     TJ: independant of selinux policy?
     SG: traditionally xinetd has capability of discriminating connections on its
	own.
     TJ: so you don't mind redundancy
     SG: no, we don't want people to modify policy
     DW: can we have it go to different application based on if it came as system
	high or system low.
     SG: that's how xientd should be, the kind of thing I am looking for. Maybe a
	config option in file to help identify which server to go to.
     GW: you suggesting we have different definitions for servers
     SG: yes, for xineted you can have 10 definitions for ftp for example, and
	you can decide which one to use. there are 5 differnt options that help
	it decide which server to invoke
     GW: this is a different model than what we were thinking of.
     SG: right, if it doesn't find match, it rejects connection. You could have
	separate daemons for system high and low. What Dan suggested would work
     GW: so you want the selection criteria to be the inbound label?
     SG: yes that is what I am looking for.
     VY: how would a child socket that get created get labeled as secret for
	example.
     TJ: the invoked process will have a context that will be at that level
     VY: by that time the child socket would have been created right?
     SG: xinetd has two sockets for listening and accepting. I think the
	listening one might be set at a range.
     TJ: not sure that is handeled correctly yet, but you would set the socket
	level.
     VY: I mentioned that in emails to Trent I believe. we want the label to be
	at same level as incoming connection. I can send a patch.
     TJ: that would be good.
     SG: I am looking at xinetd code, seems like we want something there to help
	have the socket at the right level. also looking at the environment
	options. We need to change on how it makes the transition to the right 	
	type and level. I didn't look deep into the patch sent in April, is that
	the one that checks the level of the process after the fork?
     DW: so is it doing set_exec_con?
     TJ: yes.
     DW: wouldn't you need to set the level as well.
     TJ: we were only doing it with TE labels. Did joy try with MLS labels?
     GW: I beleive she did, but I need to check with her for sure. I saw her try
	it with TE and saw the child get the right type. Are you volunteering to
	fix those things Trent or we need to find someone to fix that.
     TJ: I don't know where my student is now, and I'll be traveliing, so better
	to find someone and we can communicate.
     GW: Joy will be back Thursday, I'll ask her see if she can do it.
     SG: and if she needs anything or questions regarding xinetd, she can ask me
     GW: looks like ipsec tools dimished in priority regarding upstream. don't
	know if Venkat has a patch that you want to send to RH.
     VY: We have something but it is not upstream ready
     SG: just noting that kernel deadline is before userspace deadline, so we
	have some time for userspace.
     GW: In that case we may have time to discuss the patch and work it out. if
	you want to share the patch, maybe someone can help too.


Device allocation
==================
     GW: We already heard from Dan about that, and he is following up on that.

Self tests
==========
     GW: I need to get back to that. I have been busy with hardware setups
	lately, but I'll get back to this.

VFS polyinstantiation
======================
     GW: Janak, any developments with this?
     JD: pam namespace is sent again. I fixed comments, and resent it. I changed
	the manpage, and added reference to shared sub tree. Last time we talked
	about it we were gonna put it into fedora rawhide. Dan if you can get
	that in fedora, we can use it and test it. As for cron, I havn't heard
	anything
     SG: I taked to Jason Friday, he is gonna look into it this week, it is on
	his to do list
     DW: on the mount patch, the developer said he is looking into it. With
	regards to pam namespace, is there any movement on xwindows?
     JD: I added a section on man page on what people need to do to use gdm, and
	polyinstantiated /tmp. if you don't want to polyinstantiate /tmp, then
	gdm needs one change in the config that I talked about in the man page
     DW: did you look into bind mount stuff
     JD: I looked into that, it doesn't work since socket has already been
	established under different name space.. only way to do it is to  move
	that dir; but when you log out and log in .. it is not set up properly,
	and I couldn't get it set up through the scripts
     DW: I'll play with it and make sure it all works with Selinux.
     JD: if you see anything else that you want me to try, let me know.


     GW: to reiterate .. as Steve mentioned earlier ... all code needs to go into
	the 2.6.18 kernel. Any more issues anyone needs to bring up?
     LK: I sent an email about the RBAC roles.. we need to talk about that on the
	list, and maybe discuss it next week.
     GW: we talked about that, we need to use policy module
     KW: maybe question for RH. if admin uses policy module, would that
	invalidate the certified criteria
     DW: ???
     KW: but you don't automatically consider something unsupported for that 	
	module.
     DW: same analogy as a kernel module.
     GW: but in this case it wouldn't be a random policy module
     LK: you are assuming this is a requirement and we have to do this
     KW: intent of RBAC is to have roles, and you might be able to squeak by
     GW: our initial intent was to squeak by. so the question is a configured
	system if you go add another role to your policy
     KW: would it be possible to have limited way to have roles added, or is it
	once you change anything then all bets are off.
     DW: my perspective is that it is not a problem. I don't want to make
	agreements for RH, but it shouldn't be a module that will break
	something.
     KW: users can still get support for their system even after creating few new
	roles to the policy
     LK: what about modifying an existing role?
     KW: it is reasonable to tell users not to modify roles, if they want a
	change, then add a role for that.
     DW: as far as the dominance stuff, I know it was broken, not sure if Tresys
	fixed it.
     KW: you should let admins creat new policies, otherwise all bets are really
	off.
     LK: is Irina still on the call?
     IB: yes.. let's put this on the list and discuss it then decide on it.
     LK: george and Klaus, will you post your thoughts on the list
     GW: yes we will, we also will check on the dominance operator.
     DW: we need to find these issues early since that is what people will be
	testing
     GW: I agree, we need to take action on that.
     LK: we also have the tools
     DW: modifying policy is difficult so that's why we need the tools
     KW: Need general audit record saying people changed policy
     GW: we don't have a diff mechanism, so we can't tell if policy changed
     SG: we have a diff mechanism
     DW: but you don't want that to be sent to your audit log
     SG: one last thing, do we need Xm or postfix for print.
     GW: we like postfix
     KW: first there are some documentation related to that. one other thing is a
	feature you turn off which is the .forward, we know how to do that with
	postfix but not xm.
     DW: discussion is on going about wich one is the default. the decision is
	postfix right now, but we are deciding which one we want to support.
     KW: the previous configuration specifically selected a mail client.
     MT: One more issue to bring up. If it takes too long we can discuss on list
	instead. setsepool, is that supposed to be generating audit messages
     SG: yes .. supposed to
     MT: what audit records are we expecting
     SG: I would have to go check
     DW: we are seeing AVC right now
     MT: is there a specific message type we should see, cause we are testing
	that now and haven't seen any yet.
     SG: it should be there in the lspp kernel.
     MT: I don't see it.. this is on i386, and x86_64
     SG: that was fixed a long time ago, possibly in Feb.
     GW: Ok.. Michael just try it and post your findings to the linux audit.
	Anything else?
     GW: Ok, again iterate the deadline for 2.6.18


Cron, tmpwatch, mail, etc.
==========================

Approximately 90% complete, 80% upstream
All kernel work needs to be in 2.6.18
Remaining tasks




More information about the redhat-lspp mailing list