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

[Loulwa Salem]

6/26/2006 lspp Meeting Minutes:
===============================
   Attendees
   Robin Redden (IBM) - RR
   Janak Desai (IBM) - JD
   George Wilson (IBM) - GW
   Loulwa Salem (IBM) - LS
   Debora Velarde (IBM) - DV
   Michael Thompson (IBM) - MT
   Lawrence Wilson (IBM) - LW
   Nikhil Gandhi (IBM) - NG
   Al Viro (Red Hat) - AV
   Steve Grubb (Red Hat) - SG
   Irina Boverman (Red Hat) - IB
   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
   Ted Toth - TT
   Joe Nall - JN


Tentative Agenda:

Kernel update
==============
     GW: Al, would you like to give us a kernel updates?
     AV: Most of what we had a week ago got into the tree on Tuesday. Right now
	the problem is we've been asked to do something similar to what RHEL4
	did, namely check for r/w/x, all such stuff, for files. We do have patch
	that allows to define classes of syscalls and I am keeping them up to
	date with changes--32 and 64 bit binaries on same kernel. Original
	intent of this patch was to do stuff like allow audit to ask to watch 	
	syscalls that change directories. keeping userland up to date is
	unpleasant; better done in kernel, we want kernel to expand the set of
	syscalls based on bitmap from userland. It looked like we should be able
	to do this, unfortunately, when tried to implement on top of syscall
	classes, and realized that actually the behavior we used to have is not
	particularly well defined. example:  say we do link:  modify 2 objects,
	namely directory where we link object, and modifies metadata for file
	we're linking to. what should this thing be considered? change or read,
	because we also do read access to bunch of directories at very least,
	parent of file we are linking to
     SG: I would think a link would be a write
     AV: yes it is a write to two objects and a read from many more. Thing is it
	has been said many times that we can't just use watches because we want
	checks done before access control. We want events even when access
	control denies operation. That is fine, but not quite consistent. Don't
	know what a pathname will resolve to until you have passed a bunch of
	access control checks. If it ends on a symlink, don't know where it
	points to unless you get it from the fileserver (for NFS), if NFS
	refuses to let you do the lookup, you will never know what it is, you
	don't know what pathname resolves to ahead of time. You don't manage to
	generate events regardless of what access control does. It depend on
	previous accesss control checks given positive results. We don't get
	consistent semantics for what used to be done in RHEL4, and it would be
	nice to figure out what we want semantics to be and how much of code we
	want to emulate, and how exact do we want the emulation to be.
     SG: that's a big piece of code that people are using.
     AV: can't say how pathname will resolve if we get access denied midway
	through resolution. It is not a matter of syscall or not, just
	permission we cannot get out of server, now back to question about link
     SG: I think we only want to have 4 groups rwxa, I know there is 1 or 2 holes
	in getting attributes or not being able to set watch. this may be kind
	of thing to put something out there that maybe klaus or stephan can
	critique. ultimately, they need to help us decide which syscall goes
	where and what we need to log. sometimes if you have watch on something,
	it never gets inode, so it will never trigger a watch
     AV: no we couldn't since we ...
     SG: I think the next best thing is take user string to OS and record that.
	but still I don't think we will generate a watch record. if we have
	syscall rule that was triggered, you'll see a record and access denied.
     KW: in previous evaluations, we used requirements that you have audit on 
objects,
	and if you didn't get access to object, then you don't need to audit
	that operation on the object
     AV: ok now back to question about link. it changes contents of directory and
	changes attributes of target. Now, we can filter on syscall being
	writing or modifier of attributes and see that it had triggered watch on
	directory or target respectively. Question is how to combine it? what we
	see is 2 objects have been touched, 2 watches have been triggered. We
	see that syscall was a link and we are watching for changes of contents,
	in fact how do we decide which of the touched objects have change of
	attributes and which a change of contents. looking at it post mortem, at
	syscall exit, we see 2 places touches, we see syscall was link.
	figuring out now that we are watching for change of attributes.
     KW: one thing is I'm not sure how security relevant is this. Point is that
	when someone tries to access file you get record if they do access
	through hard link or through name.
     AV: indeed, but that applies to any syscall that would generate events on 2
	different filesystem objects; 2 that are of a different nature.
     SG: I think the way rhel 4 worked it included 3 different object, for 
