07/31/2006 lspp Meeting Minutes:
===============================
Attendees
Janak Desai (IBM) - JD
Loulwa Salem (IBM) - LS
Joy Latten (IBM) - JL
Debora Velarde (IBM) - DV
Michael Thompson (IBM) - MT
Thiago Bauermann (IBM) - TB
Nikhil Gabdhi (IBM) - NG
Fernando Medrano (IBM) - FM
Al Viro (Red Hat) - AV
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Robert (Atsec) - ROB
Darrel Goeddel (TCS) - DG
Chad Hanson (TCS) - CH
Venkat Yekkirala (TCS) - VY
Tentative Agenda:
Kernel update
-------------
JD: George is not here this week so I am running the meeting in his place.
Al would you please give us a kernel update
AL: latest audit stuff seems to be working fine so I sent it to Linus
SG: Is the lazy audit patch in the queue for Linus to take in for 2.6.18?
AV: yes
SG: I'll get together a .46 kernel today. I'll release that so everyone has
something to sync up to. We'll do another one with net labels and ifsec
patches.
AV: anything new on the debugging of the audit string problem?
SG: turned out to be user space problem, sorry about that. It was a bug in
audit search parsing piece. I had it on my to do list, and didn't
realize it was dropping text. Also I am working on getting -p option for
syscalls into audit. As far as I can tell, the code associated with it
is still untested since there is no option support for it in userspace.
This is the highest priority I am working on; I don't expect problems
but you never know. I am planning to get that working tomorrow, and send
a new user space package tomorrow, the new package should take care
of the untrusted string everyone was seeing. It should also have the -p
option for people to test with. By end of this week we should be able to
do real regression testing. I think -p is the only option that is not
available in rhel5 that was in rhel4. This should cover the kernel and
audit userspace discussion as well.
AuditFS/inotify
---------------
JD: anything Lisa on this
LS: Nothing on audit notify. Amy is not on the call so maybe you can ask her
about that if she joins later.
SG: I think these issues need to be taken from the agenda. Our work on them
is done and if there is anything about them, then they are considered
bugs.
JD: Ok sounds reasonable.
LSPP kernel issues
------------------
Audit userspace
---------------
JD: you already talked about that Steve, so we'll move on
Print
------
JD: Matt, anything new?
MA: last week, between Linda and I, we determined a method for rendering
postscript to handle it properly. Using configuration files only, we can
successfully render postscript to pdf and back and apply labels.
unfortunately, while working on that, we found a problem printing to
foomatic devices. Before we were using local printers and it wasn't
using foomatic, so we didn't see this; now if you print anything that
needs to call foomatic, the job just hangs, certainly not good. Once I
debug and fix that, I plan on releasing a new patch based on the latest
1.2.1-4. I also got good feedback from Tim and Klaus, I made these
changes and just wanting to see if there are any software bugs that I
need to take care of.
KW: could you document those config entries you talked about in the
postscript config man pages with the next patch please
MA: I was also planning on documenting it in a web page, but I'll also
include it in the patch.
SG: I am wondering about the timing of the patch, any idea when it'll be
available
MA: as I said the bulk of it went in. Seems it missed rhel5 deadline, but we
talked to Irena to check if it went in
IB: Yes, it should be in.
SG: We might have a short window maybe 24 hours or so that you can use to
send incremental patches, so the beta test that goes to everyone is a
little bit better. There is opportunity for maybe next day or two to get
couple of updates in
MA: All the suggestions I got, I put in so far. I am not sure if I should
send one update, or many smaller ones. I don't think I'll have any code
changes to the fix the foomatic problem but I'll see how things go, and
maybe submit a patch soon
SG: I don't think this is a problem
MA: I'll try to get the fix out tonight
SG: see if you can get it in beta. also ask Tim to see if he can get it in
fc6?
SELinux base update
-------------------
JD: is Dan on?
DW: yes .. I'm here. crontab is broken and I am fixing it now
JD: yes, I had issues with it and needed to add few things to make it work.
I thought maybe I was doing something wrong.
DW: No, there are many issues with it. Right now, crontab writes to /tmp and
creates files with wrong context. So I am working on it as we speak
JD: There were another issues that were brought up last week, anything new
with that?
KW: The issue was about making policy more restrictive for MLS to disable
multilevel objects for untrusted users. It is still apparently an issue.
I posted a program to expose the problem using newrole scripts. Maybe
there is a missing check in selinux that is causing the problem
DG: I saw your post. I think these are two separate issues
KW: I agree it is entirely possible they might be separate issues. The good
thing is that making the policy more restrictive didn't break anything.
DG: Biggest thing of concern are things in /var/run and daemon startup.
There isn't a way to differentiate between privileged and unprivileged
user from a trusted perspective
KW: from an evaluation perspective, admins could be permitted to access
multi-level objects, as long as the normal users do not have this
privilege
DW: Is there a patch available to turn this off
KW: I have a patch included in the email I sent to the list.
DW: to get rid of multilevel objects
CH: ok, we'll test this more
MLS policy issues
-----------------
Roles
-----
JD: Mike anything new on that. I've been using it and the separation seems
to be working.
MT: I have no news, I haven't been working much with policy lately, been
more audit focused.
DW: There is a change making newrole not a login shell and that change went
in Friday. It's a nice thing and allows you to use /etc/profile to see
what shell you are working on. Wonder if that might affect the behavior
klaus was talking about earlier with scripting newrole.
KW: what package do I need to pick up to try this
JD: policycoreutils provides newrole I believe
Kw: I'll try it, but my feeling is that it's different.
CIPSO
------
JD: Any CIPSO news Paul?
PM: Good news. I got feedback from David Miller and others, the feedback
looked good. There are a couple minor changes. Dave Miller said once a
few things are taken care of, he'll put the patch in 2.6.19. which is
encouraging.
JD: That's great. Paul, last week you said you were looking into a problem
Joy was seeing, any progress on that, have you heard from her? or is
there something I need to follow up on?
PM: if you can follow up that would be great.
JL: I am here. Paul, I never really got a chance to check the patch on the
latest kernel. I think my problem was that I had 2 policies on my
machine. I think that had something to do with it.
PM: Ok, unless you narrowed it down, my recommendation is not to worry about
it now, the code will be changing in the next few days anyway.
JL: yeah, I thought I'll wait for the latest kernel, and test with latest
kernel that has yours and Venkat's patch.
PM: my push now is to get something for dave miller to put in his tree. once
that is done, I'll work with steve grubb on porting the patch to lspp
kernels
IPsec: MLS, UNIX domain secpeer, xinetd
-----------------------------------------
JD: anything new here?
VY: mls patch went into 2.6.19 -mm tree
JD: great. looks like things are falling into place
ipsec-tools: SPD dump and racoon base + MLS
---------------------------------------------
JD: joy do you report on this?
JL: Venkat you need to send a racoon patch. ipsec picked up my patch, but
not the racoon patch, and we need that. I'm gonna resend it and say it
is needed for another patch and see if they take it.
SG: who are you planning to send the patch to, Red Hat or upstream?
JL: I'll send it to ipsec tools mailing list to the maintainers. I got the
list from sourceforge, and that's the only way I know how to do that.
SG: if the patch is in good shape, we might pull it in and get it in beta
patch also. we have some time maybe 24 hours that we might be able to
put a patch in.
JL: ok sounds good.
Single-user mode
-----------------
JD: Dan you mentioned last week creating a boot flag, did you work on that?
DW: I talked to few people then dropped the ball. I'll get back to doing
that. I was looking at the flag auditfs_chk(??), if set, then we check
for an environment variable, that indicates a crash and then go into
single user. That's what we agreed on .. right?
KW: yup that would be fine
Self tests
----------
JD: I believe George was going to send out a patch.
SG: From an email he sent me on Friday, he didn't do anything.
VFS polyinstantiation
----------------------
JD: pam namespace is upstream. I sent out a patch to newrole which was not
using pam namepsace. The patch will make newrole use pam session
management. As far as cron, I started testing, but ran into some of the
problems we talked about earlier.
SG: something about cron, turns out the maintainer of cron is no longer with
RedHat. A new person will take over that work, I already talked to him
just in case we have any issues, I'll send you his email address, he is
also the maintainer of xinetd. Ok, so it turns out Jason never finished
work to incorporate vixie cron. Maybe the at daemon needs a patch
similar to the vixie cron, I think jason was gonna work on that, but
there is no one who is knowledgeable enough to do the work. so if at
daemon is going to be in the security target(ST) it will probably need
polyinstantiation as well.
JD: I thought that we were not gonna put it in ST because it is a wrapper
for cron
SG: but it is not going to be now
JD: right, how much time do we have to submit a patch.
SG: might be able to pull it by beta2. so we have about 2 weeks
DW: why not drop it from ST, we have cron, why do we need at
KW: that sounds reasonable. I wouldn't miss it
KW: the issue is if there are certain users for at?
LK: so you would drop it all together rather than having non mls at?
KW: I would recommend dropping it all together
LK: would we have packaging issues if we don't have at installed?
KW: you can have it installed just not running
JD: any other issues. if not, then we are done. we must be getting closer.
KW: short comment on cron. Important thing is that the new level should
dominate the lower level. you should not be able to put jobs at the cron
tab that run at lower level than cron tab runs at. Doing it this way
breaks integrity, since this is a kind of write up operations. it is ok
with lspp but just not the way things are being run so far.
JD: ok
KW: so it's lspp compatible, but if you want additional integrity
restrictions, I don't know how to do that.
JD: ok
KW: This is just for your information, but I don't think it will affect
certification. one way to fix this is to request a password for cron
just to make sure it is not invoked unintentionally.
JD: it will be different from how cron operates and not sure if maintainers
would like that.
KW: this is just for additional paranoia and that's why I wanted to bring
it up
JD: ok, Thanks Klaus. Anymore issues? alright let's adjourn
Cron, tmpwatch, mail, etc.
--------------------------
More than 90% complete
Remaining tasks
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
