[redhat-lspp] LSPP Development Telecon 06/19/2006 Minutes
Loulwa Salem
loulwas at us.ibm.com
Tue Jun 20 00:20:44 UTC 2006
6/19/2006 lspp Meeting Minutes:
===============================
Attendees
Janak Desai (IBM) - JD
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Lawrence Wilson (IBM) - LW
Thiago Jung Bauermann (IBM) - TB
Nikhil Gabdhi (IBM) - NG
Stephen Smalley (NSA) - SS
Al Viro (Red Hat) - AV
Steve Grubb (Red Hat) - SG
Irina Boverman (Red Hat) - IB
Dan Walsh (Red Hat) - DW
Paul Sutherland (Red Hat) - PS
Chris Runge (Red Hat) - CR
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
Bill O'Donnel (SGI) - BO
Ted Toth - TT
Tentative Agenda:
Kernel update
==============
GW: Al, if you can give us an update, that would be great.
AV: Last week there were several fixes. 2.6.17 got opened this weekend.
Today I have a patch series I hope to feed to Linus. That is pretty much
everything that went on Linux audit and got into the tree, the only
exceptions that I still don't want to push is the last patch from Amy.
The only thing that won't go is filterkey, the rest will hopefully go in
today.
GW: ok great ..
AV: once it is in the tree we are back into getting stuff into our tree
first and then feeding it to Linux. only difference is now we have a
deadline for major patches going upstream. Now we know when the window
closes; and things that touch more than audit related files are
particularly important to get in time.
LK: when will the window be closed
AV: Window should close in two weeks
SG: I'll also roll a new kernel out sometime over night, also there was a
patch that was sent by Andrew Morton on task watcher, it is touching our
code. I don't know if anyone looked into what it is doing, but we need
to keep an eye on it
GW: I sent a note to Matt about that, asking if he did any work testing it,
considering it was included with out an ACK from audit list. I haven't
heard back from him yet. He is in Beaverton, hopefully will hear
something this afternoon or evening, I'll let you know.
SG: also I sent an email, but no response either. If it lands in 2.6.19,
it's ok, but if it lands in 2.6.18 that will affect us.
AV: We can live with that and we can work around whatever breakage gets
introduced. I don't like it, I don't like the idea itself, but we'll
see, at least it is localized.
GW: Serge was worried about performance impacts. He said it is the first
thing we need to do when we test scalability next.
AV: For what it is worth, I suspect audit won't be main part of the
performance impact.
GW: what I want him to do is post additional information to list and get
more debate. There is no debate as of now and no ACK. He might have
taken your comments as an ACK, but it is not. He works in Beaverton, so
we don't know him
AV: I really don't like it. I wonder how it went into -mm. What this guy is
trying to do is provide a way for 3rd party modules to attach to a task
struct. if these guys are working with somebody like a bunch of
anti-virus scam artists, that's where this sort of thing comes from.
GW: like I said we don't know him and don't fully understand the purpose of
his patch, so we need more comments and debate about this on the list.
That's all I can do for it right now
AV: Ok
GW: I was gonna try to get him to this meeting, maybe next week.
AuditFS/inotify completion
==========================
GW: As best as I can tell, inotify is substantially complete minus the one
patch that is not ready yet. We need to do testing, we recovered well
from that. Anything else Amy or Steve you like to talk about
AG: I don't have anything
GW: thanks for hanging in there
SG: Just to double check where we are now. One of the patches was to remove
a watch where there was no audit record. When there is a task being
watched and you add task to audit record, it isn't watched, and the last
one is cleanup of child watches.
AG: yes that is resolved. All are resolved except for one.
SG: all resolved but the one that Amy is still working on, I need to go too
and make the changes to audit as well to use the -k option.
LSPP kernel issues
==================
GW: Anything we need to discuss for lspp kernel
AV: I Want to start doing performance testing again.
GW: I'll see if I can get time with Jose. Also get a kernel with cache
poisoning turned off.
SG: ok, I'll turn debug off in the next kernel
GW: Alright, now that I know it's coming, I'll schedule time for that. I'll
make this a high priority item.
SG: I need to update syscall mappings too, in 2.6.17 few new syscalls got
added.
GW: so we should expect new audit coming out soon.
SG: Yes. later in the week.
Audit userspace
================
Audit failure action inquiry function
======================================
GW: Lisa, anything new on the failure action inquiry
LMS: I sent out a patch last week. I had a request to change the code to
match the style and functionality in auditd.conf; I am working on that
now.
GW: ok, thanks much for the update.
Print
=====
MA: I started using raster image format, it seems to be working well. I need
to verify the header and footer banner images are applied correctly.
Few concerns came up, the spool queue files are in SystemLow.
KW: if you have a user space process in SystemHigh, then a process is
downgrading the file, which process is doing that?
MA: that would be cupsd
KW: so cupsd has the override. I don't like it unless you have appropriate
DAC. It's better if files stay at same level.
MA: The problem I'm running into is it seems functions for manipulating
contents take two different data types and it doesn't modify ranges
separately. You can get into some weird situation were content wasn't
really specified by policy
KW: still need to do investigation. It makes things easier from a design
perspective that you have small piece of code running in override rather
than the whole of cupsd
MA: you can have small program that does that as another solution
KW: if you don't have MAC override, the files couldn't end up in SystemLow.
So something is happening to downgrade them.
MA: cups doesn't have the MAC downgrade in its policy, it is only creating
files and dumping data in them
KW: This looks like another problem then, need to have easy way to do that
MA: Well, I need to put it in enforcing mode then try that
KW: can be that it is working now because it is not in enforcing mode, and
might not work in enforcing
MA: another thing is the lpq?
GW: shouldn't see jobs you dominate.
KW: you shouldn't be able to see job info you don't have access to
MA: the queue files are not queried to see what jobs are there, it is only
coming from cups memory
KW: you should not be seeing any file names for print jobs you don't have
access to
MA: is this a good way to determine dominance on things
SS: [missed this part]
MA: I want to do string compare, and wonder if I need to query policy to do
that.
SS: [missed this part]
MA: I can look at that
SS: there is a number of user programs instrumented to get those checks
DG: I think we have something similar used to device allocator.
MA: fundamentally they are all similar types of access
SS: you might want to segregate the services, whether you want to do that
based on target contents or not, I think we need the drill down more on
this to figure out the specifics
MA: Well .. generally, I still need to implement some dominance checks for
lpq. Other than that, things look good
GW: where do we want to resolve the dominance issue, on the list, or talk it
out here?
MA: I need to look into device allocator stuff and see how it fits with
cups, I'll look into that first and then post on list to start a
discussion on this.
GW: I am also hearing we need to try this in enforcing mode and see what
happens
MA: If we are having a separate program do the actual downgrade then it
shouldn't be a problem
LK: but I think it's a good point to test in enforcing mode, we should be
doing that by now.
GW: Yes. It's painful, but we are doing it here too, and it's the best way
to flush out bugs.
MA: the printer I am using now is running enforcing, but been having
problems.
GW: We also have an intern who will be testing this stuff in near future ..
Fernando, he is not here today, but he will be testing this soon ..
alright .. thanks
SELinux base update
===================
GW: I don't know if Dan is on, is there anything we need to discuss about
selinux?
DW: I'm here. Major development is figuring out how to work on new roles.
Came up with the webadm, httpadm user role. Someone on fedora now is
attempting to build a backup role. As we play with these roles, we're
gonna find limitations; surprisingly it's easy, we can create a webadmin
role.
GW: glad, we needed that badly, to know that we can do that. Have you tried
the dominance operator
DW: no
GW: I didn't try it in a while either .. the last time I did it was broken.
DW: stephen you know if that works
SS: didn't know it was broken
DW: one problem with adding new roles, we will have to add additional types.
The more roles are added, the more types are added and the more
complicated the policy becomes.
GW: The question is how is your level of tolerance
KW: As a side note, why not use groups to edit config files? Not necessarily
you need roles to do that
DW: we need root privileges but only on certain groups of files
KW: give files to appropriate group and use ACLs on them. You can restrict
root roles to things the need the root override. Thanks for looking into
this. I posted response about the RBAC requirement question, I am
looking into more flexible ways to do that.
DW: I came up with my own response to that as well simultaneously.
GW: to what extent can we prevent it from tainting main policy. we assume
non malicious admins. This is more a question of what do RH folks want
to support, what is your tolerance level?
SG: Really, we are not in a position to answer that I think
GW: This will decide how we can use this flexible mechanism. I was actually
composing a post about what klaus said. I don't know the extent to how
we can isolate it to make it acceptable to RH.
DW: we are treading on new territory here. I'm not sure who'll make the
decision on this, it's a difficult problem. if you ship with policy, and
it breaks, it'll be hard to figure out what went wrong if user is
changing things too.
KW: would there be something like a tool that can check if you are only
using permitted constructs to make sure you are not breaking something a
system depends on
DW: there is something like that
KW: if you add a policy module, is there a way to check that you don't break
any of existing constraints.
DW: you shouldn't be able to get around constraints, but you can add
modifications
KW: can you ensure that any constraints in place will remain active
SS: semanage has ability to run verifier program to do that. you can write a
checker to do that. you can do those checks .. strongly enforcing them
requires use of the policy manager that is coming soon.
KW: are there documents or examples about how these checkers work
SS: not really.. we can talk about it more on the list
GW: I think we need to do that quickly. I remember you mentioned semanage
when we were looking at integrity of policy.
SS: not sure if that is necessarily useful for your focus, cause you are
concerned with MLS, and modules can take care of type enforcement (TE).
KW: if we are sure that the modules will not mess up current constraints,
then we are ok for certification purpose. MLS constraints that specify
what people can/cannot do must remain the same
DW: you saying you can't change constraints but can add capabilities to
existing types.
KW: yes
DW: I don't see how you can change constraints on a loadable module, Stephen
you know?
SS: I have to check on that
GW: as long as they further restrict, we can make an argument. Ok that might
not be as bad as it originally sounded. Now that we scoped the work, it
maybe easier for decision makers to make the right decision
KW: other part of that, make sure people don't modify existing roles, but
add new roles. This greatly helps in debugging as well
GW: yes. if you can crisply draw a line, it makes it easier.
DW: One more thing, I've been working on device allocator, sent out patches
last
week. Few things to make it acceptable to fedora extras. The problem is
it doesn't build on i386.
CH: we incorporated your patch
DW: I am at 5.4, I'll reissue this patch for 5.5
CH: sounds good, we'll get that put in
GW: anything else Dan
DW: I've been having discussion with Michael, regarding testing roles. He
wants to use scripts to run tests, and they need to be accessible by
many users. I showed him how to do that.
MT: I haven't actually experimented with that yet. Is there a type that
everyone can read.
DW: bin_t is closest one that allows you to do that
MT: as far as I know the test code doesn't have to be secure.
DW: yeah, use bin_t.
CH: I think there is a 5.6 for the device allocator
DW: ok, I'll base on 5.6. and resend it. I'll be gone for next two weeks to
Florida for vacation.
MLS policy issues
=================
Roles
=====
CIPSO
=====
GW: anything on cipso
PM: Everything is on the mailing list. There is a headache on how to deal
with accept, I posted what I think is a reasonable solution to that.
SS: did you look into what Venkat posted?
PM: When do we need to start worrying about the labels. Because of where LSM
hooks are, it's easier to do things and only be concerned with where
things are at. worse case is you'll go ahead initiate a tcp connection,
do handshake, both sides start talking, but once you start talking you
then get errors saying "hey, I don't like this MLS label" .. this is the
path of least resistance to get this into kernel.
SS: I think the other way is better, but probably more invasive.
PM: that's my concern, it'll be too invasive and the network people won't
like that.
VY: I'm going to get a patch out tonight.
SS: At what point is the stuff going to show up on netdev
VY: I think this time I'll include netdev as well, unless you don't think I
should
SS: I think it's reasonable to put them on netdev now, and get wider
exposure
GW: Venkat, did Serge ever contact you?
VY: yes, and he sent me the transform user patch, and I'll include it
GW: great.. didn't know if you were in touch, hopefully that was helpful
VY: yes .. it was
GW: Joy is unavailable now .. she is away on personal business and is
unreachable.
IPsec: MLS, UNIX domain secpeer, xinetd
=========================================
GW: Catherine posted the secpeer unix domain patch, few comments but pretty
good to go. As far as xinetd goes, Joy was going to incorporate the
comments, but Steve I believe you wanted to change parts of it yourself?
SG: yes, I've got about half of it changed to conform to what I need. My
goal this week is to get the patch that trent posted to conform to the
style then visit irc logs between Joy and I to get those things we
talked about in place
GW: thanks for taking that on Steve.
SG: also seems like I have one minor patch to add to ipv6. You want me to
post patches to the mailing list, or just put daemon out to rawhide.
GW: whatever is easiest to get it out to community
TT: I like to see it
GW: yes Ted mentioned that issue of polyinstantiated ports
GW: I thought we'll use something out of iptables that will remap on the fly
to a real port
GW: yeah, I remember that now ... about 6 months ago we talked about it.
James talked about it then. I can dig that up.
SG: that was my recollection that we were gonna tackle it through iptables.
not sure if secmark was gonna handle it.
SS: I thought the port redirection was what we will use. haven't the TCS
people used that.
GW: I'll dig that discussion. Ted you can live with that, or you need the
polyinstantiation ports?
SS: Is anyone watching the network name spaces work going on?
GW: I haven't looked at it, or talked to Serge about it either. I'll talk to
Serge about it
TT: as long as it gets on the radar I'll be happy
GW: I'll try to dig that out, and repost something about it.
ipsec-tools: SPD dump and racoon base + MLS
=============================================
GW: I understand this will end up as a patch in rawhide since IPsec tools
are BSD centric.
Device allocation
=================
GW: Dan said he made some patches to device allocator, anyone has anything
else?
SS: I just looked at the code for that, and it is doing process_get_attribute
check for some reason. Either way it is fine depending if it is caching
results. This is more directed to people doing cups work.
MA: ok, I'll take a look at that
SS: is TCS maintaining that
CH: yes we are maintaining that.
DG: you think we need a class for device allocator. We need a translation
daemon to be put in there.
CH: the checks in device allocator right now are very convoluted things. It
relies on things like policy to be there ... we should definitely look
into getting some classes in there. you know what the work is like to get
classes into user space
SS: right now we are still in a mode were you need a patch for that.
GW: any other device allocator issues?
Self tests
===========
GW: I need to get the self test done. I'll commit to have new iteration of
that by end of week.
VFS polyinstantiation
=====================
GW: Janak, anything for polyinstantiation?
JD: Nothing major. for pam namespace, I posted a patch to redo some work to
get X working, I updated man pages and put example to get gdm working. I
posted a patch, and there were some spelling mistake comments from Tim,
I fixed those. If people can give it a try and let me know. it is in
rawhide, except for the last patch, you would need to get the rawhide
stuff, then apply the last patch.
SG: I got an email from pam maintainer, he'll be unavailable for Wednesday
and Thursday, so it won't be until then before it gets in rawhide.
GW: so cron is in rawhide?
SG: that's different. Regarding that I talked to Jason and he is re-working
vixie cron, but he is concerned about the patch being invasive, he'll
look into it when he gets back, but If we want I'll build a cron and put
it in the lspp repository so we can test it before he gets back and we
can flush bugs before he is ready to merge. I'll go ahead and put out an
iteration like I do for lspp kernel so we can test it.
JD: ok, one of our QA guys will test it as well.
SG: unfortunately Jason has been working hard on vixie cron, and his
reservation is that alot of code is written to the old code, so he has
to remap it.
JD: tell him to contact me, and I can help him merge it with new code.
SG: meantime, I'll build it and put in repository
GW: Any other issues? ... ok .. kernel work needs to go into 2.6.18. we are
making good progress, and we just need to keep pushing to get the last
bit in. Thanks everyone, let's adjourn the meeting.
Approximately 90% complete, 80% upstream
All kernel work needs to be in 2.6.18
Remaining tasks.
More information about the redhat-lspp
mailing list