[redhat-lspp] LSPP Development Telecon 10/02/2006 Minutes

[Loulwa Salem]

10/02/2006 lspp Meeting Minutes:
===============================
   Attendees

   Lawrence Wilson (IBM) - LW
   George Wilson (IBM) - GW
   Loulwa Salem (IBM) - LS
   Debora Velarde (IBM) - DV
   Michael Thompson (IBM) - MT
   Joy Latten (IBM) - JL
   Thiago Bauermann (IBM) - TB
   Al Viro (Red Hat) - AV
   Dan Walsh (Red Hat) - DW
   Eric Paris (Red Hat) - EP
   Lisa Smith (HP) - LMS
   Linda Knippers (HP) - LK
   Matt Anderson (HP) - MA
   Paul Moore (HP) - PM
   Klaus Weidner (Atsec) - KW
   Darrel Goeddel (TCS) - DG
   Chad Hanson (TCS) - CH
   Ted Toth - TT

Tentative Agenda:

Kernel / Rawhide update
-----------------------
     GW: any kernel updates you'd like to give us Al?
     AV: There are several patches that went into audit tree. The ppid patch is
	one, so it shouldn't bother us anymore. basically I completely forgot
	possibility of checking that stuff earlier than the syscall audit, so it
	had to be initialized better than it had been.
     GW: good news
     AV: that's all taken care off
     GW: anything else we need to know about audit besides ppid?
     AV: not that I can think of, the rest is not particularly visible.
     GW: klaus had an issue of perhaps requiring read and write audit, Al you
	explained in the past why it was not desirable to have. Based on how
	sockets work, there could be a requirement to read/write if we are not
	careful.
     KW: The requirement is to deny quickly. it would be good if you can refuse
	if not performing a read/write on file descriptor(fd). it would be
	easier if selinux can check that, but not necessarily with mls
     AV: ok,  let me see if I got that right. Do we, if we actually want to audit
	read/write attempts, could do it with syscall audit?
     KW: I think it would be much preferable if we don't have to do that. if a
	process gets a fd then it can use it
     AV: Generally we do that at the moment you get the fd; except that we do
	not, as far as I know, do that when we receive/send write datagram. That
	actually might be problem. It's true somebody had to send it to us, but
	it is possible to get a fd from a process without going through anything
	like open() in that process.
     KW: the reason is that in previous versions of policy, the policy rules did
	not enforce restriction for tcp to have equal levels, so you were able
	to connect initially then get an error on write calls. We need to agree
	on what the policy need to be.
     LK: I think we agreed that the policy need to behave the other way, but no
	one had time to fix that. Paul you agree?
     PM: I thought we decided last week to set MLS constraints so it has the
	right level
     KW: Ok, so I think we need to check that the current code is implementing it
	in this way.
     AV: There are several files where we actually do access control on read. we
	have to , Mainly stuff - property masks - should certainly be readable
	for process itself.  However, being able to open that file, fork, then
	have parent execute something sensitive would be a bad thing if child
	could read that file and get info about maps for the sensitive process.
	so in that case, we do have access control checks on read/write.
     KW: are you talking about the case where you have a privileged change.
     AV: yes
     KW: in that case, it is usually with trusted application and they make sure
	they are setting that right. This is a different class of security
	exposures than when you have unprivileged applications. guarding against
	sloppy trusted application is putting guards that it fails gracefully. I
	am not arguing to make checks go away ...
     AV: oh no, we are talking about real life exploits. Problem is that we have
	a file that gives up info about memory maps currently existent in a
	current process. We certainly can't open it ourselves, however having it
	open doesn't mean that at any subsequent point its contents won't become
	less sensitive. Here we just have change of contents for that file. That
	way we have to make different decisions.
     KW: for me this looks more like a case as invalidating fd if it refers to
	something different. it's the difference between doing an access check
	if that fd is pointing to something privileged.
     AV: not quite. basically, current logic looks that way, if we have that
	credential deleted and can trace task it tries to get info about, it
	also allows to access methods of any task that share memory with.
     KW: if you are talking about trusted applications don't you need to limit
	memory mapping and ptrace any way for that?
     AV: exactly so, to read from that file at any given moment, is ignoring
	ability to ptrace. That ability can go away and come back. We can trace
	it as a descriptor being invalidated.
     KW: I think in this case, I don't see a big problem, in this case it sound
	that the check on read is the right thing to do. since it is protection
	against a particular class of exploits. I don't really see anything that
	needs to be changed. This is a case to have the check happen at read
	time without having read become a security relevant operation.
     AV: I really generally think access control happens on open, if you have a
	fd, you can read it.  There are cases where this is legitimately not so.
     KW: as long as it is well defined special case, it's ok to have it that way.
	but working with sockets should not be a special case; that should work
	fine by default
     GW: ok, any other kernel issues
     CH: Regarding the networking issue, are you guys going to send that desired
	policy
     KW: The first step is to see what current pieces will look like. when the
	new beta comes out, it should have everything in one place. Also a
	related question, what's the time line for policy changes?
     LK: we don't have any one from RH today on the call .. right?
     CH: This is Chad, so I can't speak for RH.
     KW: I agree it is important to get that finalized. As paul said earlier, we
	don't want to break any applications. We just want to keep it
	restrictive for unprivileged applications
     GW: so that needs more discussion on list. who will make sure it works well
	enough for evaluation?
     KW: I have feedback from the evaluator and he is unhappy about the mls
	constraints. I need to update since those he looked at are probably
	obsolete by now. I'll keep you posted.

