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
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
Note: The line was breaking up through out the call, so there are some sections
I missed.
