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

Loulwa Salem loulwas at us.ibm.com
Tue May 23 21:38:02 UTC 2006


Note: The line was breaking up through out the call, so there are some sections 
I missed.


5/22/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
    Michael Thompson (IBM) - MT
    Irina Boverman (RH) - IB
    Lisa Smith (HP) - LMS
    Fernando Medrano (IBM) - FM

Tentative Agenda:
=================
No meeting next week
     GW: We are shifting the agenda a bit this week. Dan Walch will give
	an update on selinux first, then we'll go back to the kernel update.

Kernel update
=============
     GW: Al, would you like to give a kernel update?
     AV: There has been some work on getting stuff in -mm tree, that appears
	to be going well. The only thing not in -mm are Amy's patches, but
	hopefully I'll put this this week. There had been some fixes that were
	posted on the linux-audit. Also just today there are a couple of patches
	from Amy that still need to be tested. Put them in the lspp queue so
	they don't go to -mm right now, Steve is building a kernel now with
	them. Hopefully we'll get some use within a day or two. Eventually the
	plan is to push them into the -mm as well preferably before the linux
	2.6.17 final release so that stuff can get some testing in -mm before
	the big merge.
     SG: I got the lspp.27 in the build system. I'll try to push it out tonight
     AV: there is one issue regarding pending patches. Amy mentioned that she
	suspected that startup of kaudit might be racing. We need more details
	but hopefully it is being fixed and dealt with now.
     GW: ok, thanks Al, hopefully we are getting a bit closer now.
     AV: just one more thing, there has been a request for watching an entire
	subtree. The situation is rather unpleasant, people are asking for it,
	but they won't say what they want to happen. I wouldn't call it a corner
	case, just a pile of cases that are very ambiguous as to what is wanted.
	All requests of that sort are put on hold until those folks decide what
	they want. There is a bugzilla for it, but we are still waiting for
	people to step up and say what is happening on different cases.
     SG: As it turned out there are some nasty problems with malloc, also some
	problems with polyinstantiation. That's the kind of problems in the
	bugzilla. I think one of the things we need to do is define what our
	requirements really are.
     GW: I take it you mean beyond just lspp?
     SG: Yes, we don't need to define it in today's meeting because there are
	other things to consider  the file system audit and other stuff like
	that, but in the future.
     GW: Yeah, I agree. I have the same sort of questions about my patch, how
	much data is too much data? yeah we should visit that in the future

AuditFS/inotify completion
==========================
     GW: Is Amy on? how is this going?
     AG: Yes I'm here. I sent a couple of patches out a few hours ago. At the end
	of last week I was working on the move problems; I found a few other
	bugs that I fixed, I sent those patches out this afternoon. Next one
	I'll address is the problem with missing audit record for remove,
	hopefully I'll have a patch tomorrow, it shouldn't be difficult. Next
	thing is do the filterkey, but I also want to work on inotify.
     LK: Do you have a list of work to do with the inotify patch
     AG: The last set of patches I sent out, while looking at the way I was doing
	the ref counting, I found a problem. Now they are both using the same
	set of ref counts. When doing a remove, it seems I am getting sleep and
	context errors. I was looking at that before the meeting, and will
	continue to look at it after.
     GW: Ok Amy .. thanks for the update

LSPP kernel issues
===================
     GW: Any issues with the current kernel? I put it on machine over the weekend
	and it looks pretty good. I also sent a request on Jose Santos to
	profile the .25 kernel, I believe this is the one without debug turned
	on. I will need to set up a system for him to run the tests.
     SG: Do you have a saved copy of it somewhere?
     GW: yes I do
     SG: Ok good because as I put the new kernels out, the older ones are getting
	removed.
     GW: yes I downloaded them. when is the next build you'll turn debug off?
     SG: I can do it anytime, but with all the new code I thought we need debug
	on.
     GW: I'm trying to find a large machine to test this. I need to verify
	another problem that apparently been fixed. if I get a 64 way, I'll try
	to test the scalability vs. CPU usage issue.

