7/10/2006 lspp Meeting Minutes:
===============================
Attendees
Janak Desai (IBM) - JD
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Debora Velarde (IBM) - DV
Michael Thompson (IBM) - MT
Joy Latten (IBM) - JL
Thiago Bauermann (IBM) - TB
Fernando Medrano (IBM) - FM
Nikhil Gabdhi (IBM) - NG
Al Viro (Red Hat) - AV
Steve Grubb (Red Hat) - SG
Irina Boverman (Red Hat) - IB
Dan Walsh (Red Hat) - DW
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Amy Griffis (HP) - AG
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Venkat Yekkirala (TCS) - VY
Joe Nall - JN
Tentative Agenda:
Kernel update
=============
GW: Al, if you can give us an update on kernel
AV: there has been another round of merges upstream. not much, 4 patches
went in right now. I'm finishing up stuff that does lazy work in case we
have no rules. That is what Jason's patch tried to do with slightly
different approach. Instead of trying to check number of rules and avoid
going into audit on syscall entry, we do that call unconditionally and
mark audit context as made when there had been no rules. After that, in
a lot of places we check for audit context non-null and not marked as
call made when no rules, most of them but not all of them. This allows
to avoid more work than Jason's, it generates fairly complete audit
records. We may not want special type for these, we don't generate
auxiliary records for ipc, namespace, etc. We do generate main part of
records. everything that had come from SELinux. Anyway, that is going to
be complete today or tomorrow, and will go into lspp kernel and see how
it works at least that should be safe. Another new thing that went in
(I'm trying to figure out what had been done in last 2 weeks and what
prior), definitely during last 2 weeks, is syscall classes. It is
already
in mainline. Now can have arch declare set of syscall numbers, actually
several such sets. Userland can specify set in high order bits.
Currently, there are sets for syscalls that modify some directory and
syscalls that modify attributes, and 32-bit counterparts of those. It is
in its current form, fairly easy to modify those sets when new syscalls
get added to kernel. Changes are only in 1 place (asm/generic). Adding a
new syscall for all architectures, is just a matter of adding few lines
to corresponding header. It also now gives 2 classes + 32-bit
counterparts hooked only on i386, amd64, and ???. Will need to add
similar pieces to other arch's we care about. This can go in after
freeze
trivially. The problem was getting the infrastructure into Linus' tree.
Steve told me stuff to add userland bits that would use it. That
conversation was today, and I don't know how soon it will be testable.
SG: I think I'll get that out today or tomorrow
AV: Of course we need to decide what other sets of syscalls are interesting.
What sets of syscalls are needed to implement interesting things.
SG: the same ones we had in rhel 4. We can add to those syscall classes but
need to make sure we preserve backward compatibility. Any other
classifications beyond that is icing on the cake and we can discuss on
leisure.
DW: with the changes you are making, will it allow us to run audit by
default
SG: yes. Al gave the long version, but the short version is that this is the
enhancement that allows us to operate with no audit rules and with just
selinux generating rules.
AV: yeah
SG: one other thing I like to point is that as far as I can see this is the
last changes for audit kernel work which takes care of performance
updates and syscall classes. If there is anything else there, please let
me know so we can deal with it soon.
KW: for audit you mean, or in general?
SG: yes, audit. later this week, I'll switch to a 2.6.18 based kernel. I was
waiting to resolve some problems before I switch. When we switch, I
don't expect us to be carrying alot of patches. So we can start opening
bugzillas, and track things that way since all is upstream.
KW: From a timing perspective I expect us to have minor updates and fixes
later on, so it's good to have an interim kernel to fix those quickly
rather than waiting for upstream acceptance for each fix.
SG: yeah, but we can track them with bugzilla.
AV: correct.
GW: Steve, are you looking for same sort of regression testing that we did
last time?
SG: I think Al said he knows how to test the syscall record.
GW: so it's a complete record with no auxiliary record
SG: we are going to want to do regression testing, but we won't have new
records. I do need to have auditctl updated so we have the -p option to
have backward compatibility. hoping to have -p in new release either
today or tomorrow
GW: great. that's alot better than partial record. I'm sure people won't
complain
KW: there was a discussion that open syscall is not working, have you seen
that?
AG: I took a look at that. When you do an open, you do a lookup, and it
looks like it is getting the wrong inode number. looks like we need a
new hook in open_namei, I am not excited about that, but that's the only
way I see now
KW: Ok. thanks for looking into that.
GS: Any new audit issues? Steve you said you'll have new audit out soon
SG: yes. I am also trying to take care of bug with -r option that we saw
last Friday. I also made changes to audit dispatcher. That's really what
is driving the work on the new audit version. Audit needs to be out this
week in order to make it into fedora core 6. if anyone sees anything
wrong, please let me know.
GW: Speaking of fedora, would you recommend we base our installation on
rhel5 alpha
SG: fedora core 6 test 2 (FC6T2) is fresher than that. At this point I'd
lean towards FC6T2. The alpha is a snapshot in time, and there will be
compile and linker changes, so they are planning to rebuild all the
packages soon I believe.
GW: so we'll hold off on rhel5 alpha
KW: we'll try to get feedback to you. I think we have a bugzilla on archs
with 64bit. There is a nasty mix of 32 and 64 packages that are getting
installed.
SG: I need bugzilla number for that, I wasn't aware of it. I need to talk to
people here; seems they are pushing the other way to have 32 bit
packages on 64 machines for development. Developers have been asking for
this in order to be able to develop 32 bit application on 64 bit archs.
KW: But it's a nasty issue, for example the pam modules contain binaries so
if you install both 32 and 64 bit packages, they are getting
overwritten, and you end up with what binaries got installed last which
may conflict with the library you have. When you try to clean up and
remove them you end up with a big mess, and possibly an unusable system.
For certification you need one package version.
SG: if you can point me to that bugzilla so I can take a look at it.
GW: not sure if we have bugzilla, Mike sent you a note I believe before the
4th holiday
MC: Yes I did, but I don't know if there was a reply, I'll check
KW: we need to make rhel friendly, to make it allow for minimal install
DW: in rhel5 you can click and get really minimal install, it's almost
unusable.
KW: I need to look at it, but since it is yum based install, it happily
pulls all sort of dependencies.
DW: you can go to install screen and unclick everything
KW: I like the base option, maybe dependencies to development tools are
aggressive
GW: on mine I believe it installs 32 and 64 packages
KW: we'll get more info to you on that
GW: and we'll get a bugzilla on that as well
AuditFS/inotify
================
GW: Lisa, wanna give us an update on that please.
LSM: Sure. It's going well. I gave updates to steve, also sent him man
pages, and it will be included in next version. it's done now, I'll
download the latest audit patch and try it on my system to double check.
One thing left is if people want me to update the application, or they
prefer to update them themselves. I'll send a note to the list about
that.
GW: I doubt people will turn down help. Thanks for your work.
Print
======
GW: What's going on with print Matt?
MA: It's going well, Dan took a vacation at the right time, otherwise I
would be asking him all about the policy. But it was good, I learned the
policy alot the past week, and got my enforcing mls system to where I
wanted it. Today I actually got it to only display jobs you are allowed
to see. The only gotcha is that I get that when running as sysadm_r
rather when I am running from init. Dan, I'll send you some info to help
me fix that.
LK: Are you talking about cups daemon
MA: no, it's the lpq. if I start it from init I can't communicate to it.
I've gotten rid of all avc messages so now I don't get messages about
being denied. it works from sysadm_r role but not from the init.
DW: you are able to do "service cupsd start" as sysadm?
MA: I can do lpq from user, root, sysadm and all sorts of different roles. I
think sysadm_r is able to communicates to selinux netlink socket. It
appears to be working with exception of some policy issues regarding
lpq. once I fix a few minor things, I should be able to get a 1.2
version out for people to try out. I also started looking into a
targeted system, it seems to be working well. I'm liking where it is
right now. I'll talk to Dan about the policy issues, and it should be
all set.
GW: great, good to have the policy out. Are you looking into putting a
release out this week?
MA: yes, should clear all the issues this week.
GW: great, thanks
SELinux base update
===================
GW: anything you wanna tell us Dan?
DW: not really, I am catching up after coming back from vacation.
GW: Ok, any mls policy issues this week?
DW: Mike and I communicated a bit, We had an issue where secadm can read
audit library while auditadm couldn't in system low. This is kinda
strange, and not sure if that is problem or not.
KW: you shouldn't get any privileges you didn't ask for, but if this
behavior is clearly documented then it's ok.
DW: secadm doesn't have to go to systemHigh to read the audit library, while
auditadm does.
KW: I'm not clear on why it is this way, looks like you gave mls overrides
to secadm
DG: we might want to look at that, maybe do a transition to another domain
to limit the power of the user.
DW: we can do that by change con.
KW: I don't see a fundamental problem with having it be an override, but
people need to be careful on who uses secadm.
MT: what about adding standard selinux users or associating unix login? Only
sysadm can do that.
KW: argument about moving defining selinux users into the sysadm role, t has
been fuzzy distinction between sysadm and secadm.
MT: distinction between having sysadm adding unix user, and secadm adding
selinux user is that, users are at level 0 and can't do anything when
they log in.
KW: We reached consensus that default roles are what is on the system, and
if people want more restrictions they can create users. I'm neutral on
that as long as it is documented well.
DG: secadm can load policy. Aren't we giving secadm root powers basically, I
mean if secadm doesn't like the policy they can just load another one.
KW: In a way yes. It's perfectly ok that admins with hostile intentions be
able to breach security as long as it is not by accident (We assume a
trusted admin)
MT: The point is that you don't do anything by accident.
GW: what about the pty issue, we reached a conclusion on that?
KW: sounds as if newrole -l is broken. Casey had good summary of the issue.
if you are doing labeled networking, once you do new role to change
label, then it should end all communication. you either need some nasty
overrides, or if not, you won't have IO on your console. you can use
newrole to have your labels match. if you want to do labeled networking
with secure shell you have to end up with the right level when you log
in, since you can't change it later. At the moment I don't see how this
will work smoothly. Alternately you can give override capability to
sshd, but you have to be careful about that. Main issue was that now any
normal user can use pty to declassify information. System currently
allows pty to use multilevel devices that undermine mls policy which
should be fixed in new policy that will break current things like
newrole.
GW: so no solution right now?
KW: if we get a tighter policy we should restrict the multilevel devices. So
you log in ssh and stay at that level; you can use virtual consoles and
have each at a certain level.
GW: is there precedence to have users log out and back on to change level
KW: most systems don't seem to permit dynamically changing your level.
GW: alright, I think we need to discuss this on list some more.
KW: two things that might be useful, ployinstantiated ports, or if trusted
program can do a wild card open by accepting network connection at any
level.
GW: that's dangerous, we need xinetd to do that
DG: we have something similar.
KW: Is there a set of patches available
DG: Venkat is working on current patches porting to use ipsec base, by
Wednesday he should have that out.
GW: Is he planning on releasing an sshd patch as well
DG: I'm not sure how all that fits. It will take a level of connection and
label socket correctly, it will limit level of child as well.
PM: netlabel patch does the same thing almost, if someone wanted to try that
they could
DW: do you prevent them to use new role then?
KW: I don't think we need to prevent it as long as newrole prevents info
being sent to the socket.
GW: this deserves more thought and discussion and we need stephen's input
KW: so it's a heads up, there might be more code changes to be put in to
make this work
GW: yeah, changes to sshd which we were hoping not to touch.
CIPSO
======
GW: Paul, what's going on with CIPSO?
PM: New patch out. steve and I had a back and forth discussion on right way
to handle the whole parent/child nightmare. I took his comments into
account and incorporated the, but I haven't heard anything more from
him. This should be the last round of issues. last two remaining issue:
how to deal with unlabeled packets? there is also another question of
finer granularity regarding selinux checks. There is not much code to be
written, but any new code will break backward compatibility. There is a
RH bugzilla 195238, about adding new selinux features without breaking
backward compatibility. Aside from feedback, I think I'm done with net
label stuff with for this evaluation at least.
IB: when do you think you'll have all changes completed
PM: as soon as we get all the issues resolved, I can have it done soon. if
it is resolved today, I can have the code done by end of this week
GW: great, sounds good. Thanks
IPsec: MLS, UNIX domain secpeer, xinetd
=========================================
GW: Venkat asked for testing help. joy and I worked with fernando to set up
tahi. found bug on ipv4 and ipv6. so far it's looking good
FM: yeah, bugs I found were fixed with venkat's latest patches
GW: now we are setting up udp to work with xinetd. are you getting enough
testing on cipso paul?
PM: Ted and I have been working on it. Every once in a while, if people from
IBM with trusted AIX can check every couple of kernels to ensure I
didn't break anything real bad. But I think it is ok from a unit test
point of view.
GW: we've been focusing on ipsec. joy was going to try to run stress tests
JL: I am setting them up as we speak, I'll set them up before I leave today.
GW: are those gonna be in enforcing
JL: yes, I 'll first make sure nothing regressed, once that is checked I'll
check with latest policy
GW: Venkat you on?
VY: yes. I should have a patch out today. Tomorrow I am planning to clean up
the whole thing, then break it up for upstream submission
SG: James morris was interested in seeing patch posted to netdev and audit
list
VY: yes, I'll send it to netdev tomorrow or day after
SG: Steve Mill(??? not sure about the name) said he is willing to review
your patch. also James morris was looking at patch on netdev. So please
make sure patch goes out to netdev. if you have to do two patches, one
for us to test with and one to submit, then I say go ahead and do that.
the netdev guys are interested in driving this one home and finishing up
work on it, also we need one to test with. so please send to netdev.
James wanted me to say that this is going to be needed to get done soon,
since this is past deadline, but we are accommodating it so we need to
move quickly
LK: so is the network patch going in the git tree?
SG: Ah, I don't know. Maybe it is possible to do it as stunnel kind of thing
where cipso is done in userspace.
PM: steve, that is ugly
LK: we posted patches and expect it to be taken seriously
IB: we are trying really hard.
GW: from IBM perspective we would really like to see the patches there as
well
LK: we are not dumping this code, we are maintaining it, so I don't see what
the problem is.
IB: It would be helpful if we have an impact statement to prove the business
case.
LK: well we did that, we had customers on the phone also backing this up.
IB: if your business organization has a document to prove the business case,
that would help alot.
GW: if people with customer contact can give feedback, it would help too I
believe.
SG: that's what I was saying about the issue tractor. we need people to look
at it. I think I have two levels of management on my side saying we need
to get this on .
LK: who is the next management level name name, send it to me please. I need
to know my escalation path.
GW: anything we can do on our side to push this further
SG: you guys have done very good. Klaus' statement was really good. All we
are missing now is numbers.
IB: there are also test results, if we can show these
GW: we have not done much cipso testing, but we can do some if there is a
need
PM: they did that and posted results a couple of weeks ago, I think on net
dev
LK: George, maybe you can do something with your RH alliance path to push
this.
GW: also I know some people might not want to share numbers in public, but
at least if they can share it with you Irena. The business case is
there, it's just a matter of demonstrating it to those people with the
strings.
LK: It had both technical and business issues. we solved technical issues,
and now we need business issues taken care of.
GW: we'll try our best. what about xinetd steve?
SG: I'll try to work on that and get one out before I head out to OLS. I'll
be out starting Friday for that.
ipsec-tools: SPD dump and racoon base + MLS
=============================================
GW: we still have the spd dump issues but that is secondary to network
issues. Anyone tried device allocator especially with print? I think
that should be interesting to see how it works.
Self tests
==========
GW: I got back to that this weekend. but I've been working on performance
tests. I should get new self tests in the next few days.
VFS polyinstantiation
======================
GW: Janak, anything new for polyinstantiation?
JD: couple of minor things. pam namespace module was accepted upstream. I am
testing namespace with policy changes and playing with tight member
rules. I'll be sending patch to newrole, because it's not using pam for
session management. It's upstream and people are testing it
GW: cool, any word on cron?
JD: no, still waiting on maintainer.
GW: big thanks to Amy for all her work. we just need to get all remaining
items closed. other issues anyone wants to bring forward right now. Ok,
let's adjourn the meeting. Thanks everyone.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
