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

[Loulwa Salem]

6/12/2006 lspp Meeting Minutes:
===============================
Attendees
Janak Desai (IBM) - JD
Debora Velarde (IBM) - DV
George Wilson (IBM) - GW
Joy Latten (IBM) - JL
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Lawrence Wilson (IBM) - LW
Fernando Medrano (IBM) - FM
Thiago Jung Bauermann (IBM) - TB
Nikhil Gandhi (IBM) - NG
Stephen Smalley (NSA) - SS
Al Viro (Red Hat) - AV
Steve Grubb (Red Hat) - SG
James Antel (Red Hat) - JA
Irina Boverman (Red Hat) - IB
Paul Sutherland (Red Hat) - PS
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Amy Griffis (HP) - AG
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
=============

     PM: I have some patches, but I haven't been posting to the list. I am
	intending for them to go into the 2.6.17
     SG: you intend for it to go into rhel5?
     PM: yes, I hope so
     SG: if you want it in rhel5 then it needs to go into 2.6.18. All of Amy's
	patches will go into 2.6.18, which will open for business in the next
	couple of weeks
     PM: and the window will is open for 2 weeks
     SG: yes, most likely.
     AV: The real question is what SELinux maintainers will have to say about
	this. If it is more than code in kernel, then audit & friends, need at
	least the maintainers of that code agreeing to get the patch merged.
     PM: If Stephen is on the call, would he comment on that issue.
     SS: it's not an issue on our side.. if it's ok with net dev people
     AV: which would be Dave Miller
     PM: only people I got feedback from is Stephen and James.
     AV: what is the situation with Dave Miller?
     LK: have you heard from him, what's the best way to contact him
     AV: mail, cc him as well
     PM: I'll send him some private mail this week and see if he has any
	comments.
     GW: we also would like to see it in there if you can
     SG: I was building a kernel Friday, but the net label patch broke in the
	linking part. I sent the output to Paul to look at. As soon as I have a
	net label patch that compiles I'll build another one. Should .35 be an
	update with the new patches, and make a .36 with the net label patch.
     PM: we can talk about the net label stuff now if it's ok. Is this going to
	delay your agenda George?
     GW: No problem, go ahead.
     PM: Reason I didn't see it yet is that I got it late Friday, and got to see
	it just today morning. Is Ted on call.
     TT: Yes, I'm here
     PM: We all need to thank Ted, he set up a trusted solaris system last week,
	which saved me about 3 weeks of work, so thanks alot Ted. There is an
	issue about trusted Solaris talking to selinux, but we'll work through
	it since we have trusted solaris in operation now.
     GW: Great, thanks Paul and Ted .. we appreciate that
     TT: Glad to help
     PM: There was some talk about ipsec stuff, when you do accept a connection
	you need to relabel the socket. Need to make sure the CIPSO IP is set
	correctly. IPsec needs to be figured out, but the netlabel stuff should
	behave correctly. I believe we are doing it the right way. Now that this
	is taken care of Steve, I'll take a look at the problem you posted. I'll
	fix it and send you a new patch. So as far as kernel goes, I'm
	recommending that if you have all your patches, then go ahead and build
	a .35 kernel now, and I'll get the net label patches in the next kernel.
	I'll put the netlabel stuff on the list.
     AV: There is a potential problem, Andrew Morton will be away for a week.
	That means no new -mm for about a week
     MA: is there a way we can extend the window for 2.6.18.
     AV: How?
     MA: well, since we can't do much testing during that week.
     PM: I'll test the lspp kernel on different platforms, make sure it works, I
	know IBM people do that as well. I want to look at the code once over,
	then I'll send another posting to netdev, selinux, lsm, see if I can get
	another round of comments.
     GS: sounds good to me. Once that it's out, we'll put an effort into more
	testing.

AuditFS/inotify completion
==========================
     GW: Hi Amy, how is this going?
     AG: Good, I am wrapping things up. I posted couple fixes for inode number
	patch. Also posted new patch to add directory info to audit log record
	at end of last week, I don't think it got alot of testing other than me.
	Also Al fixed a problem that I introduced, thanks Al, and I'll try to be
	more careful about not introducing problems. This week I'll work on
	filter key patch. I'm out Thursday and Friday, I'll post something
	before I leave.
     SG: I remember you had talked to Al if it was time to put anything on Linux
	mailing list. have you done anything to push these patches upstream
     AG: I got that the inotify patches will be merged upstream. I got some
	comments about cleanups, and I'm working on that. I have not received
	any other feedback. My assumption is that audit part of that patch will
	be sent by Al as a group along with the ones in -git tree.
     SG: I was just wondering since people were asking about the client piece of
	it.
     AG: yeah those people who asked that didn't post anything.
     GW: thanks Amy, we can't express our gratitude enough, I know this can be
	annoying and not so much fun.
     AG: Well ... it can be fun.
     GW: I posted my small three line patch to fix memory leak to the audit list.
	hopefully that will be picked up