Audit of POSIX message queues
==============================
     GW: I put a not very pretty patch for this. Steve and Tim sent me feedback
	and I put them in over the weekend. The issue is how much data we need?
	I'll address the flaws, put it out there with the code it has, if we
	want to reduce it later it'll be easier to remove code rather than
	adding new code. I'll put it out tomorrow.

Audit userspace
================
     SG: I was curious about Mike's problem, the very fist rule doesn't take, and
	the rest do. We need to patch and build a kernel for Mike to try it
	with. Mike, do you need us to patch and try this?
     GW: Mike just stepped out of the room for a bit, but Lou was the first who
	saw this problem. I am testing on ppc64, and I don't see it, but Lou and
	Mike saw it with x86_64, and i386.
     LS: Steve, if you have a kernel with additional debug on, I can test with
	it.
     GW: there is a kernel that should work right now.
     SG: But we need to patch a kernel to get some more debug info. Need to put
	some printk to see which function is causing this issue.
     GW: which functions, maybe we can put it in ourselves
     SG: It's all in the email I sent out. Other than that I am working with
	audit. I fixed all the bugs that Mike reported. still working on some
	issues. I'll have another userspace one out later this week.
     GW: Mike just came in the room. Can we put some printk in the kernel and see
	what is going on with the problem you were having.
     MT: I'm not sure which kernel I was testing with, let me check. I believe it
	was lspp.25; I'll update to .26 and post what I find on the list.
     GW: ok thanks
     SG: Mike also had some questions about clearance, if Darrel is on the call
	we can sort those out as well
     DG: yes I'm here, I haven't got a chance to look at it.
     MT: se-user, se-role, and se-type are clear, what about se-sen, and se-clr?
     DG: se-sen is what you are currently in. se-clr is the upper level of what
	you can go up to.
     MT: I am seeing problem on audit 1.2.2 audit, and .25 kernel where adding a
	rule for a standard user (s0-s0) and root user (s0-s15:c0.c255) to audit
	the se_clr works for the standard user where se_clr=s0 and for the root
	user where se_clr=s15:c0.c255. However, se_sen does not work for the
	root user where se_sen=s0, but it does work for the standard user where
	se_sen=s0.
     DG: sounds like you know what it's supposed to be doing, so we just got to
	fix it.
     MT: ok then, so it sounds like a bug
     DG: Yes, I'll look and see what I can do.
     GW: Great .. thanks Darrel.

Audit failure action inquiry function
======================================
    LMS: I am doing testing on this now, and I expect to have a patch out
	sometime this week.

Audit of service discontinuity
==============================
     GW: The issue is production of audit records when audit can't be started. We
	also talked about need for run level records there.
     LK: We had a discussion about patching syscalls that make sense. Al was
	working on that and I was wondering what happened with that.
     AV: will bring it today and put it into the tree. what architectures do we
	care about?
     LK: ppc64. ia64. zSeries, x86_64. I can't remember how we specify syscalls
	by name, Steve you know?
     SG: it looks in all the places that it traverses
     LK: For the filesystem related ones you would do the same thing for 64 and
	32 bit.
     SG: that's why we made arch part of the record so we can support something
	like this
     AV: interesting question, not sure what should be done on architectures that
	have a 64-bit and 32-bit at the same time. Audit by syscall number,
	almost always should be thinking about not just syscall number but arch
	as well. Same number may mean something different on 32- and 64- bit
	archs
     LK: I don't know why you would want to audit the 64 bit one and not the 32
	bit one?
     AV: correct, but at some point we are going to run into a situation where
	the same number is different for 64 and 32 bit modes on an architecture.
	Then we will have to split otherwise, it will pull the wrong syscalls on
	the architecture.
     LK: so you might need to turn one rule into two.
     GW: are we satisfied with this, or are we going to continue the discussion
	on IRC?