SELinux base update
-------------------

MLS policy issues
------------------
     GW: any base updates to policy anyone has seen that we need to discuss?

Hierarchical roles
------------------
     GW: for hierarchical roles, from our last meeting, we needed to play with
	that and if we didn't like it, we may need more changes. We determined
	what we have was ok.
     KW: since you can meet requirements using other features then it is not
	necessary to change
     GW: do we need examples?
     KW: yes

VFS polyinstantiation
---------------------
     GW: So Mike now is looking at that, he took over Janak's work. Janak offered
	some help but he doesn't have alot of time right now.
     MT: what I am focusing on is newrole. basically to make it capable of
	performing polyinstantiation work. It requires newrole to be a root suid
	program, which is not proving to be very easy to do.
     GW: ok, so that discussion will happen on selinux list as well.

Audit userspace
---------------
     GW: I think there was talk about a new userspace
     LS: Steve posted something on the list, audit-1.2.8.
     LK: yes, he posted new audit on Friday

Print
------
     GW: Any print updates Matt?
     MA: I was getting stuff together end of last week, and sent patches to RH. I
	am working with Tim and Linda on cleaning remaining issues. I sent
	updated patch that handles lprm better. now I am playing with mls
	enforcing mode some more, which is uncovering new problems like the
	socket file and printed device files. At this point, I am running into
	different mls issues. So in all, I sent updated patch to RH and Tim
	should be able to get that in FC6 without any problems
     GW: ok, great.
     MA: I'll also send the patch to redhat-lspp as well so everyone can look at
	it.
     LK: and there are policy patches floating around too .. right?
     MA: yes. I got feedback. chris PeBenito was concerned about removing the
	lpd. not sure how many problems we'll run into that. I have a .te file
	that I'll post with my patch. basically lpr was given too many allow
	rules, so I needed to remove allows.
[Dan joined]
     PM: Dan did you catch the last bit about that Chris is concerned that lpd
	might break.
     DW: yeah .. how many rules did you have to remove?
     PM: about 13 rules.
     DW: mainly have to deal with the spool file
     PM: yeah. I also have the .te file that I'll post too.
     DW: you may want to throw a boolean there if cups is running or not. I
	clearly want to maintain what they want as well. as soon as I get the
	patch I'll take a loot at it and put booleans to switch between modes.
	we'll default to cups running.
     DW: I spent about 1 hour this morning working on crond. I think IBM submitted
	a bug. I have a policy-17 that should fix that, should be going out
	soon. also Linda submitted some changes to mcstransd. that might require
	some policy changes. but people have not used it yet to see if there are
	any changes needed. is Linda on?
     LK: yes, I'm here, Is Darrel on?. I can do the part of the patch that I did.
	but Stephen made suggestions and I was wondering how to do that, it's
	above my head to add those types
     DG: I'll take a look at the emails and see how we can do that.
     LK: my response to Stephen's suggestions is great idea, who wants to do it?
     DW: is there a way to turn this off, or toggle, I don't want the overhead
     LK: I don't think it get there if mcs is not defined
     DW: it is defined for mcs.
     DG: it will be cached, so you only go through this once
     DW: what if the policy is reloaded
     DG: then it'll have to go through the avc again, but once cached, it'll be
	there.
     LK: well there are also mallocs and frees that can cause overhead.
     DG: yes .. true
     DW: problem with mcstransd is that 99% of time, it is not finding anything,
	so I don't want the overhead associated with it.
     DG: so yeah, we can put in a change to make it configurable

     GW: I have something to share here. Klaus took Kickstart generation
	materials that hp generously opensourced, he modified them for the beta
	and we'll put his modifications out. so hopefully everyone can perform
	the installations easily. klaus, where do you want to post that?
     KW: depends on what people want. the whole thing is small, about 35kb, so we
	can post it on the mailing list, and later we can look for more
	permanent home for it. This is intended as a snapshot to see an example
	of what the mls configurations will look like. it has the
	polyinstantiation on ssh session.
     LK: if it is hard to mail, we at HP can post things on external website.
     GW: hopefully people will find that helpful.