example if
	you did a move ..(Al interrupts)
     AV: Move is alright, that is different. let me ask a more specific question.
	We are watching for changes of attributes of given directory. We create
	link of that directory to some file. Syscall touches some directory;
	syscall changes attributes of one of objects it touches. Did rhel4
	generate a records from such an operation? Problem is we did change
	directory and some attributes, but not of that directory.
     KW: not entirely sure I understand the question. what would be relevant is
	creating name inside directory, which is interpreted as a write. if you
	have watch on a link, you would get record
     SG: we need to define what a change of attribute is
     KW: should be security relevant like owner or perms, but the increase in
	link count is not relevant
     AV: yes you would care.
     KW: but this is not an area that the protection profile defines. This is
	where we trust applications to do the right thing but didn't examine it
	in detail.
     SG: the changes in attribute, extended attributes in acl, the attributes in
	filesystem is what we care about.
     AV: what about time stamps?
     SG: time stamps are not interesting
     AV: ok, one more thing. There is a case where write can change attributes;
	when you have write to open file that happens to have suid bit set then
	this will be a write.
     KW: you mean open?
     AV: no on write; happens on write; it has to
     KW: this is new to me, but I don't think it's a security issue.
     AV: doing that is security related; I know this way which is to say, even if
	you got write access to suid binary, any attempt to actually modify it,
	will lead to binary not being suid.
     KW: I mean that's kind of a nice feature, but not required.
     AL: posix requires it
     KW: but we are not concerned with posix requirements here.
     AV: I think it is very standard behavior
     KW: we are mostly concerned with capp compliance. it's nice if it behaves as
	you said, but we don't need to go the extra mile to cover everything.
     AV: what about file length
     KW: not important.
     SG: keep it simple, user, group, access permissions., changes to acl
     AV: ahm, ok fine
     SG: just pieces that deal with ownership and access. Also for directories we
	are interested in same attributes. but not actual entries
     AV: what about operations that change both? you discard link count--fine.
	ok, there might be some need for additional work namely in some cases, we
	will have to look at more than just what syscall it is. Let me explain;
	thing I am thinking about is; basically how much info about syscall do
	we want in those situations?
     SG: need to know which kind of access was attempted
     AV: that is mostly a function of syscall number. that is the point, knowing
	syscall number gives us almost everything.In some cases we need to go
	further, namely flags to open.
     AG: in rhel 4 we had fields that would indicate the mode. I want to think
	that was the mask.
     SG: well there is no concept of mask, it might be a place where these things
	were reported. don't know if we want to keep adding things to syscall
	records. on other hand maybe someone clever can put something into new
	key to indicate rule was attribute change rule, or a read, or something
	like that.
     AV: alright, ok. what do we want from existing rules? if we have rules
	created on each, say chmod, or better yet, chown. I have rules with this
	syscall number as a filter. what do we want it to do when we deal with
	32-bit process? keep current behavior?
     SG: that's tangent I agree
     KW: requirements are same if you have 32 or 64 bit
     AV: the thing is, we have different meaning of syscall number for 32- and
	64-bit processes on AMD64. Now current behavior is userland gave us a
	list of interesting syscall numbers, that condition satisfied whenever
	system call number matches one in the set no matter whether from 32- or
	64- bit
     KW: that's why we have arch field
     AV: A syscall, we can discriminate on that. what do we do if rules has no
	such field?
     KW: then people would get what they ask for. if people care, it's tricky to
	get that right. in real world we have audit rule to get this info right.
	Now it's acceptable that if people specify something broken then they
	get something broken back.
     SG: So if people specify something to /etc/audit, then they can specify that
	there
     AV: correct ..
     SG: I think we need all syscalls related to writing
     AV: that's fine, that will be done. That's very few classes of syscalls;
	certainly anything that does write is no problem. How fine grained do we
	go?
     KW: need arch number. userspace should put right syscall numbers to the
	filter, people who care about audit requirements would need to be
	running a specific version of audit. so people running new kernel with
	old userspace, then it won't work, no need to make kernel smart about
	this.
     AV: yes, understand, pleasant moment. if you ask to watch for fork and exit,
	you will get nothing because recent libc uses clone rather than fork,
	and exit_group rather than exit. It is not generated by library calls of
	same names
     KW: we encountered that before when people are complaining. this logic
	does not need to go to kernel, we only need user tools or something.
	it's sufficient to have example files or config files to show how to do
	it. These are all valid points, but people can get it wrong if you don't
	know how the low level things work.
     AV: ok, oh by the way, question for Steve. how do names of syscalls get
	resolved to numbers in userland? where do you get 32-bit numbers, when
	things are built on 64-bit?
     SG: we take look at arch field, and based on that we see it in a lookup
	table
     AV: I see.
     SG: we have all syscall tables for all arch we support in memory
     AV: Hope we never have to support MIPS. There are 5 sets of tables there. Oh
	well.
     KW: Alternate choice is that for things that you don't want to support, then
	you can disable those
     AV: RHEL doesn't support MIPS at all, so that isn't a problem.
     KW: example was that on ia64, they completely disabled 32-bit. not the best
	way, but for functionality it's better to disable than jump through
	hoops to get it to work
     AV: that wouldn't be practical on PPC, SPARC, or any arch 64- doesn't give
	much over 32- bit in userland. others, well synchronized between 32-bit
	and 64-bit
     SG: I think that anything else on this we should take to the mailing list.
     GW: alright, sounds like we are resynced again there.