Print
=====
     MA: We had questions about how the image file will work. I also sent message
	to cups mailing list, and got feedback for cups raster about supporting
	multiple pages. It can be the output of filter without needing
	postscript wrapping, and it won't matter what printer I use. Also I
	started working on instrumenting the access control check. one side
	effect from the discussion on cups mailing list is how to handle
	advisory labels and putting that in cups API at lower level than I
	thought so that Gnome and KDE would pick it up. I am getting ready to
	work on the cups raster image format as output for filter of postscript
	parser.
     GW: do you have any anticipated date when you might produce a new drop.
     MA: not really, but I need to get something out soon. once access checks are
	there, I need to make sure it works with device allocators. next week 	
	I'll go on vacation so I'll put something out before I leave.
     GW: Well, the urgent pieces are the kernel pieces. Thanks. By the way, how
	is the quality of the output looking?
     MA: it did improve a bit. I haven't tried anything with cups raster format,
	it might be better with that.

SELinux base update
===================
     DW: did you try the tools.
     GW: I didn't set them up. Joy is out, but Fernando (our intern) will be
	helping out with those.
     DW: The latest in is rawhide and hopefully that is working. The current
	secadm, auditadm seems to be working.
     MT: what will happen with removing secadm?
     DW: We will leave it in, Stephen Smalley said it is needed by customers.
	Smalley suggested we use a boolean. As far as reboot stuff, I got
	initial approvals, and I sent a patch but didn't hear anything back.
	This is regarding if autorelabel will happen automatically or not.
     GW: once that is in rawhide I need to pick up new init scripts?
     DW: I sent a patch to init maintainer but didn't hear anything back. I'll
	try to ping him. I continue to work on dev allocator. I submitted a
	patch to TCS about renaming stuff; the Fedora guy didn't like it so I
	fixed them. it looks like it should go through but a it's a matter of
	getting the spec files fixed.
     CH: did you resend the patch
     DW: I did, but I 'll resend it. They are all minor nit picky things, we are
	trying to add sanity checks to the packages.

MLS policy issues
=================
     GW: Mike already discussed this, anything else on this?

Restriction of kernel keyring
=============================
     GW: Stephen Smalley brought up that those hooks are not done, and they are
	only dummy hooks but not selinux implemented. We also should implement
	them using DAC.
     LK: was there also a question if this is going to be in RHEL5?
     GW: yes, is there a possibility this is not going to be enabled in RHEL5?
     LK: did you find it not enabled in fedora right now?
     GW: not sure, I build my own kernels. The interesting thing though is that I
	don't see keyrings rpm in either rawhide or FC5.
     SG: it's in the process of getting into extras, they are being nit picky as
	they are doing on dev allocator.
     GW: would you bet it'll be in RHEL5
     SG: yes, I think it will be.
     GW: ok, so we have to restrict hooks in DAC. Stephen concern is that this is
	not sufficient since this is new code. In terms of policy we can have no
	policy for it. I'm not volunteering to write the hooks. Joy or Serge can
	help with that, but I don't have commitment from any of them on that. We
	need to hurry up and get it in .18
     SG: well, .18 is not open. so if someone has time to put a patch out, we can
	put it in.
     GW: we'll have to figure this out.
     MT: I can take a look at it, and tell you tomorrow.
     GW: we can collaborate on it, needs to be done within a week or so. we need
	to take action. We'll restrict it with DAC and see if everything goes
	through proc.