CIPSO
------
     GW: sounds that people want and other didn't want. the networking pieces are
	all impending. I came out of that that we do have a complete story and
	that the pieces will come back together. mainly that we don't' have to
	worry about TE

IPsec
------
     GW: Joy have you been doing any testing on this
     JL: no I've been waiting on patches
     LK: what happened to all these patches that Venkat was working on.
     EP: I spent all day trying to figure out what happened with all those
	patches. my deadline is in 16 minutes and I don't think I'll make it. I
	am trying to figure out what is going on. I want to point out that if
	this does not get proper testing before beta 2 then I will not sign off
	on it to go in rhel5. We also did not see any auditing hooks. I don't
	know if that is in there, and not sure who is looking at it.
     GW: I thought that in the SELinux symposium we agreed that file system
	auditing was enough.
     KW: if you do things that change labels that needs to be auditable. The
	requirements don't go in much detail of what is required for that.
     LK: I think lspp requirements are somewhat vague there. if you are relying
	on AVC, I am not sure what kind of AVC will you be relying on.
     JL: what would you audit for ipsec, every time you access a policy?
     GW: every time you access a socket.
     LK: if you change config files, so if there is a netlabel command that
	changes settings then you need to audit that
     DG: basically changes to configurations
     PM: only problem with doing that is to have a label netlink socket, so now
	we have it restricted to root.
     KW: as long as operations are restricted to admins you get less worry. if
	everybody can do it then that is a problem, you don't want everyone to
	be able to change configurations
     PM: right, but since it is restricted interface, it would be nice to have
	auditing on it, but it is not required. I am hoping
     GW: yes, that's what I am hoping as well.
     EP: hopefully in a couple of hours, I'll have a rhel5 with all the patches
	and fixes.
     GW: are there any breakages?
     EP: currently, there is a fix for the bluetooth sockets, but there is an
	IPSec leak that we are working on.
     GW: what is considered serious testing Eric?
     EP: if I get an extension on the deadline, then I'll be able to hopefully
	get the code in and we'd get wide partner testing with beta. if not my
	management wanted to know if we can ship beta 2 with out networking then
	put it in between beta2 and GA, but I am not comfortable with that.
     GW: I agree, I wouldn't be comfortable with that either.
     PM: Eric, I'll also send you a patch based on the comment changes.
     DG: is the security id reconciliation fix in there?
     EP: the SID reconciliation is not there. but the other stuff is there
     LK: that includes the netlabel audit changes?
     EP: they are not in, but I'm sure they can be pushed in.
     GW: so we need to do testing non the less. I am hoping joy you can continue
	to do performance testing
     EP: I will hopefully have a kernel to test with by today.
     PM: that would be helpful.
     EP: I've been spending all day to fix differences between 2.6.18 kernels.
	What I'll have today, should be close to what we have in rhel 5
     GW: is this going to be off your people page
     EP: yes ..

     KW: back to the networking labeling. since this is an admin action, there is
	flexibility in that. do you use a configuration file.
     JL: yes, the racoon file
     KW: so I think file system auditing for that would work. it might be a
	different type of record, but at least it needs to be visible.
     EP: I would say that the auditing is not much concern to me at this point,
	and can be added to rhel later, but the other stuff like sec id
	reconciliation is a bigger concern.
     EP: so who will be taking care of that.
     GW: we certainly care about that, but I can't volunteer to do work from a
	technical point of view. Joy and I would need to work with Venkat on 	
	that
     DG: Venkat is not around, but we can support and provide help for that

ipsec-tools:  racoon
---------------------
     GW: as far as I know the racoon patch is complete and free of bugs
     JL: so far

xinetd
-------
     GW: anyone has problems with xinetd
     PM: there was a discussion on mailing list on the thread of sec id
	reconciliation that I told steve about. Basically Stephen smalley had
	some concerns about xinetd. I have not seen a reply from Steve.
     DW: what is this about?
     PM: Stephen smalley basically wanted to use, and I'm gonna make up a term
	here, a hybrid context. he wasn't happy with blindly taking the ftp
	context. I think we can handle that in user space so probably not a big
	deal
     GW: so we'll keep discussing xinetd next week as well

Single-user mode
-----------------
     GW: I don't know if single user mode made it in
     DW: you mean the crashing, yes it is in
     GW: Ok, I'll try and test it out

Self tests
-----------
     GW: I need to get back to that.

Cron, tmpwatch, mail, etc.
---------------------------
     GW: don't know if anyone experimented with using mail wrapper with cron, it
	is necessary to send messages to admins

Bugs / remaining tasks
----------------------
     GW: basically everything we are handling are considered bugs right now. I
	think all can have access to view bugs. if not we need to let Irena
	know. Any other issues?
     DW: George, if you want to use the single user mode, the flag is /.autofsck.
	It is not handled by selinux anymore. look in /etc/rc.sysinit for
	single user mode if you like too.

Final cutoff date
------------------