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

[Loulwa Salem <loulwas us ibm com>]

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

  Janak Desai (IBM) - JD
  George Wilson (IBM) - GW
  Loulwa Salem (IBM) - LS
  Debora Velarde (IBM) - DV
  Michael Thompson (IBM) - MT
  Joy Latten (IBM) - JL
  Thiago Bauermann (IBM) - TB
  Fernando Medrano (IBM) - FM
  Nikhil Gabdhi (IBM) - NG
  Al Viro (Red Hat) - AV
  Steve Grubb (Red Hat) - SG
  Irina Boverman (Red Hat) - IB
  Dan Walsh (Red Hat) - DW
  Lisa Smith (HP) - LMS
  Linda Knippers (HP) - LK
  Amy Griffis (HP) - AG
  Matt Anderson (HP) - MA
  Paul Moore (HP) - PM
  Klaus Weidner (Atsec) - KW
  Darrel Goeddel (TCS) - DG
  Venkat Yekkirala (TCS) - VY
  Joe Nall - JN


Tentative Agenda:

Kernel update
=============
    GW: Al, if you can give us an update on kernel
    AV: there has been another round of merges upstream. not much, 4 patches 	
	went in	right now. I'm finishing up stuff that does lazy work in case we
	have no	rules. That is what Jason's patch tried to do with slightly 	
	different approach. Instead of trying to check number of rules and avoid
	going into audit on syscall entry, we do that call unconditionally and
	mark audit context as made when there had been no rules. After that, in
	a lot of places we check for audit context non-null and not marked as
	call made when no rules, most of them but not all of them. This allows
	to avoid more work than Jason's, it generates fairly complete audit
	records. We may not want special type for these, we don't generate
	auxiliary records for ipc, namespace, etc. We do generate main part of
	records. everything that had come from SELinux. Anyway, that is going to
	be complete today or tomorrow, and will go into lspp kernel and see how
	it works at least that should be safe. Another new thing that went in
	(I'm trying to figure out what had been done in last 2 weeks and what
	prior), definitely during last 2 weeks, is syscall classes. It is already
	in mainline. Now can have arch declare set of syscall numbers, actually
	several such sets. Userland can specify set in high order bits.
	Currently, there are sets for syscalls that modify some directory and
	syscalls that modify attributes, and 32-bit counterparts of those. It is
	in its current form, fairly easy to modify those sets when new syscalls
	get added to kernel. Changes are only in 1 place (asm/generic). Adding a
	new syscall for all architectures, is just a matter of adding few lines
	to corresponding header. It also now gives 2 classes + 32-bit
	counterparts hooked only on i386, amd64, and ???. Will need to add
	similar pieces to other arch's we care about. This can go in after freeze
	trivially. The problem was getting the infrastructure into Linus' tree.
	Steve told me stuff to add userland bits that would use it. That
	conversation was today, and I don't know how soon it will be testable.
    SG: I think I'll get that out today or tomorrow
    AV: Of course we need to decide what other sets of syscalls are interesting.
	What sets of syscalls are needed to implement interesting things.
    SG: the same ones we had in rhel 4. We can add to those syscall classes but
	need to make sure we preserve backward compatibility. Any other
	classifications beyond that is icing on the cake and we can discuss on
	leisure.
    DW: with the changes you are making, will it allow us to run audit by
	default
    SG: yes. Al gave the long version, but the short version is that this is the
	enhancement that allows us to operate with no audit rules and with just
	selinux generating rules.
    AV: yeah
    SG: one other thing I like to point is that as far as I can see this is the
	last changes for audit kernel work which takes care of performance
	updates and syscall classes. If there is anything else there, please let
	me know so we can deal with it soon.
    KW: for audit you mean, or in general?
    SG: yes, audit. later this week, I'll switch to a 2.6.18 based kernel. I was
	waiting to resolve some problems before I switch. When we switch, I
	don't expect us to be carrying alot of patches. So we can start opening
	bugzillas, and track things that way since all is upstream.
    KW: From a timing perspective I expect us to have minor updates and fixes
	later on, so it's good to have an interim kernel to fix those quickly
	rather than waiting for upstream acceptance for each fix.
    SG: yeah, but we can track them with bugzilla.
    AV: correct.
    GW: Steve, are you looking for same sort of regression testing that we did
	last time?
    SG: I think Al said he knows how to test the syscall record.
    GW: so it's a complete record with no auxiliary record
    SG: we are going to want to do regression testing, but we won't have new
	records. I do need to have auditctl updated so we have the -p option to
	have backward compatibility. hoping to have -p in new release either
	today or tomorrow
    GW: great. that's alot better than partial record. I'm sure people won't
	complain
    KW: there was a discussion that open syscall is not working, have you seen
	that?
    AG: I took a look at that. When you do an open, you do a lookup, and it
	looks like it is getting the wrong inode number. looks like we need a
	new hook in open_namei, I am not excited about that, but that's the only
	way I see now
    KW: Ok. thanks for looking into that.
    GS: Any new audit issues? Steve you said you'll have new audit out soon
    SG: yes. I am also trying to take care of bug with -r option that we saw
	last Friday. I also made changes to audit dispatcher. That's really what
	is driving the work on the new audit version. Audit needs to be out this
	week in order to make it into fedora core 6. if anyone sees anything
	wrong, please let me know.
    GW: Speaking of fedora, would you recommend we base our installation on
	rhel5 alpha
    SG: fedora core 6 test 2 (FC6T2) is fresher than that. At this point I'd
	lean towards FC6T2. The alpha is a snapshot in time, and there will be 	
	compile and linker changes, so they are planning to rebuild all the
	packages soon I believe.
    GW: so we'll hold off on rhel5 alpha
    KW: we'll try to get feedback to you. I think we have a bugzilla on archs
	with 64bit. There is a nasty mix of 32 and 64 packages that are getting
	installed.
    SG: I need bugzilla number for that, I wasn't aware of it. I need to talk to
	people here; seems they are pushing the other way to have 32 bit
	packages on 64 machines for development. Developers have been asking for
	this in order to be able to develop 32 bit application on 64 bit archs.
    KW: But it's a nasty issue, for example the pam modules contain binaries so
	if you install both 32 and 64 bit packages, they are getting 	
	overwritten, and you end up with what binaries got installed last which
	may conflict with the library you have. When you try to clean up and
	remove them you end up with a big mess, and possibly an unusable system.
	For certification you need one package version.
    SG: if you can point me to that bugzilla so I can take a look at it.
    GW: not sure if we have bugzilla, Mike sent you a note I believe before the
	4th holiday
    MC: Yes I did, but I don't know if there was a reply, I'll check
    KW: we need to make rhel friendly, to make it allow for minimal install
    DW: in rhel5 you can click and get really minimal install, it's almost
	unusable.
    KW: I need to look at it, but since it is yum based install, it happily
	pulls all sort of dependencies.
    DW: you can go to install screen and unclick everything
    KW: I like the base option, maybe dependencies to development tools are
	aggressive
    GW: on mine I believe it installs 32 and 64 packages
    KW: we'll get more info to you on that
    GW: and we'll get a bugzilla on that as well