LSPP kernel issues
==================
     GW: Let's go around and collect status. Steve got a new kernel out there no,
	I've tried it and so far no issues specific to this kernel.
     SG: there is one thing, Dave jones was doing experiments while I was
	building. His experiment kills anything that uses a serial port. I'll
	switch to another build system when we build another kernel, so if you
	are using a serial console, it'll not work.
     GW: That is great to know, because we were ready to set up a serial
	connection. In this case we'll use an older kernel, or wait for the
	fixed one.
     SG: I hope to get everything together and push a build tomorrow.
     DG: I put a patch out about the enforcing issue. I got some comments from
	Stephen, anyone else has comments on that?
     GW: It looks good to me, obviously Stephen has better experience. If
	everything builds and works in both modes, then I don't think there is a
	problem.

Audit userspace
================
     GW: Steve, anything new with audit userspace?
     SG: I am working towards another userspace release, but it's going slow, and
	will be a while before it's out.


Audit failure action inquiry function
=====================================
     GW: Ok, now to the audit failure action inquiry, anything new here.
     LS: It's going well, changing code to parse and put file in /etc. I've
	incorporated some comments, and should have a patch out this week for
	that.
     GW: great .. thanks Lisa.

Audit of service discontinuity
==============================
     GW: I don't remember what we decided about this last week.
     LK: I believe we decided it was impossible to do that. It's going to fail in
	a catastrophic way that it will be obvious for the administrator that it
	failed.
     GW: Ok, then I'll remove this item from the agenda.

Print
=====
     MA: I am going between doing dev allocator integration and other testing,
	and I ran into dev allocator problem. I tracked bug from before and
	verifying the fix is correct. I have updates to the man pages and docs.
	I'm not sure they cover everything you are looking for. I need a test
	plan to make sure I got everything.
     GW: That was Janak asking for that.
     JD: Yes .. that will be great. thanks
     MT: By the way, small interruption Al will Join shortly on IRC
     GW: great, Al will join, we'll step back a bit to the kernel section and ask
	him about that.
     AV: Sorry I missed some of this.


SELinux base update
===================
     GW: Dan is not on the call today, but he did send status to the list. Main
	thing, the device allocator patch is in

MLS policy issues
=================
     GW: any issue with policy. Mike usually has some, anything Mike?
     MT: the sysadmin role seems to be the only one capable of accessing /root.
	Dan said it is to protect admin roles from being attacked using the
	.bashrc profile files. I just don't know how that reasoning came about
	when you are working with trusted admins. it's annoying when you log in
	as secadm and can't see what's in /root. any one has any idea why we do
	it this way?
     GW: so then your question is why we have it this way?
     MT: yeah, does it make sense for it to be this way when we are assuming
	trusted admins. should it be changed back?
     SG: couldn't you do something like the bashrc file checks who you are, and
	sets some variables.
     MT: yes we can, but Dan said they are trying to protect the admins and
	separate them, but it doesn't make sense with trusted admins. And that's
	what I don't get.
     KW: there is no requirement in the sense of RBAC, it can be acceptable for
	all roles.
     MT: that's the trusted admin argument
     SS: Your other option is to configure pam-namespace.
     MT: I just don't understand why we don't give them access to root. where
	would secadm files be, where does secadm role live. I'm not clear about
	that.
     KW: It would be nice to have that as an option. if people wanted more
	protection, it can be an option. Using polyinstantiation to separate
	roles. people who don't care about that then would have a more friendly
	system.
     GW: seems like a reasonable compromise to me. I don't think we would make
	that default configuration though
     SG: No, sounds like it would be in a configuration script, but not shipped
	by default.
     GW: yeah, until customers figure out how to use polyinstantiation. So
	hopefully we want a friendly default with good instruction on how to set
	up polyinstantiation. This is a Red Hat decision.