AuditFS/inotify completion
==========================
     GW: anything on audit fs or inotify
     AG: since last week, all patches went in, since then I'm updating our audit
	test suite, hoping to shake out any bugs
     KW: is that the audit suite you published on sourceforge
     AG: yes, and probably we will need to release an update once we have those
     KW: thanks very much
     GW: yes thanks a lot


LSPP kernel issues
==================
     GW: I've been working on getting performance readings. I am trying to
	resolve some problems and see what varying numbers of watches and
	syscalls do on performance. if there are any interesting variations you
	think I can try, post on irc, mailing list or email me
     SG: are you testing on 64 power pc, or 390?
     GW: yes this is 64 way ppc
     SG: Ok, because there were issues on 390
     GW: these are standard bench marks we run. The main point is that I am
	trying to get some numbers, hopefully I'll have some by end of the week.
	This looks like good kernel, I haven't had problems, haven't tried the
	networking though

Audit userspace
================
     SG: right now, the lspp.39 is in build system. I got patch from Venkat, and
	I added that one to the .38. so the .39 will be combination of both
	patches, maybe within 1 hour. on userspace, I've been working on new
	release. I finished integrating the key patch that Amy sent. made few
	changes for backwards compatibility, hoping to get new audit userspace
	out in next 24 hours. My highest priority right now is the audit
	userspace
     GW: ok, we'll upgrade to that once it's out .. thanks


Audit failure action inquiry function
======================================
     LMS:I sent updated patch out, people can look at that and send comments,
	need to create man page, as well as update audit open man the patch
	mailed to audit mailing list?
     LMS: yes, about 1 hour ago. If you don't see it, let me know I'll send it \	
	again
     GW: I see it off the lspp list here
     SG: ok, I'll look for it
     SG: thanks lisa


Print
=====
     MA: had minor hardware problem, they are now resolved. I got update from 
tim 	that version <...> will be in rhel 5. I got patch from Smalley that
	clears up lpq issue. also have policy updates. I would like to get 1.3
	version of cups out mid this week so I can get response from people over
	the long break.
     GW: we have intern, Fernando, you might have already talked to him, who will
	be helping test this stuff
     MA: I guess I also need to get some test development as well, but waiting
	to get this out
     GW: he should be able to get you feedback, we are also getting a physical
	printer soon, and should give you some feedback
     MA: great, looking forward to hear from him


SELinux base update
===================
     GW: is Dan on?
     SG: he is on vacation
     GW: right, does anyone have any issues to bring up regarding this?


MLS policy issues
=================
     GW: any mls issue, Mike this is your section here, anything you want to
	bring up?
     MT: none as of this moment, I did have a question, the semanage utility, the
	man page is out of date, there is a concept of labeling prefix for user.
	Anyone knows what this is, because I don't understand it's purpose. if
	you do semanage user -l, you'll see it. what is it and how do you use
	it?
     DG: I believe this is related to the home directory.
     MT: you mean you would use it in labeling /bin/user_t
     DG: I think it wants to match up to role you log on as, I am stuck in old
	policy, so I don't have great time playing with this.
     GW: so it's not documented in man page
     MT: it's not documented at all. It's not clear on how to use it. I might be
	using it incorrectly or not, so I am not sure
     DG: can you dump information on user
     MT: yes, you can do semanage -l and you'll see the label
     KW: does that interact with polyinstantiation, do we have to polyinstantiate
	user home directory?
     JD: there is probably some interaction there, so far I've been working with
	very simple rules. I need to play with it more since people are working
	with it now and want to know about setting up tight member policy.