AuditFS/inotify
================
    GW: Lisa, wanna give us an update on that please.
    LSM: Sure. It's going well. I gave updates to steve, also sent him man
	pages, and it will be included in next version. it's done now, I'll
	download the latest audit patch and try it on my system to double check.
	One thing left is if people want me to update the application, or they
	prefer to update them themselves. I'll send a note to the list about
	that.
    GW: I doubt people will turn down help. Thanks for your work.


Print
======
    GW: What's going on with print Matt?
    MA: It's going well, Dan took a vacation at the right time, otherwise I
	would be asking him all about the policy. But it was good, I learned the
	policy alot the past week, and got my enforcing mls system to where I
	wanted it. Today I actually got it to only display jobs you are allowed
	to see. The only gotcha is that I get that when running as sysadm_r
	rather when I am running from init. Dan, I'll send you some info to help
	me fix that.
    LK: Are you talking about cups daemon
    MA: no, it's the lpq. if I start it from init I can't communicate to it.
	I've gotten rid of all avc messages so now I don't get messages about
	being denied. it works from sysadm_r role but not from the init.
    DW: you are able to do "service cupsd start" as sysadm?
    MA: I can do lpq from user, root, sysadm and all sorts of different roles. I
	think sysadm_r is able to communicates to selinux netlink socket. It
	appears to be working with exception of some policy issues regarding
	lpq. once I fix a few minor things, I should be able to get a 1.2
	version out for people to try out. I also started looking into a
	targeted system, it seems to be working well. I'm liking where it is
	right now. I'll talk to Dan about the policy issues, and it should be
	all set.
    GW: great, good to have the policy out. Are you looking into putting a
	release out this week?
    MA: yes, should clear all the issues this week.
    GW: great, thanks


