08/28/2006 lspp Meeting Minutes:
===============================
Attendees
Robin Redden (IBM) - RR
Lawrence Wilson (IBM) - LW
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Debora Velarde (IBM) - DV
Michael Thompson (IBM) - MT
Joy Latten (IBM) - JL
Thiago Bauermann (IBM) - TB
Al Viro (Red Hat) - AV
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
Linda Knippers (HP) - LK
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Robert (Atsec) - ROB
Darrel Goeddel (TCS) - DG
Chad Hanson (TCS) - CH
Ted Toth - TT
Bill O'Donnel - BO
Tentative Agenda:
Kernel / Rawhide update
------------------------
GW: Any kernel updates that we like to discuss?
SG: yeah I think so, is Al on?
GW: are you on Al?
SG: Well, there are couple of issues with the kernel. There is the syscall
classes and its status regarding upstream acceptance. The user space
piece is mostly working, I am trying to get a patch out overnight, so
rawhide now works with the patch that I sent. I am trying to decide if I
need to build another lspp kernel for people to test with if the code is
not upstream yet
GW: you want to be out of the kernel building business?
SG: yes, would like to, it takes lots of time, but if I have to do it then
we'll do it
GW: So the issue is that we don't know the status with respect to upstream
acceptance
SG: There is the problem Mike found where ppid was not part of legacy audit.
Also the oops in the kernel, it is calling the audit_.._child too often,
I was kind of wanting to raise that issue here; maybe we need to put a
bug on that if it increments. So basically there are few kernel issues
to talk about.
GW: Ok, we'll get back to it in a bit
[AL Joins]
GW: steve was talking about different issues in the kernel
SG: I was checking about half hour ago and it seems to be working correctly
AV: here is what I am going to do, I'll take your patch and cut the stuff I
put in and send that to Linus.
SG: will be really good if we can get that in. There is also the issue of
audit inode child where name count was getting incremented. should we
put a bug there.
AV: we shouldn't try to expand it for simple reason, it has potential of ...
SG: would putting bug statement there be appropriate
AV: yes.. basically we should never let counter get past ... and anything
else that happens is a bug. Right now my opinion is if this problem is
not with file_cache itself, then it should be dealt with. Any activity
needed to compensate for that belongs in the same patch
SG: let me know if Linus take the information. if it takes very long, then
I'll build a lspp kernel
AV: if it is not a big problem for you then it makes sense to do anyway
SG: to build a new kernel. If it goes to linus, we'll pull it within a day
or two. maybe I'll make lspp kernel too
AV: actually, there are two missing pieces, syscall classes for ppc, another
is s390 which is uglier. Same problem, I can easily do native stuff, but
32-bit and 64-bit is just extremely ugly code. I think I'll be able to
deal with that. Basically hookups for syscall classes on s390. I think
by tomorrow morning, I'll have those patches tuned. At that point it
would make sense to build the kernel and see how well it works. It won't
be a problem getting those merged. Have merge for several archs; for
rest it is missing. Adds them for archs that do not have them yet. Not
a problem.
SG: to wrap it up, I'll build lspp kernel probably later today or tomorrow
morning
AV: wait until tomorrow
GW: so, we'll pull that one and do regression testing
SG: yes, should be able to run the full test suite now. the -p option is now
available, it is a bit different, the -a option is not for append now,
it is referring to attribute
LS: Steve, before with the -p, we used to see the perm and perm-mask fields
in the FS_WATCH type record, where are the perm and perm mask going to
be printed at now?
SG: we don't know if it will be printed. I was thinking once we have lspp
kernel, and we can test it and have conversation of what's wrong.
LS: Ok, I have a test case that tests combinations of permissions and looks
for perm and perm-mask, I'll test with it once your new kernel comes
out.
SG: you get the perms part of PATH type now. It is now called mode field.
LS: The mode field is not new, we used to get that before
GW: are we gonna need new user space with that kernel?
SG: yes, I'll put a patch out. user space will be ahead of kernel at this
point
GW: any other kernel or rawhide issues?
SELinux base update
-------------------
GW: any updates on SELinux Dan?
DW: not right now. Was wondering what happened with the newrole
conversation,
is that complete? Any new status?
MT: which conversation
DW: do I need to do anything
KW: Oh, the one about how you ensure people are coming into labeled network
connections. not sure if it is solved, I believe it got held up in
issues about getting labels on network setup. Has anybody experimented
lately to see what happened with that
GW: I have not, anyone did
KW: I guess it is still to be determined whether we use ssh or xinetd to set
up labels
GW: we need to do some experimentation. Maybe Fernando can work on that.
I'll get him to try that specifically.
KW: one thing that has not been helping is the CIPSO config tools and IPSEc
tools don't ship on rawhide. is anyone using those successfully?
GW: sounds like a no
GW: while we are talking about net label control problem, James Antel is
trying to get that in Fedora extra and trying to get it in rawhide soon
KW: excellent
GW: we still need to do the end to end testing.
KW: if anyone has a howto on those tools, it'd be very good if you can put
that on the list
GW: that would be good, apparently it is harder to update the wiki now
KW: yeah, I no longer have edit rights
GW: it discourages people to update it
KW: One more issue about the kernel key ring, I caused some confusion about
patch that I posted to the list. Te kernel key ring will be available to
certain applications and not all users. right?
DW: yes. If anyone requires access, we'll put boolean around them to prevent
that
SG: I think there is a patch in sshd that has a patch to use keyring
KW: it is fine if trusted programs access that, but not any users can access
that and create rings. Trusted programs are fine as long as they are not
accessing user data.
DW: as for the if-sec tools, there are conversations going on about that and
how to get it working. There is a bugzilla and I'll be updating it.
GW: which bugzilla, you know Dan?
DW: bugzilla # 201573
MLS policy issues
-----------------
Audit userspace
----------------
Print
-----
GW: Matt are you on, anything to say? if Matt is not on, anyone else has
anything to say about it. This is another thing that we need to make
sure we have coverage for to make sure it works from a functional
standpoint
Secmark
-------
GW: The consensus was that compat_net should be available for use whether we
include secmark in evaluation or not. My preference is to use
compatibility mode so we don't extensively have to document. I don't
know how acceptable is that from RedHat point of view. Do you have
objections about the configurated evaluation. that is my preference
DW: My concern is that most of those rules are being removed from upstream
policy
GW: If this is something you are not willing to support, I need to see how
I'll document secmark; I need a definitive direction. from what I can
tell with compatibility on, you have options. James didn't comment one
way or the other from a customer perspective. Customers seem to want it
though.
CH: secmark is better at handling of labeling.
GW: I don't disagree it's superior, just how much it increases the scope of
TOE. if I have to test it and document it, I'd rather know now
DW: I'd lean toward secmark
GW: that was my fear. That's why we were asking for opinions, we absolutely
want to do the right thing from a customer point of view. that's real
valuable feedback. It would help if there were existing documentation,
but I know that doesn't exist.
DW: McMillan(?) and Tresys are doing work on that.
[ Linda Joins]
LK: Hi George, this is Linda, did I miss the meeting
GW: not at all, we are discussing secmark, how do you feel about it. I was
talking about having to prepare all the documentation
LK: you already got them documented?
GW: More or less, but we don't have docs on how to use secmark. I'm hearing
we won't use the compat_net, so we need to look at that being included.
Was there final determination made about if CIPSO is included in rhel5.
IB: yes, will be in beta 1
SG: it is in rawhide
SG: but the patches were not accepted due to lack of upstream review
LK: CIPSO itself is in beta1, but those patches were not yet sent to net-dev
GW: what does that mean?
SG: It means there are few little bugs in beta 1, but they are known, we
want to fix that for beta2, but it requires getting it to net-dev first
to get it reviewed and accepted
PM: is this the cipso stuff I just tested
LK: yes
PM: I am doing some stress testing, and if everything is running good, I'll
send patches to net-dev in the morning
SG: Klaus raised an issue about userspace not working with current kernel
KW: yes, I saw that, but did not dig deep into it yet.
PM: if you have more info, that would be great, I haven't seen anything like
that, so send me more info please.
KW: I'll try to replicate it and send it to you
GW: I'll also get one of our testers to test that
PM: I'll get a patch to net-dev and then I'll provide bulk of my time to
userspace tool. The code needs attention, but first we wanted to get
kernel piece out.
LK: Steve you talked about a Sep 8th as date for cutoff, is that still the
case?
SG: we pushed that out a bit further, we need to have it in Fed Core 6. but
that's not alot of time still, maybe extra week or two
PM: To clarify, Sep 8th that's just for feature freeze right? But we can get
bug fixes in after that, correct?
IB: yes .. it is correct
GW: we have a little extra time, which is good, but act like we don't.
CIPSO
------
IPsec: MLS, UNIX domain secpeer, xinetd
-----------------------------------------
GW: Joy need to drop of early, so Joy would you like to give us an update on
the ipsec problem?
JL: I still can't get it to work on ppc. but James Morris is able to get it
to work on i386 and x86. The bug is showing up in upstream kernel too.
Dave Miller suggested I try a kernel from kernel.org and see what
happens without the -mm patches; maybe it is a ppc64 problem. Also We
ran TAHI ipsec and that is ok. I integrated Venkat's patch in, but
didn't test it. I don't want to hold the patch, so as soon as we are
done running TAHI, I'll test the patch and send it out.
GW: so the problem is compilation issue. you think it is a real bug?
JL: to be honest, I am not sure. they don't see any oops on x86 or i386. I
am not sure
GW: you'll continue to investigate
JL: yes, I am trying on kernel.org kernel with out that -mm patch.
GW: Steve got the xinetd patch for us, anyone else tried it?
LK: we didn't try it yet
GW: we need to do that as well, I'll get one of our testers to get some
testing done, need to make sure all those parts work together well.
SG: for any testing it only works for tcp connection. For udp connection,
xinetd doesn't get in the business of reading labeling; so for udp, it
has to take care of it's own labels. I have it error-ing out if you try
to use udp
KW: we can take care of that in the configuration. Also is there a way to
launch ftp daemon through xinetd
SG: I don't know, have to check. I think it's tricky
KW: not sure at this point how ftp service works on MLS system, maybe have
to exclude anonymous ftp
PM: maybe you'll run into problems with ipsec handling if you are using the
ports
KW: do we expect ftp to work
SG: if we need to patch ftp we'll do that later
GW: what would you patch for, to allow passive mode?
SG: ftp daemon can start child process at level of connection that came in,
that's what xinetd will do for it
KW: as plan B, we use sshd sessions and pam module to adjust labels, not
sure if it'll be something that will work
MA: do we have that sshd config information captured anywhere. I am little
concerned we lost some of that configuration lately
KW: which patch are you talking about?
MA: this was just a question I posted on a list and Dan said you can specify
which selinux users you can ssh into, but that doesn't seem to be
maintained moving forward.
KW: I don't recall that
GW: would be nice if we made little better use of wiki to keep such things,
but it is gotten painful.
KW: easier idea is stick this on wikipedia :)
MA: is there any captured docs on configuring MLS cron. Janak was talking
about that
KW: I don't recall seeing specific documentation on that
GW: RedHat maintainer was changing that, so we need to look at rawhide
manpage to see if it is updated well and use that as docs
KW: is is in vixie cron
GW: yes, I believe so, as man pages
DW: yes, it is in crontab
MA: I am seeing it in mine also
GW: any documentation through manpages beats anything on the list, that's
great.
LK: couple of weeks back, I asked janak about polyinstantiation and janak
sent me mail, and he pointed me to pam namespace manpage as well. So
sounds like man pages are being updated.
GW: yeah, I also think it is a decent write up in there as well
GW: Matt anything about label printing
MA: not much, couple of patches from Tim that I applied. I just have couple
of more things on my list. The access check still needs to go in, the
ones I'm doing now will require tweaking of policy, nothing too major,
other than that it is progressing along
GW: alright. going back to where we were. Joy got Venkat's patch integrated,
she wanted to test it when she ran into the ooops, but she'll test it
and send out when she can ensure it is functioning as desired
ipsec-tools: SPD dump and racoon base + MLS
---------------------------------------------
Single-user mode
-----------------
GW: any verification that this is implemented when policy load fails?
DW: I had to get new patch out, my original patch didn't allow for fck(?). I
have one more patch to send
DG: do we want that variable on the config
DW: We put it there since the file existed
DG: it is not doing anything for selinux, just going in single user mode
DW: it is telling us what MLS mode we are in
DG: it is not a MLs thing, just an option of bringing up the system. just a
thought
DW: Hmm, you can give me an alternate file, we wanted a place that already
exists
DG: have you talked to the policy maintainer?
DW: I'll talk to Smalley about it
SG: how about etc/sysconfig
DW: it's a symbolic link to /etc/selinux/sysconfig
SG: this is for the machine crashing if policy didn't load.
DG: it has nothing to do with selinux, just that the machine stopped
working, so let's go to single user mode.
DW: only MLS and selinux cares about it, so we put it there. There is also
fix now so that syslog will log error messages, where in past it was
just a core dump, but it still will not boot.
GW: so it was that change to make it go to single user mode, instead of
panic-ing.
DW: if the machine crashed, but the policy loaded, then we go in single user
mode so admins see what caused the crash
KW: I think this came from RBAC requirement.
GW: is it ok that init panics
KW: as fas as I understand, it sounds like it fulfills the requirements.
init itself shutting down is not enough.
DW: this is happening on bootup process and not shut down process. init
script finds out if the machine crashed through that environment
variable.
KW: that would be fine
Self tests
-----------
GW: have not made progress on that, I'll need to get that done soon
VFS polyinstantiation
----------------------
GW: as best I can tell, hopefully bug fixes are very few, cron patches are
in, just waiting for testing, specifically with mail wrapper. we'll drop
these topics, unless we have bugs. all issues are tracked as bugs and
hopefully you can track everything in bugzilla.
IB: please say LSPP in subject and add me to cc list.
GW: yes, it makes life easier to do reports, we are driving for Sep. 8th as
cut off point, we'll have more time for bug fixes.
Cron, tmpwatch, mail, etc.
--------------------------
Bugs / remaining tasks
-----------------------
Final cutoff date
-----------------
Further meetings
-----------------
GW: Finally, this bring
up the point of how often we need to keep this meeting. Perhaps it is
good to keep in close contact and have these meetings maybe in shorter
durations, or every two weeks. we'd like to keep having the meetings,
what do you think?
SG: we probably want to do keep weekly meeting until beta is out at least in
a few weeks. at that point we'll get alot of testing from ISV.
GW: you have any idea when do we get in hard must fix bugs mode
SG: later down the road. we want to try to get beta 2 as good as possible,
until it comes out, I'd say keep meetings weekly.
KW: as for beta, what packages are going to end up in the next beta.
DW: pretty much what's in rawhide
SG: yeah , pretty much rawhide. and rawhide is stabilizing since it has the
fedora core6 packages
KW: that means we can expect less hickups like init panic-ing
GW: any other issues
MT: one minor audit thing while I have Steve's attention. I sent you an
email about it, "auditctl exclude,always -S all" --should this fail?
SG: yeah that should fail
MT: I don't think it fails though
MT: so exclude list should only be used with message type filter?
SG: yes, anything else should fail.
GW: any other issues ... ok. we'll adjourn. .. thank you
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
