6/26/2006 lspp Meeting Minutes:
===============================
Attendees
Robin Redden (IBM) - RR
Janak Desai (IBM) - JD
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Debora Velarde (IBM) - DV
Michael Thompson (IBM) - MT
Lawrence Wilson (IBM) - LW
Nikhil Gandhi (IBM) - NG
Al Viro (Red Hat) - AV
Steve Grubb (Red Hat) - SG
Irina Boverman (Red Hat) - IB
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
Ted Toth - TT
Joe Nall - JN
Tentative Agenda:
Kernel update
==============
GW: Al, would you like to give us a kernel updates?
AV: Most of what we had a week ago got into the tree on Tuesday. Right now
the problem is we've been asked to do something similar to what RHEL4
did, namely check for r/w/x, all such stuff, for files. We do have patch
that allows to define classes of syscalls and I am keeping them up to
date with changes--32 and 64 bit binaries on same kernel. Original
intent of this patch was to do stuff like allow audit to ask to watch
syscalls that change directories. keeping userland up to date is
unpleasant; better done in kernel, we want kernel to expand the set of
syscalls based on bitmap from userland. It looked like we should be able
to do this, unfortunately, when tried to implement on top of syscall
classes, and realized that actually the behavior we used to have is not
particularly well defined. example: say we do link: modify 2 objects,
namely directory where we link object, and modifies metadata for file
we're linking to. what should this thing be considered? change or read,
because we also do read access to bunch of directories at very least,
parent of file we are linking to
SG: I would think a link would be a write
AV: yes it is a write to two objects and a read from many more. Thing is it
has been said many times that we can't just use watches because we want
checks done before access control. We want events even when access
control denies operation. That is fine, but not quite consistent. Don't
know what a pathname will resolve to until you have passed a bunch of
access control checks. If it ends on a symlink, don't know where it
points to unless you get it from the fileserver (for NFS), if NFS
refuses to let you do the lookup, you will never know what it is, you
don't know what pathname resolves to ahead of time. You don't manage to
generate events regardless of what access control does. It depend on
previous accesss control checks given positive results. We don't get
consistent semantics for what used to be done in RHEL4, and it would be
nice to figure out what we want semantics to be and how much of code we
want to emulate, and how exact do we want the emulation to be.
SG: that's a big piece of code that people are using.
AV: can't say how pathname will resolve if we get access denied midway
through resolution. It is not a matter of syscall or not, just
permission we cannot get out of server, now back to question about link
SG: I think we only want to have 4 groups rwxa, I know there is 1 or 2 holes
in getting attributes or not being able to set watch. this may be kind
of thing to put something out there that maybe klaus or stephan can
critique. ultimately, they need to help us decide which syscall goes
where and what we need to log. sometimes if you have watch on something,
it never gets inode, so it will never trigger a watch
AV: no we couldn't since we ...
SG: I think the next best thing is take user string to OS and record that.
but still I don't think we will generate a watch record. if we have
syscall rule that was triggered, you'll see a record and access denied.
KW: in previous evaluations, we used requirements that you have audit on
objects,
and if you didn't get access to object, then you don't need to audit
that operation on the object
AV: ok now back to question about link. it changes contents of directory and
changes attributes of target. Now, we can filter on syscall being
writing or modifier of attributes and see that it had triggered watch on
directory or target respectively. Question is how to combine it? what we
see is 2 objects have been touched, 2 watches have been triggered. We
see that syscall was a link and we are watching for changes of contents,
in fact how do we decide which of the touched objects have change of
attributes and which a change of contents. looking at it post mortem, at
syscall exit, we see 2 places touches, we see syscall was link.
figuring out now that we are watching for change of attributes.
KW: one thing is I'm not sure how security relevant is this. Point is that
when someone tries to access file you get record if they do access
through hard link or through name.
AV: indeed, but that applies to any syscall that would generate events on 2
different filesystem objects; 2 that are of a different nature.
SG: I think the way rhel 4 worked it included 3 different object, for
example if
you did a move ..(Al interrupts)
AV: Move is alright, that is different. let me ask a more specific question.
We are watching for changes of attributes of given directory. We create
link of that directory to some file. Syscall touches some directory;
syscall changes attributes of one of objects it touches. Did rhel4
generate a records from such an operation? Problem is we did change
directory and some attributes, but not of that directory.
KW: not entirely sure I understand the question. what would be relevant is
creating name inside directory, which is interpreted as a write. if you
have watch on a link, you would get record
SG: we need to define what a change of attribute is
KW: should be security relevant like owner or perms, but the increase in
link count is not relevant
AV: yes you would care.
KW: but this is not an area that the protection profile defines. This is
where we trust applications to do the right thing but didn't examine it
in detail.
SG: the changes in attribute, extended attributes in acl, the attributes in
filesystem is what we care about.
AV: what about time stamps?
SG: time stamps are not interesting
AV: ok, one more thing. There is a case where write can change attributes;
when you have write to open file that happens to have suid bit set then
this will be a write.
KW: you mean open?
AV: no on write; happens on write; it has to
KW: this is new to me, but I don't think it's a security issue.
AV: doing that is security related; I know this way which is to say, even if
you got write access to suid binary, any attempt to actually modify it,
will lead to binary not being suid.
KW: I mean that's kind of a nice feature, but not required.
AL: posix requires it
KW: but we are not concerned with posix requirements here.
AV: I think it is very standard behavior
KW: we are mostly concerned with capp compliance. it's nice if it behaves as
you said, but we don't need to go the extra mile to cover everything.
AV: what about file length
KW: not important.
SG: keep it simple, user, group, access permissions., changes to acl
AV: ahm, ok fine
SG: just pieces that deal with ownership and access. Also for directories we
are interested in same attributes. but not actual entries
AV: what about operations that change both? you discard link count--fine.
ok, there might be some need for additional work namely in some cases,
we
will have to look at more than just what syscall it is. Let me explain;
thing I am thinking about is; basically how much info about syscall do
we want in those situations?
SG: need to know which kind of access was attempted
AV: that is mostly a function of syscall number. that is the point, knowing
syscall number gives us almost everything.In some cases we need to go
further, namely flags to open.
AG: in rhel 4 we had fields that would indicate the mode. I want to think
that was the mask.
SG: well there is no concept of mask, it might be a place where these things
were reported. don't know if we want to keep adding things to syscall
records. on other hand maybe someone clever can put something into new
key to indicate rule was attribute change rule, or a read, or something
like that.
AV: alright, ok. what do we want from existing rules? if we have rules
created on each, say chmod, or better yet, chown. I have rules with this
syscall number as a filter. what do we want it to do when we deal with
32-bit process? keep current behavior?
SG: that's tangent I agree
KW: requirements are same if you have 32 or 64 bit
AV: the thing is, we have different meaning of syscall number for 32- and
64-bit processes on AMD64. Now current behavior is userland gave us a
list of interesting syscall numbers, that condition satisfied whenever
system call number matches one in the set no matter whether from 32- or
64- bit
KW: that's why we have arch field
AV: A syscall, we can discriminate on that. what do we do if rules has no
such field?
KW: then people would get what they ask for. if people care, it's tricky to
get that right. in real world we have audit rule to get this info right.
Now it's acceptable that if people specify something broken then they
get something broken back.
SG: So if people specify something to /etc/audit, then they can specify that
there
AV: correct ..
SG: I think we need all syscalls related to writing
AV: that's fine, that will be done. That's very few classes of syscalls;
certainly anything that does write is no problem. How fine grained do we
go?
KW: need arch number. userspace should put right syscall numbers to the
filter, people who care about audit requirements would need to be
running a specific version of audit. so people running new kernel with
old userspace, then it won't work, no need to make kernel smart about
this.
AV: yes, understand, pleasant moment. if you ask to watch for fork and exit,
you will get nothing because recent libc uses clone rather than fork,
and exit_group rather than exit. It is not generated by library calls of
same names
KW: we encountered that before when people are complaining. this logic
does not need to go to kernel, we only need user tools or something.
it's sufficient to have example files or config files to show how to do
it. These are all valid points, but people can get it wrong if you don't
know how the low level things work.
AV: ok, oh by the way, question for Steve. how do names of syscalls get
resolved to numbers in userland? where do you get 32-bit numbers, when
things are built on 64-bit?
SG: we take look at arch field, and based on that we see it in a lookup
table
AV: I see.
SG: we have all syscall tables for all arch we support in memory
AV: Hope we never have to support MIPS. There are 5 sets of tables there. Oh
well.
KW: Alternate choice is that for things that you don't want to support, then
you can disable those
AV: RHEL doesn't support MIPS at all, so that isn't a problem.
KW: example was that on ia64, they completely disabled 32-bit. not the best
way, but for functionality it's better to disable than jump through
hoops to get it to work
AV: that wouldn't be practical on PPC, SPARC, or any arch 64- doesn't give
much over 32- bit in userland. others, well synchronized between 32-bit
and 64-bit
SG: I think that anything else on this we should take to the mailing list.
GW: alright, sounds like we are resynced again there.
AuditFS/inotify completion
==========================
GW: anything on audit fs or inotify
AG: since last week, all patches went in, since then I'm updating our audit
test suite, hoping to shake out any bugs
KW: is that the audit suite you published on sourceforge
AG: yes, and probably we will need to release an update once we have those
KW: thanks very much
GW: yes thanks a lot
LSPP kernel issues
==================
GW: I've been working on getting performance readings. I am trying to
resolve some problems and see what varying numbers of watches and
syscalls do on performance. if there are any interesting variations you
think I can try, post on irc, mailing list or email me
SG: are you testing on 64 power pc, or 390?
GW: yes this is 64 way ppc
SG: Ok, because there were issues on 390
GW: these are standard bench marks we run. The main point is that I am
trying to get some numbers, hopefully I'll have some by end of the week.
This looks like good kernel, I haven't had problems, haven't tried the
networking though
Audit userspace
================
SG: right now, the lspp.39 is in build system. I got patch from Venkat, and
I added that one to the .38. so the .39 will be combination of both
patches, maybe within 1 hour. on userspace, I've been working on new
release. I finished integrating the key patch that Amy sent. made few
changes for backwards compatibility, hoping to get new audit userspace
out in next 24 hours. My highest priority right now is the audit
userspace
GW: ok, we'll upgrade to that once it's out .. thanks
Audit failure action inquiry function
======================================
LMS:I sent updated patch out, people can look at that and send comments,
need to create man page, as well as update audit open man the patch
mailed to audit mailing list?
LMS: yes, about 1 hour ago. If you don't see it, let me know I'll send it \
again
GW: I see it off the lspp list here
SG: ok, I'll look for it
SG: thanks lisa
Print
=====
MA: had minor hardware problem, they are now resolved. I got update from
tim that version <...> will be in rhel 5. I got patch from Smalley that
clears up lpq issue. also have policy updates. I would like to get 1.3
version of cups out mid this week so I can get response from people over
the long break.
GW: we have intern, Fernando, you might have already talked to him, who will
be helping test this stuff
MA: I guess I also need to get some test development as well, but waiting
to get this out
GW: he should be able to get you feedback, we are also getting a physical
printer soon, and should give you some feedback
MA: great, looking forward to hear from him
SELinux base update
===================
GW: is Dan on?
SG: he is on vacation
GW: right, does anyone have any issues to bring up regarding this?
MLS policy issues
=================
GW: any mls issue, Mike this is your section here, anything you want to
bring up?
MT: none as of this moment, I did have a question, the semanage utility, the
man page is out of date, there is a concept of labeling prefix for user.
Anyone knows what this is, because I don't understand it's purpose. if
you do semanage user -l, you'll see it. what is it and how do you use
it?
DG: I believe this is related to the home directory.
MT: you mean you would use it in labeling /bin/user_t
DG: I think it wants to match up to role you log on as, I am stuck in old
policy, so I don't have great time playing with this.
GW: so it's not documented in man page
MT: it's not documented at all. It's not clear on how to use it. I might be
using it incorrectly or not, so I am not sure
DG: can you dump information on user
MT: yes, you can do semanage -l and you'll see the label
KW: does that interact with polyinstantiation, do we have to polyinstantiate
user home directory?
JD: there is probably some interaction there, so far I've been working with
very simple rules. I need to play with it more since people are working
with it now and want to know about setting up tight member policy.
CIPSO
=====
GW: paul, anything on that?
PM: I posted patch to net dev last week, at least david miller looked at it.
he had comment about patch ordering, so I reordered an pushed it back
out. What concerns me most is about having CIPSO in kernel at all
regardless of implementation. Some people posted that CIPSO is
important, so I'm grateful to that, james morris said it is nice to
have, but not much more. One of comments david miller had is to use the
generic network interface, so I am making changes to that. once that
looks ok, I 'll push another patch out. there are couple of issue I need
to work out
SG: there are 4 different config options. you think people will need that
much flexibility
PM: I think so
SG: when will you turn other stuff on/off, I am compiling with all on
PM: sometimes you won't turn some stuff on, if you don't want unlabeled for
example.
SG: I suggest you consolidate options, one of the things I read in the
verbiage of comments is about the complexity of the code
PM: well, changeling config options will not change the code
SG: I understand, but there is about 16 different options with the
permutations
PM: I think there is a total of 6 options, which ones would you remove?
SG: if the answer is always a yes, then these are candidates to be removed
I'd say
PM: yeah, but I don't think there are any options that are always yes, there
are defaults
SG: I see, but I think it is something you should consider
PM: I understand your point Steve, so if you have a specific argument, or
you can pinpoint, please let me know.
SG: is the Argus group on lspp list?
PM: i think they are on lsm list. only thing anyone is getting rid off, is
the cipso option, but I'd like to keep it so we have option to put ripso
later. I see it going out then us putting it back in
SG: I am trying to help you get it up stream easier, so trying to think of
things to help you
KW: does it hurt to have the support for unlabeled packets always on? people
can reject them.
PM: I don't know, is Ted on call
TT: yes, I think we need to have labeled and unlabeled.
KW: I am thinking to have it at compile time
JN: I think it is depending on the customer, if Argus guys, or Red Hat have
them on.
PM: we can put them as compile time options. turning things on and off is
very little work
LK: even if it is a perception
PM: if that's what people want, then I'll drop it.
LK: that's the feedback you are getting, so maybe have a run time option
SG: that might be necessary to get initial acceptance, then later it can be
added
KW: another related question. Paul, do you have a set of selinux policy to
put mls constraints on packets
PM: haven't done any work on that
KW: I don't know where to start on that, but how much policy would be needed
to get things working
PM: the policy shouldn't be too substantial. there shouldn't be changes to
mls constraints. the only thing I can think of is the TE policy. I think
in current configs, it uses the socket type.
KW: I think it would really help to have sample policy which doesn't do any
TE, but at least allows MLS to do its job
PM: I can do that, but I need to get some things done first
GW: test policy would be very helpful, another intern project for us is
building that into a kernel.
IPsec: MLS, UNIX domain secpeer, xinetd
=========================================
GW: Venkat has done considerable work, not sure if it is enough to get in
the window. I suspect not, unless something drastic happens
VY: I got email about wanting requirements and design, we have something we
are reviewing here, and should have it out tonight
JN: I am looking for a "how to" to line systems together to get them to work
together
GW: I think Joy put out something on that
JL: I can send the tests I used. It's a way to avoid writing new policy.
I'll send you basic config file that I have been using.
GW: you'll post to the list?
JL: yes, I'll post to the lspp list. if you want additional settings, you
will need to write a policy. eventually we should put something about
users, and how to use something other than user_t.
GW: thanks. makes sense . I don't think there are any issues with secpeer
data gram, any one knows if it's in
JL: I haven't seen anything
GW: as far as I know, I think it is slated to make it. Any fun with xinetd
Steve?
SG: I have the patch working on it, but I shifted priority late Friday, and
started working on audit userspace. I'll try to get the xinetd as soon
as I get audit patch out the door
GW: what's the thinking about the polyinstantiated ports now. I can't find
the discussion we had earlier.
JN: I can tell you about that. We had that one feature about trusted
solaris,
you can combine polyinstantiated directories and ports, and it works. we
never actually had it, Ted and I did work on trusted solaris, and it was
nice, it is nice feature to have. but if it is competing with CIPSO or
network labeling, then those are more important than polyinstantiated
ports. I haven't been wanting to ask for them because we are at risk of
not having trusted networking at all
CH: Joe is right, they are nice to have, but there are other things that are
more important
GW: even if not for this evaluation, then maybe keep it on the radar.
JN: I was hoping someone can ...
CH: I was hoping it will be there with containers, and polyinstantiation
JN: would it make difference if more of us looked at Paul's code on net dev
GW: yes, it will be very helpful. people who are on the field, your comments
carry a lot of weight
KW: especially since the requirement is to deploy selinux in environments
that you couldn't deploy it in before
JN: I think not having the labeled networking make this a bogus
certification.
GW: we need to do what ever we can to help the networking stuff go in as
much as we can. if not 2.6.18, then we should at least try, but we also
have to have fall back positions. And we probably need to discuss what
those fall back positions are.
ipsec-tools: SPD dump and racoon base + MLS
=============================================
GW: still need to keep spddump on radar, but there are bigger issues, as dev
allocation. I saw patch from Dan, but I don't think it was renamed.
CH : ...
Self tests
===========
GW: self tests, I need to get back on that, but I've been working on bigger
machines and am considering that to be a high priority
VFS polyinstantiation
=====================
JD: I need to send the patch for newrole. newrole uses pam but not the
session management of pam, so should be a simple patch. I am also
playing with some new rules so that people can try. it's in rawhide, so
people are testing it
JN: after setting up some stuff, I was getting better results
JD: ...
JN: I am still not getting what I consider consistent results between ssh
local and remote, su and login. I'll give you more feedback on that
JD: ssh used to stack the pam module which it is not doing anymore. with
lack of that, you are Dependant on policy. I'll look at it and ask
questions on list
JN: that would explain why I get different results every time
JD: getting different context
KW: curent newrole behavior is that you stay in same context as you log on.
if the directory you are in doens't exist, should we have logic to
handle that
JD: I think it goes one level higher, but I'll look at it
KW: I think it might be nicer to have it fail rather that changing directoy
since people might get confused. I'm flexible on that, as long as if it
is visible
GW: what about cron, have you heard from maintainer
JD: no, I am waiting for the vixie-cron overhaul, but so far haven't heard
anything
SG: Jason is still on vacation, that's probably why you didn't hear anything
yet
GW: Ok, any issues we want to bring up
SG: not really an issue, but lspp.39 is built, and I'll post that
GW: you recommend I move to that for bench marking
SG: only thing it has different is the two patches
GW: that will have cipso as well ..?
SG: yes
LK: steve, have you seen the patch on object labeling
SG: yes I saw that, but I didn't include this so that we don't have many
changes. I forwarded to Dustin, since we talked about this earlier.
GW: did you hear from him steve, I know he is working on another project
SG: not yet, I just forwarded this afternoon
CH: there was original implementation on filters .. but I think it fell
through the cracks
SG: I was backtracking to see if it did fall through the cracks, or we made
a decision about it. I'll include that next time. but we still need the
userspace.
CH: any idea on names is great, I wasn't thrilled with the ones we had.
SG: We were talking about subject, user, role, and sensitivity all matching,
and I am trying to figure out why we ended up with what we got. If we'll
have 10 different things, we need to drop the <-t> off it so it will be
easier. Outside of us, who is really using this stuff?
KW: one note about restrictions, RBAC only talks about roles for subjects,
and maybe that's why we didn't talk about roles for objects
GW: any other stuff we need to discuss .. alright .. thank you all. We will
not have a meeting next week ...
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