SELinux base update
===================
    GW: anything you wanna tell us Dan?
    DW: not really, I am catching up after coming back from vacation.
    GW: Ok, any mls policy issues this week?
    DW: Mike and I communicated a bit, We had an issue where secadm can read
	audit library while auditadm couldn't in system low. This is kinda
	strange, and not sure if that is problem or not.
    KW: you shouldn't get any privileges you didn't ask for, but if this
	behavior is clearly documented then it's ok.
    DW: secadm doesn't have to go to systemHigh to read the audit library, while
	auditadm does.
    KW: I'm not clear on why it is this way, looks like you gave mls overrides
	to secadm
    DG: we might want to look at that, maybe do a transition to another domain
	to limit the power of the user.
    DW: we can do that by change con.
    KW: I don't see a fundamental problem with having it be an override, but
	people need to be careful on who uses secadm.
    MT: what about adding standard selinux users or associating unix login? Only
	sysadm can do that.
    KW: argument about moving defining selinux users into the sysadm role, t has
	been fuzzy distinction between sysadm and secadm.
    MT: distinction between having sysadm adding unix user, and secadm adding
	selinux user is that, users are at level 0 and can't do anything when 	
	they log in.
    KW: We reached consensus that default roles are what is on the system, and
	if people want more restrictions they can create users. I'm neutral on
	that as long as it is documented well.
    DG: secadm can load policy. Aren't we giving secadm root powers basically, I
	mean if secadm doesn't like the policy they can just load another one.
    KW: In a way yes. It's perfectly ok that admins with hostile intentions be
	able to breach security as long as it is not by accident (We assume a
	trusted admin)
    MT: The point is that you don't do anything by accident.
    GW: what about the pty issue, we reached a conclusion on that?
    KW: sounds as if newrole -l is broken. Casey had good summary of the issue.
	if you are doing labeled networking, once you do new role to change
	label, then it should end all communication. you either need some nasty
	overrides, or if not, you won't have IO on your console. you can use
	newrole to have your labels match. if you want to do labeled networking
	with secure shell you have to end up with the right level when you log
	in, since you can't change it later. At the moment I don't see how this
	will work smoothly. Alternately you can give override capability to
	sshd, but you have to be careful about that. Main issue was that now any
	normal user can use pty to declassify information. System currently
	allows pty to use multilevel devices that undermine mls policy which
	should be fixed in new policy that will break current things like
	newrole.
    GW: so no solution right now?
    KW: if we get a tighter policy we should restrict the multilevel devices. So
	you log in ssh and stay at that level; you can use virtual consoles and
	have each at a certain level.
    GW: is there precedence to have users log out and back on to change level
    KW: most systems don't seem to permit dynamically changing your level.
    GW: alright, I think we need to discuss this on list some more.
    KW: two things that might be useful, ployinstantiated ports, or if trusted
	program can do a wild card open by accepting network connection at any
	level.
    GW: that's dangerous, we need xinetd to do that
    DG: we have something similar.
    KW: Is there a set of patches available
    DG: Venkat is working on current patches porting to use ipsec base, by
	Wednesday he should have that out.
    GW: Is he planning on releasing an sshd patch as well
    DG: I'm not sure how all that fits. It will take a level of connection and
	label socket correctly, it will limit level of child as well.
    PM: netlabel patch does the same thing almost, if someone wanted to try that
	they could
    DW: do you prevent them to use new role then?
    KW: I don't think we need to prevent it as long as newrole prevents info
	being sent to the socket.
    GW: this deserves more thought and discussion and we need stephen's input
    KW: so it's a heads up, there might be more code changes to be put in to
	make this work
    GW: yeah, changes to sshd which we were hoping not to touch.


CIPSO
======
    GW: Paul, what's going on with CIPSO?
    PM: New patch out. steve and I had a back and forth discussion on right way
	to handle the whole parent/child nightmare. I took his comments into
	account and incorporated the, but I haven't heard anything more from
	him. This should be the last round of issues. last two remaining issue:
	how to deal with unlabeled packets? there is also another question of
	finer granularity regarding selinux checks. There is not much code to be
	written, but any new code will break backward compatibility. There is a
	RH bugzilla 195238, about adding new selinux features without breaking
	backward compatibility. Aside from feedback, I think I'm done with net
	label stuff with for this evaluation at least.
    IB: when do you think you'll have all changes completed
    PM: as soon as we get all the issues resolved, I can have it done soon. if
	it is resolved today, I can have the code done by end of this week
    GW: great, sounds good. Thanks