CIPSO
=====
     GW: paul, anything on that?
     PM: I posted patch to net dev last week, at least david miller looked at it.
	he had comment about patch ordering, so I reordered an pushed it back
	out. What concerns me most is about having CIPSO in kernel at all
	regardless of implementation. Some people posted that CIPSO is
	important, so I'm grateful to that, james morris said it is nice to
	have, but not much more. One of comments david miller had is to use the
	generic network interface, so I am making changes to that. once that
	looks ok, I 'll push another patch out. there are couple of issue I need
	to work out
     SG: there are 4 different config options. you think people will need that
	much flexibility
     PM: I think so
     SG: when will you turn other stuff on/off, I am compiling with all on
     PM: sometimes you won't turn some stuff on, if you don't want unlabeled for
	example.
     SG: I suggest you consolidate options, one of the things I read in the
	verbiage of comments is about the complexity of the code
     PM: well, changeling config options will not change the code
     SG: I understand, but there is about 16 different options with the
	permutations
     PM: I think there is a total of 6 options, which ones would you remove?
     SG: if the answer is always a yes, then these are candidates to be removed
	I'd say
     PM: yeah, but I don't think there are any options that are always yes, there
	are defaults
     SG: I see, but I think it is something you should consider
     PM: I understand your point Steve, so if you have a specific argument, or
	you can pinpoint, please let me know.
     SG: is the Argus group on lspp list?
     PM: i think they are on lsm list. only thing anyone is getting rid off, is
	the cipso option, but I'd like to keep it so we have option to put ripso
	later. I see it going out then us putting it back in
     SG: I am trying to help you get it up stream easier, so trying to think of
	things to help you
     KW: does it hurt to have the support for unlabeled packets always on? people
	can reject them.
     PM: I don't know, is Ted on call
     TT: yes, I think we need to have labeled and unlabeled.
     KW: I am thinking to have it at compile time
     JN: I think it is depending on the customer, if Argus guys, or Red Hat have
	them on.
     PM: we can put them as compile time options. turning things on and off is
	very little work
     LK: even if it is a perception
     PM: if that's what people want, then I'll drop it.
     LK: that's the feedback you are getting, so maybe have a run time option
     SG: that might be necessary to get initial acceptance, then later it can be
	added
     KW: another related question. Paul, do you have a set of selinux policy to
	put mls constraints on packets
     PM: haven't done any work on that
     KW: I don't know where to start on that, but how much policy would be needed
	to get things working
     PM: the policy shouldn't be too substantial. there shouldn't be changes to
	mls constraints. the only thing I can think of is the TE policy. I think
	in current configs, it uses the socket type.
     KW: I think it would really help to have sample policy which doesn't do any
	TE, but at least allows MLS to do its job
     PM: I can do that, but I need to get some things done first
     GW: test policy would be very helpful, another intern project for us is
	building that into a kernel.


