6/12/2006 lspp Meeting Minutes:
===============================
Attendees
Janak Desai (IBM) - JD
Debora Velarde (IBM) - DV
George Wilson (IBM) - GW
Joy Latten (IBM) - JL
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Lawrence Wilson (IBM) - LW
Fernando Medrano (IBM) - FM
Thiago Jung Bauermann (IBM) - TB
Nikhil Gandhi (IBM) - NG
Stephen Smalley (NSA) - SS
Al Viro (Red Hat) - AV
Steve Grubb (Red Hat) - SG
James Antel (Red Hat) - JA
Irina Boverman (Red Hat) - IB
Paul Sutherland (Red Hat) - PS
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Amy Griffis (HP) - AG
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
=============
PM: I have some patches, but I haven't been posting to the list. I am
intending for them to go into the 2.6.17
SG: you intend for it to go into rhel5?
PM: yes, I hope so
SG: if you want it in rhel5 then it needs to go into 2.6.18. All of Amy's
patches will go into 2.6.18, which will open for business in the next
couple of weeks
PM: and the window will is open for 2 weeks
SG: yes, most likely.
AV: The real question is what SELinux maintainers will have to say about
this. If it is more than code in kernel, then audit & friends, need at
least the maintainers of that code agreeing to get the patch merged.
PM: If Stephen is on the call, would he comment on that issue.
SS: it's not an issue on our side.. if it's ok with net dev people
AV: which would be Dave Miller
PM: only people I got feedback from is Stephen and James.
AV: what is the situation with Dave Miller?
LK: have you heard from him, what's the best way to contact him
AV: mail, cc him as well
PM: I'll send him some private mail this week and see if he has any
comments.
GW: we also would like to see it in there if you can
SG: I was building a kernel Friday, but the net label patch broke in the
linking part. I sent the output to Paul to look at. As soon as I have a
net label patch that compiles I'll build another one. Should .35 be an
update with the new patches, and make a .36 with the net label patch.
PM: we can talk about the net label stuff now if it's ok. Is this going to
delay your agenda George?
GW: No problem, go ahead.
PM: Reason I didn't see it yet is that I got it late Friday, and got to see
it just today morning. Is Ted on call.
TT: Yes, I'm here
PM: We all need to thank Ted, he set up a trusted solaris system last week,
which saved me about 3 weeks of work, so thanks alot Ted. There is an
issue about trusted Solaris talking to selinux, but we'll work through
it since we have trusted solaris in operation now.
GW: Great, thanks Paul and Ted .. we appreciate that
TT: Glad to help
PM: There was some talk about ipsec stuff, when you do accept a connection
you need to relabel the socket. Need to make sure the CIPSO IP is set
correctly. IPsec needs to be figured out, but the netlabel stuff should
behave correctly. I believe we are doing it the right way. Now that this
is taken care of Steve, I'll take a look at the problem you posted. I'll
fix it and send you a new patch. So as far as kernel goes, I'm
recommending that if you have all your patches, then go ahead and build
a .35 kernel now, and I'll get the net label patches in the next kernel.
I'll put the netlabel stuff on the list.
AV: There is a potential problem, Andrew Morton will be away for a week.
That means no new -mm for about a week
MA: is there a way we can extend the window for 2.6.18.
AV: How?
MA: well, since we can't do much testing during that week.
PM: I'll test the lspp kernel on different platforms, make sure it works, I
know IBM people do that as well. I want to look at the code once over,
then I'll send another posting to netdev, selinux, lsm, see if I can get
another round of comments.
GS: sounds good to me. Once that it's out, we'll put an effort into more
testing.
AuditFS/inotify completion
==========================
GW: Hi Amy, how is this going?
AG: Good, I am wrapping things up. I posted couple fixes for inode number
patch. Also posted new patch to add directory info to audit log record
at end of last week, I don't think it got alot of testing other than me.
Also Al fixed a problem that I introduced, thanks Al, and I'll try to be
more careful about not introducing problems. This week I'll work on
filter key patch. I'm out Thursday and Friday, I'll post something
before I leave.
SG: I remember you had talked to Al if it was time to put anything on Linux
mailing list. have you done anything to push these patches upstream
AG: I got that the inotify patches will be merged upstream. I got some
comments about cleanups, and I'm working on that. I have not received
any other feedback. My assumption is that audit part of that patch will
be sent by Al as a group along with the ones in -git tree.
SG: I was just wondering since people were asking about the client piece of
it.
AG: yeah those people who asked that didn't post anything.
GW: thanks Amy, we can't express our gratitude enough, I know this can be
annoying and not so much fun.
AG: Well ... it can be fun.
GW: I posted my small three line patch to fix memory leak to the audit list.
hopefully that will be picked up
LSPP kernel issues
==================
GW: Let's go around and collect status. Steve got a new kernel out there no,
I've tried it and so far no issues specific to this kernel.
SG: there is one thing, Dave jones was doing experiments while I was
building. His experiment kills anything that uses a serial port. I'll
switch to another build system when we build another kernel, so if you
are using a serial console, it'll not work.
GW: That is great to know, because we were ready to set up a serial
connection. In this case we'll use an older kernel, or wait for the
fixed one.
SG: I hope to get everything together and push a build tomorrow.
DG: I put a patch out about the enforcing issue. I got some comments from
Stephen, anyone else has comments on that?
GW: It looks good to me, obviously Stephen has better experience. If
everything builds and works in both modes, then I don't think there is a
problem.
Audit userspace
================
GW: Steve, anything new with audit userspace?
SG: I am working towards another userspace release, but it's going slow, and
will be a while before it's out.
Audit failure action inquiry function
=====================================
GW: Ok, now to the audit failure action inquiry, anything new here.
LS: It's going well, changing code to parse and put file in /etc. I've
incorporated some comments, and should have a patch out this week for
that.
GW: great .. thanks Lisa.
Audit of service discontinuity
==============================
GW: I don't remember what we decided about this last week.
LK: I believe we decided it was impossible to do that. It's going to fail in
a catastrophic way that it will be obvious for the administrator that it
failed.
GW: Ok, then I'll remove this item from the agenda.
Print
=====
MA: I am going between doing dev allocator integration and other testing,
and I ran into dev allocator problem. I tracked bug from before and
verifying the fix is correct. I have updates to the man pages and docs.
I'm not sure they cover everything you are looking for. I need a test
plan to make sure I got everything.
GW: That was Janak asking for that.
JD: Yes .. that will be great. thanks
MT: By the way, small interruption Al will Join shortly on IRC
GW: great, Al will join, we'll step back a bit to the kernel section and ask
him about that.
AV: Sorry I missed some of this.
SELinux base update
===================
GW: Dan is not on the call today, but he did send status to the list. Main
thing, the device allocator patch is in
MLS policy issues
=================
GW: any issue with policy. Mike usually has some, anything Mike?
MT: the sysadmin role seems to be the only one capable of accessing /root.
Dan said it is to protect admin roles from being attacked using the
.bashrc profile files. I just don't know how that reasoning came about
when you are working with trusted admins. it's annoying when you log in
as secadm and can't see what's in /root. any one has any idea why we do
it this way?
GW: so then your question is why we have it this way?
MT: yeah, does it make sense for it to be this way when we are assuming
trusted admins. should it be changed back?
SG: couldn't you do something like the bashrc file checks who you are, and
sets some variables.
MT: yes we can, but Dan said they are trying to protect the admins and
separate them, but it doesn't make sense with trusted admins. And that's
what I don't get.
KW: there is no requirement in the sense of RBAC, it can be acceptable for
all roles.
MT: that's the trusted admin argument
SS: Your other option is to configure pam-namespace.
MT: I just don't understand why we don't give them access to root. where
would secadm files be, where does secadm role live. I'm not clear about
that.
KW: It would be nice to have that as an option. if people wanted more
protection, it can be an option. Using polyinstantiation to separate
roles. people who don't care about that then would have a more friendly
system.
GW: seems like a reasonable compromise to me. I don't think we would make
that default configuration though
SG: No, sounds like it would be in a configuration script, but not shipped
by default.
GW: yeah, until customers figure out how to use polyinstantiation. So
hopefully we want a friendly default with good instruction on how to set
up polyinstantiation. This is a Red Hat decision.
Restriction of kernel keyring
=============================
GW: This looks like a done deal
SS: He is finalizing some work. He's looking at additional issues. What is
in Andrew's patch set is sufficient. Has patches for gdm, login, and
sshd
we'd like to get into rhel.
GW: thanks for taking that up, we appreciate it. once that is in kernel we
need to be testing on it. Back to networking, any read if secmark will
or will not be included in Rhel.
SG: I think so, maybe Stephen knows more about what James is working on
SS: yes, it will be available for rhel5
GW: is it sufficient not to use it. it's late to integrate with the other
labeling mechanism we have.
JL: is secmark going to be installed by default?
SS: I understand that secmark will be the default. It's a huge win in terms
of performance on network. It superceedes old SELinux support port and
node stuff.. I saw patch from Venkat, but I was gone all last week, so I
don't know what is going on
VY: so far I haven't had a chance to even prototype what I mentioned in
email last week. I'll try this week, anyone thinks it might be a waste
of time to prototype it. I am Concerned about outbound secmark. Wish
James is here to give comments
SS: James prefers to keep them separate.
VY: after having resolved various labels on inbound. we can have checks to
have one label replace another label.
GS: sounds like alot of work to happen in 2 weeks.
SS: to what extent were you relying on current controls. what is actually
going into certification?
GW: the ipsec stuff will be relevant to certification. we would have to
apply this to local case. would be nice to use secmark, but timing is
late. Back to your question venkat, I don't know if there is enough
time to prototype this and put upstream. It is something we would like
to have, but don't know about the time. This is a read from RH if it has
chance to make it in. We can contain it in our Security Target, but it's
a whole timing issue, and I don't know if anyone can help you with it.
Maybe Joy
JL: in what? figuring out sizing for the effort?
GW: maybe with sizing, and figure out what needs to be done, testing as
well. can we just make use of IPsec now, and live with that. I know
Katherine needs to get her patch in there.
SS: you mean Katherine's patch alone, or also Venkat's patch as well
GW: I think we need Venkat's patch in there as well
SS: they are addressing diff kinds of controls. Long term it's good to
integrate them, but now it's ok to be separate
GW: what if have conflicting labels
SS: they are being used for different reasons.
KW: having conflicting label is not a problem. if ipsec and secmark reject
connection it's ok, as long as one rejects.
SS: they operate independently.
GW: does xinetd need to be aware of secmark labels
CH: xinetd can work with ipsec, or secmark, so at this point it needs to
work with ipsec.
GW: one enhancement we'll make is to accept/reject packets based on labels.
CH: using multiple labels that are not enforced is the biggest problem we
had
GW: for our purpose we base everything on ipsec, and ignore secmark.
KW: I have question about Venkat's patches. looks like they require racoon
to be active to be useful.
VY: racoon is not a necessity, one can manually load security associations,
and that would be fine. so racoon is not a necessity, but would make
things easier.
KW: this also may be a question for end user. if you have 1000 categories,
that will be 2^1000 possibilities and impossible to set up
VY: that's the reason for the patch, and using racoon
KW: Ok .. so we need racoon as part of evaluated configuration
CIPSO
=====
IPsec: MLS, secmark, UNIX domain secpeer, xinetd
==================================================
TT: I want to know if there is an update on xinetd
JL: I was ready to shoot an email to Steve, with some questions before I
start it.
SG: I was thinking of getting it working with cipso and xinetd
GW: we have done absolutely no test on that. Joy will address issues that
Steve brought up about packages accepting/rejecting based on secpeer.
speaking of secpeer, I haven't heard anything from katherine about that,
I'll ping her.
ipsec-tools: SPD dump and racoon base + MLS
============================================
GW: any word on SPD dump. if it's using netlink it's linux specific, and
the list is mostly BSD oriented.
CH: [Sorry, I didn't catch what Chad said about this topic ... feel free to
fill in]
Device allocation
==================
GW: Debbie is back, are there issue you like to bring up. Matt posted patch
on it
DV: I saw the patch not too long ago, will take a better look at it
GW: hopefully once done, it needs to be tested
Self tests
==========
GW: I'm getting back to those, hopefully this weeks.
VFS polyinstantiation
======================
JD: pam namespace is in rawhide. As for cron and subtree-mount patches,
Steve got commitment they'll be in rawhide, but not there yet, I think
they are waiting for a release window to put it in there.
Cron, tmpwatch, mail, etc.
==========================
GW: We reached the end of agenda .. stuff need to be in 2.6.18. any issues
anyone needs to bring up?
LK: After last week, I though we will have discussion on mailing list about
RBAC. Klaus and George you said you had some thoughts on that.
GW: yup, sorry I got involved. I owe Irena a come back on that as well. We
need to have user/roles policy modules question is, is that going to
taint the base policy.
LK: if we can just have a clear understanding of what the minimum, then that
should be helpful
GW: I agree, we need to do that, we do need to have flexibility to create
roles, change them with out tainting base policy
KW: best way to do that is to say that predefined roles are unchangeable.
GW: I thought we talked about modifying the default roles
KW: better to base new roles on pre defined ones, some programs expect the
predefined roles as is, so you don't want to break those. So you can
just create your own roles as you need to.
GW: I'll take the to do to post something on mailing list on this.
LK: George, also I think there are couple of items on the done/not done list
that need to be updated.
GW: I had things moved from one to the other ... We changed our philosophy
midstream, so I need to update this.
FM: I had a question about trusted printing, how can I attach a label to a
printer?
GW: use device allocator, so try that and see if it works.
FM: ok.. I will
GW: Any other issues we need to discuss?. Ok then let's adjourn the meeting,
and I'll start the conversation about RBAC on the mailing list.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