CIPSO
=====
     PM: last week I was finishing up a patch. I will get it out this week. I did
	preliminary performance testing doing simple runs. also a quick stress
	test that I ran it over the weekend. It looked pretty good, there were
	no lock issues. One small problem, in some cases when you create a
	socket, the label didn't get applied, this only happens under really
	heavy loads. I am trying to track this down. I do have one question. one
	of the problems is what to do when I boot up when there is no
	configuration? Right now I leave it unconfigured, but that is not good.
	I see two options: one is have init scripts to do configs before you
	start up networking; the other option is to have the kernel do it's own
	configuration. That might be good for Common Criteria (CC), but for non
	CC it is not interesting.
     GW: I think the system is in permissive if no policy is loaded, it start
	out permissive.
     LK: is there a reason why you don't stick with init scripts?
     PM: if there is no configuration it pukes. Is there a preference? Now the
	kernel doesn't figure anything; it is probably a dozen lines of code to
	do this.
     GW: You can also flip a boolean
     PM: Ok, I'll leave it as it is unless someone complains. Other thing, the
	code is starting to be reasonably mature, about 95-96% of functionality
	complete; at what point we want to introduce to lspp kernel for
	instance.
     SG: if it applies cleanly we can take it in the next build. how do you plan
	to get it upstream?
     PM: I am putting it on lspp list, also the selinux and net dev list. I am
	new to this, so if anyone has suggestions please let me know.
     SG: it's a little different, I want to figure out the strategy to get it
	upstream
     PM: I got some feedback from James Morris and I put in some of his comments.
	He said it is a large patch that needs to be looked at. also Stephen
	Smalley gave me some comments.
     SG: you have to do some configuring in init script?
     PM: that's my question, should kernel do it's own configuration, or keep
	init script.
     SG: It does not work if there are no init scripts?
     PM: yes this is why I am asking? I'll continue to post on lspp and net dev
	lists.
     GW: good idea, Joy will review it and give you feedback
     PM: when are you planning the next lspp kernel?
     SG: the next time something big comes my way.
     PM: Is this big enough
     SG: I guess
     PM: I want to know which kernel I'll rebase on.
     SG: the .27

IPsec:  MLS, UNIX domain secpeer, xinetd
=========================================
     GW: Joy is not here, she gave me a couple of updates by mail: ipsec-tool's
	nethook patches were not compiled correctly into rawhide. She talked to
	Dan Walsh and Steve Grubb about this and will verify it is fixed in the
	next few days. The setkey patches integrated into ipsec-tools CVS, but
	not the racoon patches. she is reviewing TCS's MLS patch to nethooks. It
	is a big patch that has a lot of new functionality in it. So far, she
	think it is quite invasive. Chad, thanks for putting that patch out.
	Trent was going to look at it and provide some feedback. hopefully he,
	Serge and Joy can look at it and provide good feedback. Is there any
	time frame for getting that integrated, needs to happen pretty soon as
	well.
     CH: We did not send that patch to everyone.
     GW: you're right. I just want you to know we are trying to get you feedback
	on this.
     SG: can either you or one of the TCS guys give more detailed update on the 	
	patch other than it is big.
     CH: Instead of specifying one security association, you can put a range of
	security association. You can get different association with each level.
     SG: how does it work with IPSec? are you gonna post the patch to a public
	list?
     CH: yes, but we are trying to get initial feedback.
     GW: steve should we expect feedback from James, is he swamped?
     SG: He is on a Xen project.
     GW: I saw Trent took an initial look at it, hopefully he will provide more
	input. Serge, Joy and him are good talents for looking at this.
	Regarding xientd, Trent posted the patch and steve had problem about it
	not meeting the xinetd way of working.

ipsec-tools:  SPD dump and racoon base + MLS
============================================
     GW: Any word on SPD dump.
     CH: We are tracking it, but been swamped
     GW: Is there anything we can do to help?
     CH: The biggest issue is for SPD tools to work on PMP(?)
     GW: So this may never get accepted on ipsec tools?
     CH: It might be ....
     GW: This will likely be private or linux specific
     CH: This seems right, given how quick they have been accepting patches. This
	is a usability issue, when it is a large database.
     GW: we'll not worry about fixing it for certification and worry about it
	later.


Device allocation
==================
     GW: Debbie worked on it, DW worked on that.

Self tests
==========
     GW: need to get that out hopefully this week


VFS polyinstantiation
======================
     GW: Janak, any updates on this?
     JD: as per pam namespace, I'll add a check so you can avoid attacks by non
	root daemon. Mainly I am trying to get gdm to work with pam namespace.
	From lspp perspective, we don't have to worry about it. I am trying to
	use gdm using polyinstantiation.
     GW: as long as we are good for certification now, we'll think of this later.
     JD: we need to find out what can be done without using it.


Cron, tmpwatch, mail, etc.
==========================
     GW: Anything here?
     JD: cron is not in rawhide.


GW: we are better than 90% complete, 80% upstream




More information about the redhat-lspp mailing list