IPsec:  MLS, UNIX domain secpeer, xinetd
=========================================
     GW: Venkat has done considerable work, not sure if it is enough to get in
	the window. I suspect not, unless something drastic happens
     VY: I got email about wanting requirements and design, we have something we
	are reviewing here, and should have it out tonight
     JN: I am looking for a "how to" to line systems together to get them to work
	together
     GW: I think Joy put out something on that
     JL: I can send the tests I used. It's a way to avoid writing new policy.
	I'll send you basic config file that I have been using.
     GW: you'll post to the list?
     JL: yes, I'll post to the lspp list. if you want additional settings, you
	will need to write a policy. eventually we should put something about
	users, and how to use something other than user_t.
     GW: thanks. makes sense . I don't think there are any issues with secpeer
	data gram, any one knows if it's in
     JL: I haven't seen anything
     GW: as far as I know, I think it is slated to make it. Any fun with xinetd
	Steve?
     SG: I have the patch working on it, but I shifted priority late Friday, and
	started working on audit userspace. I'll try to get the xinetd as soon
	as I get audit patch out the door
     GW: what's the thinking about the polyinstantiated ports now. I can't find
	the discussion we had earlier.
     JN: I can tell you about that. We had that one feature about trusted solaris,
	you can combine polyinstantiated directories and ports, and it works. we
	never actually had it, Ted and I did work on trusted solaris, and it was
	nice, it is nice feature to have. but if it is competing with CIPSO or
	network labeling, then those are more important than polyinstantiated
	ports. I haven't been wanting to ask for them because we are at risk of
	not having trusted networking at all
     CH: Joe is right, they are nice to have, but there are other things that are
	more important
     GW: even if not for this evaluation, then maybe keep it on the radar.
     JN: I was hoping someone can ...
     CH: I was hoping it will be there with containers, and polyinstantiation
     JN: would it make difference if more of us looked at Paul's code on net dev
     GW: yes, it will be very helpful. people who are on the field, your comments
	carry a lot of weight
     KW: especially since the requirement is to deploy selinux in environments
	that you couldn't deploy it in before
     JN: I think not having the labeled networking make this a bogus
	certification.
     GW: we need to do what ever we can to help the networking stuff go in as
	much as we can. if not 2.6.18, then we should at least try, but we also
	have to have fall back positions. And we probably need to discuss what
	those fall back positions are.

ipsec-tools:  SPD dump and racoon base + MLS
=============================================
     GW: still need to keep spddump on radar, but there are bigger issues, as dev
	allocation. I saw patch from Dan, but I don't think it was renamed.
CH : ...


Self tests
===========
     GW: self tests, I need to get back on that, but I've been working on bigger
	machines and am considering that to be a high priority


VFS polyinstantiation
=====================
     JD: I need to send the patch for newrole. newrole uses pam but not the
	session management of pam, so should be a simple patch. I am also
	playing with some new rules so that people can try. it's in rawhide, so
	people are testing it
     JN: after setting up some stuff, I was getting better results
     JD: ...
     JN: I am still not getting what I consider consistent results between ssh
	local and remote, su and login. I'll give you more feedback on that
     JD: ssh used to stack the pam module which it is not doing anymore. with
	lack of that, you are Dependant on policy. I'll look at it and ask
	questions on list
     JN: that would explain why I get different results every time
     JD: getting different context
     KW: curent newrole behavior is that you stay in same context as you log on.
	if the directory you are in doens't exist, should we have logic to
	handle that
     JD: I think it goes one level higher, but I'll look at it
     KW: I think it might be nicer to have it fail rather that changing directoy
	since people might get confused. I'm flexible on that, as long as if it
	is visible
     GW: what about cron, have you heard from maintainer
     JD: no, I am waiting for the vixie-cron overhaul, but so far haven't heard
	anything
     SG: Jason is still on vacation, that's probably why you didn't hear anything
	yet

     GW: Ok, any issues we want to bring up
     SG: not really an issue, but lspp.39 is built, and I'll post that
     GW: you recommend I move to that for bench marking
     SG: only thing it has different is the two patches
     GW: that will have cipso as well ..?
     SG: yes
     LK: steve, have you seen the patch on object labeling
     SG: yes I saw that, but I didn't include this so that we don't have many
	changes. I forwarded to Dustin, since we talked about this earlier.
     GW: did you hear from him steve, I know he is working on another project
     SG: not yet, I just forwarded this afternoon
     CH: there was original implementation on filters .. but I think it fell
	through the cracks
     SG: I was backtracking to see if it did fall through the cracks, or we made
	a decision about it. I'll include that next time. but we still need the 	
	userspace.
     CH: any idea on names is great, I wasn't thrilled with the ones we had.
     SG: We were talking about subject, user, role, and sensitivity all matching,
	and I am trying to figure out why we ended up with what we got. If we'll
	have 10 different things, we need to drop the <-t> off it so it will be
	easier. Outside of us, who is really using this stuff?
     KW: one note about restrictions, RBAC only talks about roles for subjects,
	and maybe that's why we didn't talk about roles for objects

     GW: any other stuff we need to discuss .. alright .. thank you all. We will
	not have a meeting next week ...