6/05/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
Venkat Yekkirala (TCS) - VY
Michael Thompson (IBM) - MT
Irina Boverman (RH) - IB
James Antel (Red Hat) - JA
Lawrence Wilson (IBM) - LW
Lisa Smith (HP) - LMS
Fernando Medrano (IBM) - FM
Nikhil Gandhi (IBM) - NG
Trent Jaeger (PSU) - TJ
Kernel update
=============
Gw: Now that AL is on call. Al would you like to give us an update about
what is going on with the kernel?
AV: Most of this stuff is in -mm tree. It became possible after Andrew took
Amy's patches. Most recent updates as soon as they get testing in lspp
kernel, they are going to -mm as well. 2.6.17 is still not open and
there are still rather unpleasant pending issues.
GW: Is that the bug cleanup that might happen
AV: We may have potential sec problems, and we might or might not have
fixes, may or may not have fixes in 2.6.17. Then the decision is up to
Linus, he might decide to release without those and apply fixes after
release. Hopefully it will be fixed by the stable series. May decide to
put them into tree before fix, which means giving it time to stabilize.
Right now it's rather indefinite so I don't know. Too much depends on
what Linus decides about delaying. There are reasons to delay, on the
there hand, they may not be considered sufficiently serious to hold.
It's embargoed, can't discuss.
GW: sure we understand that
AV: In general we are on track getting things into -mm. The longer it takes
to release 2.6.17 the better. After it is released, stuff in -mm will
probably go in a week or 2. Then we better hope the rest of our stuff
will remain in kernel audit and friends; probably it will.
GW: sounds pretty good. the networking stuff is not confined to audit. You
must have seen the IPsec patch it is pretty invasive ...
AV: what do linux folks say about it?
GW: Stephen says unless something quick happens on it, it is not small
enough to make 2.6.18. It's public and needs to be reviewed.
VY: I only sent out the patch to few people. I'll have it to lspp and maybe
net list. I was trying to get initial feedback. Based on feedback so
far, I'll clean it up and send it out on lspp and net dev this week.
SG: I want to reiterate, we need to get it into 2.6.18. if it is not there,
it is not guaranteed to get in Rhel 5
CH: Those secmark changes desired to be used in rhel are different to what
they have been previously.
GW: Stephen was talking about everything using that mechanism as well, but
it's a lot of work. We came to the conclusion that it is in fact going
to be enabled in rhel5, secmark that is.. right?
SG: probably, see how it goes upstream
GW: can we operate outside of it, things like local protection. This throws
a big change very late in the game.
LK: if it doesn't go upstream, would RedHat(RH) carry it in a patch?
DW: don't know?
SG: don't know?
LK: I'm curious to know what would RH do if it doesn't make it upstream?
GW: there is a ripple effect, you and I Linda see that. the later we do that
the more we jeopardize our end date.
SG: well delay is part of the product plan, and it's a moving target.
KW: as a side note, I saw a note that rhel5 will be delayed until Xen is
finished.
DW: we think of Xen as the guiding light for RH, if Xen is not working we
are not shipping.
SG: James is working on secmark patch, he intends to push it upstream on
2.6.18. not sure how successful he's been, but it's his plan as far as I
know.
GW: I did want to touch on several of these issues later in the call as
well.
AuditFS/inotify completion
==========================
GW: So regarding auditfs/inotify work, any updates Amy?
AG: It's going pretty well .. inotify patches were pulled into -mm kernel
last Monday, so they are getting more testing. also been acknowledged by
the inotify people. Things are looking good for merging with 2.6.18. for
audit stuff, I've been stabilizing it to go into -mm, I don't think it
is in yet. last week I posted fix for missing audit records for deleting
files/directories. Also fixed a bunch of other bugs. I am now working on
adding code for getting records for directories. What I have left is
filterkey and map operations.
GW: Great .. thanks Amy for hanging in there, continuing on with this work
and seeing it to completion. We need to continue testing on kernels. Is
Al on yet? Ok, well if anyone has issues please bring them up on lspp
list.
SG: I'll be putting out a new kernel tomorrow. lspp.35 should have the patch
amy talked about, and Al also has some patch that he added. it's based
on the more recent rc5.git11.
GW: good, we'll get some test time on that. I was gonna post Jose's
performance results but they were not interesting. He didn't do a
profiling run, he just tested and determined the problem was fixed. I'm
trying to set up some hardware for him and get him to do more profiling
runs.
SG: I think it would be interesting to check and exercise the filesystem,
see what results we get when the watch system is active.
GW: I can post the results if you like to see them, but they were not as
detailed as I want . I'll wait for something more meaningful and post
those.
SG: Also see performance for disk access during a match to see if some
function calls are not needed. This happened to us before with selinux,
so it would be nice to see if we are doing the same thing now.
GW: that kind of thing can help sanity check we are doing the right thing.
I'll get some time on a 64-way to get some results. what kernel do I
need to run. Cache poisoning is on since .27 right?
SG: I'll need to provide you with a kernel for that, maybe let the .35 run
for a day or so.
GW: Ok, I'll get a run scheduled
SG: Do we know what kind of hits we have with labeled networking.
GW: Joy did some bench marking for that. I thought she posted the results on
the list. she was looking for useful tests to test the scalability. She
also looked at performance with regards to nodes. Joy is back now, so
hopefully Thursday she'll be back in the office. I'll ask her, see if
she can post the results.
GW: I have one more memory leak that I intend to work on. should hopefully
be the last thing to do on that
LSPP kernel issues
==================
Audit userspace
================
GW: Steve, anything new with audit?
SG: I'm taking care of the null filename issue we discussed on the list a
long time ago. Also there were 1 or 2 patches from mike that I merged. I
might put another one out towards end of week.
Audit failure action inquiry function
=====================================
GW: Lisa, how is audit failure action inquiry going?
LMS: doing well. I ran into problems with netlink not available when we get
errors, and that's what I need; so I'm back to my design to use user
space config file in order to use the tunable.
SG: Just curious, what program couldn't read the netlink?
LSM: No one in particular. When I go to get the tunable, I need the
netlink, and it is not available for the query function
SG: but you do get a well defined ERRNO if kernel compiled without audit
support.
LK: but it is when audit is in the system
LSM: I still couldn't get the tunable value.
DW: if you can't audit how you would respond. is that the tunable you are
asking about?
LSM: right
LK: if you can issue and audit record you can read a file in directory. I
think it could be a policy issues.
SG: the ability to issue an audit record?
GW: are you also gonna have issues with the MLS policy
DW: all you need is support ability to access the file. but the netlink
concern is more related to kernel. it's a performance query
GW: if netlink is toast, we are toasted anyway.
LK: depends on which netlink socket is toasted, we can't issue an audit
record.
GW: seems like this is a case where you should give up
SG: you wouldn't stop the program... just decide on the action
LK: we decide if we need to halt the system
MA: we should be able to access one file
SG: we can move audit config stuff to an /etc audit directory.
DW: make it world readable. The problem of moving it to audit directory is
that it adopts permissions of the directory which is currently readable
by auditadm only. Put it into /etc instead.
KW: would it preferred in /etc/security
DW: not really. is this an MLS thing?
LK: not really .. not even CAPP.
KW: If audit is not running, then certain programs will not run
DW: that's when the login program would stop working for example.
AG: we need to go one way with audit failure. Because of the packaging for
Rhel there might be people with audit who don't want the system to fail
for some unforeseen reason if you can't audit.
Dw: I think you don't want that at all
KW: what CAPP says, the intention requires options to fail if audit is not
working, but not necessarily it is the only option.
DW: put the option in audit.conf
AG: we'll discuss this further on list
GW: are we happy with having it in /etc?
LK: No one seems to mind.
Audit of service discontinuity
==============================
GW: I think this is already taken care of. Wait, no, this is where we need
audit record when init is not around.
DW: there is no audit system when init is starting up
GW: there is a requirement for system discontinuity to be audited. this is
almost like early boot message capture thing
SG: we need to get messages, how do we get this through the kernel? We need
to get init to put a message out.
GW: This is the only place left we need audit message as far as I know. Is
there a message in syslog now when it fails.
DW: yes
GW: I wonder if that is enough to meet the requirement
DW: if selinux is in enforcing, it crashes the system. if not enforcing, it
sends out a message.
KW: we only care about enforcing. we need it to be in audit log, syslog is
not audit so it's not enough
DW: it sends message saying that " it can't load policy and halting system"
GW: So it gives user an informative message about what is happening, but
just to syslog.
KW: when you get a fail in system operation, and you can say at this early
stage in booting, it is not really operating.
GW: I hear that we can remove this item off the list. we'll argue that the
system is not really operating at that early point.
Print
=====
GW: saw your patch Matt.. thanks.
MA: I should also have sent a .spec file. the src.rpm will build correctly
and had to create additional file that wasn't there. I need to do a
.spec file update and fix that bug. I want to test with usb printer.
I'll will send new version to list. Hope to have it out to the list this
week. I got a message from IBM that someone will start doing some
testing as well.
GW: that would be Fernando.
FM: Yes.. I started looking at the cups daemon for testing.
JD: are you updating man pages Matt as well.
MA: We need to do that, but I haven't gotten to any documentation. anything
specific you care about?
JD: Well, besides being useful to the testing team, I was looking from a HLD
perspective. Send it my way if you have something. otherwise one of our
guys will go through your patch and write stuff up.
MA: the programs are the same mostly. The place of most docs changes is in
the cupsd man page. Mike you on the call?
MT: yes
MA: system group or auth class is what you need to modify in your file.
MT: if it is working for you, then I might have changed my file wrong
LK: Probably it is a good idea to clarify and configurations and identify
those issues
MA: I'll roll those up this week
GW: have you tried it with dev allocator
MA: Not specifically. dev allocator is on my system, but they don't seem to
collide with each other
GW: great .. thanks... I appreciate your work on this patch Matt.
SELinux base update
===================
DW: I was at RH summit last week, so most stuff is still in the works as dev
allocator is getting updated. I will push this week to get this all
done, and will answer this question better next Monday. I also need to
know why they are ignoring dev allocator, need to start yelling at
someone.
GW: ok, I hate to be at the receiving end of that :) .. thanks Dan.
MLS policy issues
=================
GW: Michael you had some questions about the policy?
MT: Yes .. the definition between sec and sys adm somewhat settled down. I
sent email to you Dan about different utilities, did you get chance to
see that yet.
DW: looking at it right now actually. I'll respond to the email. Most are
correct, most the restriction are on the target not the application.
we'll try to break it up more that way. Is this something we need
documented?
MT: if we can solidify that and post somewhere, I'd like to do that for
testing purpose
DW: I'll look through your list, and make changes and clarifications.
MT: I think we are on .43 version of policy now. so my list is outdated, but
as long as we have the main issues resolved.
DW: certain applications will blow up otherwise it will run. I mean this is
different than roles based access where you can't run at all.
MT: that's what the email is about, regarding roles mostly
GW: If no more issues with MLS policies, let's move to keyring
Restriction of kernel keyring
=============================
SG: there has been alot of work on NSA mailing list.
CIPSO
=====
GW: CIPSO went in and out of kernel. Paul any updates on that
PM: I am still working on it. James and Steve sent comments. I put James
comments, and looking at steve's comments
SG: out of curiosity is it on track for 2.6.18?
PM: you tell me Steve. I keep posting, and I'm getting lots of comments, but
I feel alot of peoeple need to approve this. I am not experienced in
this process
SG: I think you'll find it's an iterative process, you keep posting and
fixing
PM: that's what I've been trying to do.
SG: people will keep testing, and see if major issues happen. I think we
need a patch sometime this week to put into a build so we can put it
infront of poeple again.
PM: as far as syscontrol variable I can throw that in again, but I think
here is another solution. I can change that and push a patch out
tomorrow if you want. there are more changes, but if you want it fast, I
can put in temporary fixes.
LK: let's get a version running in the lspp kernel.
SG: at least fix the capability checking.
PM: then that's not gonna be tomorow
SG: should be a a small patch
PM: might be .. but I havn't looked at it. if you want a temp fix for lspp
testing it's fine, but I don't feel comfortable signing off on that as
final solution for upstream kernel.
SG: I'll build a kernel with Amy's latest changes. then I'll build another
one with your changes. so if something breaks, we have someting to fall
back on. Also too many changes makes it hard to debug.
PM: I'll send it to lspp list tomorrow. if I run into problems I'll send an
email and let you know.
GW: great. we like to try it as well.
IPsec: MLS, secmark, UNIX domain secpeer, xinetd
==================================================
GW: Trent and Venkat are on the call. First item is the MLS patch. There has
been comments and Venkat will post to public list. We need it out to see
the light of day. Joy posted some comments, looks like it needs to be
broken up, and needs to go to net dev. how can we fast track it, get
review and comments so it is acceptable?
VY: I'll break it into small patches and get it out in the next couple of
days
GW: can RH give some help in getting reviews .. how hard is it to get James
time, he and maybe Herbert?
SG: This is the ipsec patch? James thinks that Trent is reviewing it.
TJ: it looks reasonable, but we need Herbert to look at it. We seem well
along with the patch so Herbert needs to be brought in soon
GW: can we get some of his attention Steve?
SG: if it is in public, I'll have something to point to
GW: ok, so Venkat needs to post it, then you can bother Herbert a bit
SG: the de-compisition is important, how do you plan to de compose it?
VY: I'll look through the docs for submitting patches, and it'll be more
like an official patch when I get it out.
GW: We will be hard pressed to make the date, but we'll keep pushing.
GW: I saw that katherine posted patch to do delete authorizations, we need
one more patch to do the datagram. Thanks Trent for working with her to
get those authorization.
ipsec-tools: SPD dump and racoon base + MLS
============================================
GW: how to integrate the ipsec labeling with sec mark. we seem to have large
question marks here
KW: feedback from users planning to use the system would be useful here
GW: get feedback from UTCS.
PM: one question about secmark it does not address outband issues. I suspect
ipsec must have same issues
VY: I sent an email about that, solution to fix this is to prioritze the
outband, and use outbound rule as a filter.
PM: I saw your email. I like the seperation of labeling. There is more work
to be done on outbound side than that. for CIPSO and RIPSO, you need to
attach IP action, and I don't see that happening.
VY: can you elaborate on that. are you talking about outband traffic?
PM: I'm attaching IP action to socket and that is not something secmark
makes use of. Relying sololy on secmark field is not enough
DW: instead of populating that with content of IP table, we would
prioritize. We can modify that on way out.
VY: where in the outbound currently should the check happen?
DW: let's put this discussion on list. Stephen is on vacation now.
GW: we'll have a fair ammount of discussion to get this done. Moving to
xinetd. Trent's student posted a patch, but it is not up to the way
xinetd operates.
SG: xinetd has option on how to tell daemon to reject packet. there are 2
sets of config options how to reject connection and how to set up
environment. admins should have control over ranges of what to allow
connection.
TJ: independant of selinux policy?
SG: traditionally xinetd has capability of discriminating connections on its
own.
TJ: so you don't mind redundancy
SG: no, we don't want people to modify policy
DW: can we have it go to different application based on if it came as system
high or system low.
SG: that's how xientd should be, the kind of thing I am looking for. Maybe a
config option in file to help identify which server to go to.
GW: you suggesting we have different definitions for servers
SG: yes, for xineted you can have 10 definitions for ftp for example, and
you can decide which one to use. there are 5 differnt options that help
it decide which server to invoke
GW: this is a different model than what we were thinking of.
SG: right, if it doesn't find match, it rejects connection. You could have
separate daemons for system high and low. What Dan suggested would work
GW: so you want the selection criteria to be the inbound label?
SG: yes that is what I am looking for.
VY: how would a child socket that get created get labeled as secret for
example.
TJ: the invoked process will have a context that will be at that level
VY: by that time the child socket would have been created right?
SG: xinetd has two sockets for listening and accepting. I think the
listening one might be set at a range.
TJ: not sure that is handeled correctly yet, but you would set the socket
level.
VY: I mentioned that in emails to Trent I believe. we want the label to be
at same level as incoming connection. I can send a patch.
TJ: that would be good.
SG: I am looking at xinetd code, seems like we want something there to help
have the socket at the right level. also looking at the environment
options. We need to change on how it makes the transition to the right
type and level. I didn't look deep into the patch sent in April, is that
the one that checks the level of the process after the fork?
DW: so is it doing set_exec_con?
TJ: yes.
DW: wouldn't you need to set the level as well.
TJ: we were only doing it with TE labels. Did joy try with MLS labels?
GW: I beleive she did, but I need to check with her for sure. I saw her try
it with TE and saw the child get the right type. Are you volunteering to
fix those things Trent or we need to find someone to fix that.
TJ: I don't know where my student is now, and I'll be traveliing, so better
to find someone and we can communicate.
GW: Joy will be back Thursday, I'll ask her see if she can do it.
SG: and if she needs anything or questions regarding xinetd, she can ask me
GW: looks like ipsec tools dimished in priority regarding upstream. don't
know if Venkat has a patch that you want to send to RH.
VY: We have something but it is not upstream ready
SG: just noting that kernel deadline is before userspace deadline, so we
have some time for userspace.
GW: In that case we may have time to discuss the patch and work it out. if
you want to share the patch, maybe someone can help too.
Device allocation
==================
GW: We already heard from Dan about that, and he is following up on that.
Self tests
==========
GW: I need to get back to that. I have been busy with hardware setups
lately, but I'll get back to this.
VFS polyinstantiation
======================
GW: Janak, any developments with this?
JD: pam namespace is sent again. I fixed comments, and resent it. I changed
the manpage, and added reference to shared sub tree. Last time we talked
about it we were gonna put it into fedora rawhide. Dan if you can get
that in fedora, we can use it and test it. As for cron, I havn't heard
anything
SG: I taked to Jason Friday, he is gonna look into it this week, it is on
his to do list
DW: on the mount patch, the developer said he is looking into it. With
regards to pam namespace, is there any movement on xwindows?
JD: I added a section on man page on what people need to do to use gdm, and
polyinstantiated /tmp. if you don't want to polyinstantiate /tmp, then
gdm needs one change in the config that I talked about in the man page
DW: did you look into bind mount stuff
JD: I looked into that, it doesn't work since socket has already been
established under different name space.. only way to do it is to move
that dir; but when you log out and log in .. it is not set up properly,
and I couldn't get it set up through the scripts
DW: I'll play with it and make sure it all works with Selinux.
JD: if you see anything else that you want me to try, let me know.
GW: to reiterate .. as Steve mentioned earlier ... all code needs to go into
the 2.6.18 kernel. Any more issues anyone needs to bring up?
LK: I sent an email about the RBAC roles.. we need to talk about that on the
list, and maybe discuss it next week.
GW: we talked about that, we need to use policy module
KW: maybe question for RH. if admin uses policy module, would that
invalidate the certified criteria
DW: ???
KW: but you don't automatically consider something unsupported for that
module.
DW: same analogy as a kernel module.
GW: but in this case it wouldn't be a random policy module
LK: you are assuming this is a requirement and we have to do this
KW: intent of RBAC is to have roles, and you might be able to squeak by
GW: our initial intent was to squeak by. so the question is a configured
system if you go add another role to your policy
KW: would it be possible to have limited way to have roles added, or is it
once you change anything then all bets are off.
DW: my perspective is that it is not a problem. I don't want to make
agreements for RH, but it shouldn't be a module that will break
something.
KW: users can still get support for their system even after creating few new
roles to the policy
LK: what about modifying an existing role?
KW: it is reasonable to tell users not to modify roles, if they want a
change, then add a role for that.
DW: as far as the dominance stuff, I know it was broken, not sure if Tresys
fixed it.
KW: you should let admins creat new policies, otherwise all bets are really
off.
LK: is Irina still on the call?
IB: yes.. let's put this on the list and discuss it then decide on it.
LK: george and Klaus, will you post your thoughts on the list
GW: yes we will, we also will check on the dominance operator.
DW: we need to find these issues early since that is what people will be
testing
GW: I agree, we need to take action on that.
LK: we also have the tools
DW: modifying policy is difficult so that's why we need the tools
KW: Need general audit record saying people changed policy
GW: we don't have a diff mechanism, so we can't tell if policy changed
SG: we have a diff mechanism
DW: but you don't want that to be sent to your audit log
SG: one last thing, do we need Xm or postfix for print.
GW: we like postfix
KW: first there are some documentation related to that. one other thing is a
feature you turn off which is the .forward, we know how to do that with
postfix but not xm.
DW: discussion is on going about wich one is the default. the decision is
postfix right now, but we are deciding which one we want to support.
KW: the previous configuration specifically selected a mail client.
MT: One more issue to bring up. If it takes too long we can discuss on list
instead. setsepool, is that supposed to be generating audit messages
SG: yes .. supposed to
MT: what audit records are we expecting
SG: I would have to go check
DW: we are seeing AVC right now
MT: is there a specific message type we should see, cause we are testing
that now and haven't seen any yet.
SG: it should be there in the lspp kernel.
MT: I don't see it.. this is on i386, and x86_64
SG: that was fixed a long time ago, possibly in Feb.
GW: Ok.. Michael just try it and post your findings to the linux audit.
Anything else?
GW: Ok, again iterate the deadline for 2.6.18
Cron, tmpwatch, mail, etc.
==========================
Approximately 90% complete, 80% upstream
All kernel work needs to be in 2.6.18
Remaining tasks
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