IPsec:  MLS, UNIX domain secpeer, xinetd
=========================================
    GW: Venkat asked for testing help. joy and I worked with fernando to set up 	
	tahi. found bug on ipv4 and ipv6. so far it's looking good
    FM: yeah, bugs I found were fixed with venkat's latest patches
    GW: now we are setting up udp to work with xinetd. are you getting enough
	testing on cipso paul?
    PM: Ted and I have been working on it. Every once in a while, if people from
	IBM with trusted AIX can check every couple of kernels to ensure I
	didn't break anything real bad. But I think it is ok from a unit test
	point of view.
    GW: we've been focusing on ipsec. joy was going to try to run stress tests
    JL: I am setting them up as we speak, I'll set them up before I leave today.
    GW: are those gonna be in enforcing
    JL: yes, I 'll first make sure nothing regressed, once that is checked I'll
	check with latest policy
    GW: Venkat you on?
    VY: yes. I should have a patch out today. Tomorrow I am planning to clean up
	the whole thing, then break it up for upstream submission
    SG: James morris was interested in seeing patch posted to netdev and audit
	list
    VY: yes, I'll send it to netdev tomorrow or day after
    SG: Steve Mill(??? not sure about the name) said he is willing to review
	your patch. also James morris was looking at patch on netdev. So please
	make sure patch goes out to netdev. if you have to do two patches, one
	for us to test with and one to submit, then I say go ahead and do that.
	the netdev guys are interested in driving this one home and finishing up
	work on it, also we need one to test with. so please send to netdev.
	James wanted me to say that this is going to be needed to get done soon,
	since this is past deadline, but we are accommodating it so we need to
	move quickly
    LK: so is the network patch going in the git tree?
    SG: Ah, I don't know. Maybe it is possible to do it as stunnel kind of thing
	where cipso is done in userspace.
    PM: steve, that is ugly
    LK: we posted patches and expect it to be taken seriously
    IB: we are trying really hard.
    GW: from IBM perspective we would really like to see the patches there as 	
	well
    LK: we are not dumping this code, we are maintaining it, so I don't see what
	the problem is.
    IB: It would be helpful if we have an impact statement to prove the business
	case.
    LK: well we did that, we had customers on the phone also backing this up.
    IB: if your business organization has a document to prove the business case,
	that would help alot.
    GW: if people with customer contact can give feedback, it would help too I
	believe.
    SG: that's what I was saying about the issue tractor. we need people to look
	at it. I think I have two levels of management on my side saying we need
	to get this on .
    LK: who is the next management level name name, send it to me please. I need
	to know my escalation path.
    GW: anything we can do on our side to push this further
    SG: you guys have done very good. Klaus' statement was really good. All we
	are missing now is numbers.
    IB: there are also test results, if we can show these
    GW: we have not done much cipso testing, but we can do some if there is a
	need
    PM: they did that and posted results a couple of weeks ago, I think on net
	dev
    LK: George, maybe you can do something with your RH alliance path to push
	this.
    GW: also I know some people might not want to share numbers in public, but
	at least if they can share it with you Irena. The business case is
	there, it's just a matter of demonstrating it to those people with the
	strings.
    LK: It had both technical and business issues. we solved technical issues,
	and now we need business issues taken care of.
    GW: we'll try our best. what about xinetd steve?
    SG: I'll try to work on that and get one out before I head out to OLS. I'll
	be out starting Friday for that.

ipsec-tools:  SPD dump and racoon base + MLS
=============================================
    GW: we still have the spd dump issues but that is secondary to network
	issues. Anyone tried device allocator especially with print? I think
	that should be interesting to see how it works.


Self tests
==========
    GW: I got back to that this weekend. but I've been working on performance
	tests. I should get new self tests in the next few days.


VFS polyinstantiation
======================
    GW: Janak, anything new for polyinstantiation?
    JD: couple of minor things. pam namespace module was accepted upstream. I am
	testing namespace with policy changes and playing with tight member
	rules. I'll be sending patch to newrole, because it's not using pam for
	session management. It's upstream and people are testing it
    GW: cool, any word on cron?
    JD: no, still waiting on maintainer.

    GW: big thanks to Amy for all her work. we just need to get all remaining
	items closed. other issues anyone wants to bring forward right now. Ok,
	let's adjourn the meeting. Thanks everyone.