Restriction of kernel keyring
=============================
     GW: This looks like a done deal
     SS: He is finalizing some work. He's looking at additional issues. What is
	in Andrew's patch set is sufficient. Has patches for gdm, login, and sshd
	we'd like to get into rhel.
     GW: thanks for taking that up, we appreciate it. once that is in kernel we
	need to be testing on it. Back to networking, any read if secmark will
	or will not be included in Rhel.
     SG: I think so, maybe Stephen knows more about what James is working on
     SS: yes, it will be available for rhel5
     GW: is it sufficient not to use it. it's late to integrate with the other
	labeling mechanism we have.
     JL: is secmark going to be installed by default?
     SS: I understand that secmark will be the default. It's a huge win in terms
	of performance on network. It superceedes old SELinux support port and
	node stuff.. I saw patch from Venkat, but I was gone all last week, so I
	don't know what is going on
     VY: so far I haven't had a chance to even prototype what I mentioned in
	email last week. I'll try this week, anyone thinks it might be a waste
	of time to prototype it. I am Concerned about outbound secmark. Wish
	James is here to give comments
     SS: James prefers to keep them separate.
     VY: after having resolved various labels on inbound. we can have checks to
	have one label replace another label.
     GS: sounds like alot of work to happen in 2 weeks.
     SS: to what extent were you relying on current controls. what is actually
	going into certification?
     GW: the ipsec stuff will be relevant to certification. we would have to
	apply this to local case. would be nice to use secmark, but timing is
	late. Back to your question venkat, I  don't know if there is enough 	
	time to prototype this and put upstream. It is something we would like
	to have, but don't know about the time. This is a read from RH if it has
	chance to make it in. We can contain it in our Security Target, but it's
	a whole timing issue, and I don't know if anyone can help you with it.
	Maybe Joy
     JL: in what? figuring out sizing for the effort?
     GW: maybe with sizing, and figure out what needs to be done, testing as
	well. can we just make use of IPsec now, and live with that. I know
	Katherine needs to get her patch in there.
     SS: you mean Katherine's patch alone, or also Venkat's patch as well
     GW: I think we need Venkat's patch in there as well
     SS: they are addressing diff kinds of controls. Long term it's good to
	integrate them, but now it's ok to be separate	
     GW: what if have conflicting labels
     SS: they are being used for different reasons.
     KW: having conflicting label is not a problem. if ipsec and secmark reject
	connection it's ok, as long as one rejects.
     SS: they operate independently.
     GW: does xinetd need to be aware of secmark labels
     CH: xinetd can work with ipsec, or secmark, so at this point it needs to
	work with ipsec.
     GW: one enhancement we'll make is to accept/reject packets based on labels.
     CH: using multiple labels that are not enforced is the biggest problem we
	had
     GW: for our purpose we base everything on ipsec, and ignore secmark.
     KW: I have question about Venkat's patches. looks like they require racoon
	to be active to be useful.
     VY: racoon is not a necessity, one can manually load security associations,
	and that would be fine. so racoon is not a necessity, but would make
	things easier.
     KW: this also may be a question for end user. if you have 1000 categories,
	that will be 2^1000 possibilities and impossible to set up
     VY: that's the reason for the patch, and using racoon
     KW: Ok .. so we need racoon as part of evaluated configuration


CIPSO
=====

IPsec:  MLS, secmark, UNIX domain secpeer, xinetd
==================================================
     TT: I want to know if there is an update on xinetd
     JL: I was ready to shoot an email to Steve, with some questions before I
	start it.
     SG: I was thinking of getting it working with cipso and xinetd
     GW: we have done absolutely no test on that. Joy will address issues that
	Steve brought up about packages accepting/rejecting based on secpeer.
	speaking of secpeer, I haven't heard anything from katherine about that,
	I'll ping her.


ipsec-tools:  SPD dump and racoon base + MLS
============================================
     GW: any word on SPD dump. if it's using netlink it's linux specific, and
the list is mostly BSD oriented.
     CH: [Sorry, I didn't catch what Chad said about this topic ... feel free to 
fill in]

Device allocation
==================
     GW: Debbie is back, are there issue you like to bring up. Matt posted patch
	on it
     DV: I saw the patch not too long ago, will take a better look at it
     GW: hopefully once done, it needs to be tested


Self tests
==========
     GW: I'm getting back to those, hopefully this weeks.

VFS polyinstantiation
======================
     JD: pam namespace is in rawhide. As for cron and subtree-mount patches,
	Steve got commitment they'll be in rawhide, but not there yet, I think
	they are waiting for a release window to put it in there.

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

     GW: We reached the end of agenda .. stuff need to be in 2.6.18. any issues
	anyone needs to bring up?
     LK: After last week, I though we will have discussion on mailing list about 	
	RBAC. Klaus and George you said you had some thoughts on that.
     GW: yup, sorry I got involved. I owe Irena a come back on that as well. We
	need to have user/roles policy modules question is, is that going to
	taint the base policy.
     LK: if we can just have a clear understanding of what the minimum, then that
	should be helpful
     GW: I agree, we need to do that, we do need to have flexibility to create
	roles, change them with out tainting base policy
     KW: best way to do that is to say that predefined roles are unchangeable.
     GW: I thought we talked about modifying the default roles
     KW: better to base new roles on pre defined ones, some programs expect the
	predefined roles as is, so you don't want to break those. So you can
	just create your own roles as you need to.
     GW: I'll take the to do to post something on mailing list on this.
     LK: George, also I think there are couple of items on the done/not done list
	that need to be updated.
     GW: I had things moved from one to the other ... We changed our philosophy
	midstream, so I need to update this.
     FM: I had a question about trusted printing, how can I attach a label to a
	printer?
     GW: use device allocator, so try that and see if it works.
     FM: ok.. I will
     GW: Any other issues we need to discuss?. Ok then let's adjourn the meeting,
	and I'll start the conversation about RBAC on the mailing list.