[redhat-lspp] LSPP Development Telecon 11/06/2006 Minutes
Loulwa Salem
loulwas at us.ibm.com
Tue Nov 7 00:33:59 UTC 2006
11/06/2006 lspp Meeting Minutes:
===============================
Attendees
Robin Redden (IBM) - RR
Lawrence Wilson (IBM) - LW
George Wilson (IBM) - GW
Kris Wilson (IBM) - KEW
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Joy Latten (IBM) - JL
Kylene Hall (IBM) - KH
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
James Antill (Red Hat) - JA
Matt Anderson (HP) - MA
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Chad Hanson (TCS) - CH
Tentative Agenda:
GW: I hacked on self test and I have something to put on the list, it is
still incomplete but you can use it to test what you have now. Thanks
for the policy Matt, I didn't try it yet.
MA: It should be good, just make sure you put that option in there, the one
I sent you in the email.
JA: the aide policy seems to include a massive list of types at the end. Is
that all the types it looks at?
MA: yes
JA: my problem is if someone installs lspp and have aide to look at it, then
it needs to be added
KW: it would make more sense to give aide a read override
MA: perhaps that works
GW: yeah, might make the most sense
Kernel update
-------------
GW: any one wants to talk about current kernel. I had a problem with LVM and
the milestone 8 build. It maybe how my initrd got built, any one ran
into that? alright .. apparently not. I'll try that again with lvm,
maybe a driver didn't get included. Any one has anything to talk about?
is IPSec working?
JL: yes, so far everything seems ok
GW: did you run stress tests
JL: not for .54, but I can start one today. Steve I'll mail you my audit
changes, I made alot. I'll run stress test with those audit changed
before I leave today
SG: ok
JL: I have not seen any problems in that regard
GW: to the extent that we tested it
JL: yes, the tests we ran so far seem ok
Beta / Rawhide update
---------------------
GW: any problems with the current beta. I think the install went smoothly
KW: netlabel tools are now in beta, so I updated the kickstart. The latest
beta, does it already have all pieces needed for labeled ipsec, or we
need other pieces.
JL: I think we updated the policy. but that might have been the previous
beta
KW: the latest has the 2.4 policy, so that should have all the pieces, if
not please complain
GW: so you shouldn't get anything out of rawhide now
JL: no we shouldn't
KW: At this stage, we should be able to use just beta, maybe get a kernel,
but things should be in beta
SELinux base update
-------------------
MLS policy issues
------------------
GW: Any policy issue?
KW: I am unable to login in enforcing mode for level other than non system
low, as range s1-s1, I also tried local login
GW: I set an ealuser to have middle range
KW: and that worked for you to login with?
GW: yes
KW: ok, it may be something I am doing wrong
MA: some of your early KS script, you were creating user with 255
categories, is that fixed
KW: I fixed that a while ago. I had to hardcode it in since the label
translation daemon is not running at that point.
GW: I loaded james level selection on my box, but I could not get the policy
built.
JA: obviously the rpm built. the policy bit already got in RH. if you get a
really recent version from them that should work.
GW: I grabbed latest rawhide policy Saturday or yesterday, and I used your
libselinux. when I log in as root it will prompt me. I added this stuff
to selinux module, sshd and login next to the open
JA: right
GW: I also put the debug stuff to tell you what the context is. When I put
in enforcing, it would kick me out if I try lo login as root or ordinary
user. I need to look at it and do some analysis. Do you expect people to
enter an entire context there
JA: just enter the level
GW: also enter the translated level
JA: yes. if you press return without typing anything, then it will get the
default level
GW: I need to play with it a bit more, it is not working as it used to in
the past
JA: one big difference is level selection with tty. I assume ssh would let
you do that. I don't think that is the reason it logs you out.
GW: I need to go see what the denial is for. If I can't get that working,
I'll catch you on irc maybe
JA: sure.
GW: if we get that working, that'll be pretty nice to have. what about
newrole patch
MT: I sent out latest patches on the 2nd. It is broken up into smaller more
readable pieces. The change was adding in the preserve environment
option using the -p option when you newrole like when you su. That new
functionality caused better changes in the code. I have not seen any
replies to that yet, so if anyone on the call can read it, that would be
excellent. By the way, it looks like the list duplicated my sends, so
there is only 8 emails, not 16 to read.
PAM, Newrole & VFS polyinstantiation
------------------------------------
GW: Anything on polyinstantiation. Actually, I am wondering if maybe that is
what is causing the logout.
KW: I haven't changed that recently in KS. one thing to watch out with
polyinstantiation is that it is fragile. you need to make sure the home
directory has the right level if you change it. if it is at the wrong
level, it will be messed up and won't be fixed if you log in again
GW: maybe it's polyinstantiation that messed me up. I need to think about
that. Also, I was able to kill my system with audit messages with the
self tests, not sure what caused that.
LS: I had the same problem.
MT: I saw that before, I think I had to fix the context of the file it was
writing to
LS: It may be that, because I did a relabel and that's when it happened
SG: in the kernel there is supposed to be a fix that audit doesn't audit
itself
GW: I am not clear that is what's happening, is this bug worthy?
MT: audit gets sent AVC messages, maybe if it is getting avc denial ..well
.. I'll take a look at that
GW: we'll do more investigation and not open a bug yet unless RH wants that
SG: it really is a design preference. audit doesn't audit itself, but
selinux is a different subsystem and it is not aware of that, so it
might audit the audit system.
MT: seems like it is going in an infinite loop.
GW: we'll recreate it and open a bug on it.
DW: I would think it would kill the audit daemon
GW: no, it was pretty much alive
SG: I want to think there is a control that admins can set in the config
file, let me look at that .. disk_error_action, that might help. it is
set to suspend for me here
MT: mine is currently set to single
SG: I think it would trigger a disk error action
DW: disk error action will cause AVC, so that is a problem
KW: KS sets it to single option
DW: bet the policy does not allow you to drop to single user mode; if so,
this is a bug.
SG: need to halt the action, and send an email
DW: I think it can do that ... Steve, we'll review audit policy tomorrow to
see it behaves properly
GW: I want to go read audit daemon pid file, and can't do that as secadm
DW: you're running at system high?
GW: I think it is ... we need to test these issues now .. good we are
hitting this rather than customers
SG: are you writing this in python, I think you can do get status of audit
system using lib-audit. you have to have audit capabilities in case
something fails.
GW: I'll try that
SG: I believe it is audit-status
GW: you think it is reliable?
SG: The only time it is not reliable is if auditd died due to segfault and
still didn't tell the kernel that happened, in this case, there is a
window when it is not accurate
GW: ok, I'll try that
SG: that is what pam is doing I think. if pid is 0 then either kernel
detected no auditd or auditd shut itself down cleanly.
GW: is there way to say it died badly
SG: the next time the kernel sends an audit msg it would know. I would think
when a process dies, kernel would know. It is a matter of connecting
dots and saying auditd died.
GW: I think it is sufficient to check it this way since this will be a
periodic test. let me try that and see how well that works
MT: I am playing around with python audit and trying to figure out how to
use it. audit_is_enabled is a function that needs one argument, but is
there documentation on what that needs to be?
SG: I added man pages, but I am not finished adding that
DW: semanage uses audit system, so there might be code to look at there.
Audit
------
Print
------
MA: Now that Eduardo is asking me, I just started going back to look at that
more. I'll check out those test cases that he brought up.
DW: policy for range stuff should be out, it just came out today.
GW: so we should be pulling that policy from rawhide
DW: yeah, for this one
SG: general warning, rawhide is starting to diverge from main rhel
GW: we basically should be getting away from installing from anywhere but
beta. we need to be clear on what packages to install, like aide
JA: well, aide in rawhide is controlled by someone else out of RH, so the
official aide is the one we have with beta
GW: I am running the one on your page james
JA: yes that is the correct one
GW: pam, aide and the kernel are to be updated on top of beta. what about
the iptables packages?
SG: i think the one in the 27 beta is the one in the yum repo, the name,
version and release should be identical. In rhel5 branch, we put the
patches for iptables.
GW: ok, great... so any other things we need
KW: the kickstart script, which will not be available in RH until much
later.
GW: if folks know of additional packages bring them up on the list
CIPSO
------
GW: since paul is not here, and I think cipso seems ok we'll skip this now
IPsec
------
GW: How's ipsec?
JL: I did testing on the .53 kernel, I ran labeled and unlabeled ipsec.
everything passed fine, so I'll do that tonight on .54.
GW: is MLS working ok
JL: working ok according to the policy. I haven't seen anything that I think
is incorrect so far, as far as mls is concerned that is
DG: venkat gave me update, there is patch coming out tomorrow morning. the
SA selection, and .. those should be out tomorrow
GW: ok, thanks Darryl. so we need those bits in before we do comprehensive
testing. do we know when will that be in the kernel, beta or lspp
kernel.
SG: Is Eric on the line?
JL: I have a question, is there a mechanism to toggle accept or reject
unlabeled packets. when I set labeled ipsec, nothing unlabeled is
accepted. I know we talked about a toggle option, anyone knows where
that is?
DG: I am not sure, probably send a message to Venkat on the list.
JL: Ok, I'll do that
SG: Back to your question George, we are still able to pull patches to
kernel. that's still open for us to use. I would like to get out of the
business of lspp kernels. the pre-requisite is to get development done
and there are still stuff to be tested, we'll build that and do whatever
it takes
GW: so we'll expect one more lspp kernel with venkat's work
SG: as soon as it looks stable, we'll pull it in
GW: ok, so on the next kernel .55, we need to really hammer it hard for
ipsec stuff.
JL: and I'll send that audit stuff
GW: how is that going
JL: good, I'm done, just need to test it.
SG: one thing to test is turn audit system off and see if audit messages
still come through. some systems don't check the audit-enabled state
before they send messages.
GW: should we compile audit out of the kernel as well
SG: yes, probably before it goes upstream
GW: So check audit enabled, audit off, and audit compiled out of kernel
completely.
Labeled networking stabilization
--------------------------------
xinetd
-------
GW: word on xinetd
SG: no
KW: is there specific examples of how to set sshd with xinetd. I have not
seen examples on how to configure that.
GW: have you used sshd
JL: I have only used sshd ..
KW: sshd is supposed to break with unlabeled unless we have that fix from
xinetd.
Self tests
-----------
GW: Matt has been asking me to release what I have available. I need to do
something different from how I am checking auditd, but I'll put what I
have out so people can see it. Matt I'll do that tomorrow rather than
this evening.
SG: does the RBAC self test try to do anything with RBAC? do newrole or
something like that
GW: no, but it can
SG: did you come up with a list of actions for it to do to verify it is
working correctly
GW: no, it is checking status of selinux and audit now. but we can try to do
newrole and try to violate the policy
SG: I think you would want to try to do something not allowed to make sure
it is not in permissive, other than just checking the mode. Try to crash
into the wall to make sure the access mechanism is working regardless of
what the status says
GW: I can try that, anything else to try
SG: I think you would want to change role for something you can and can't
change into
GW: ok
SG: something else I was curious about. In Security Target (ST) do you talk
about "pie" randomization
KW: if selinux adds restrictions on binaries, then it should be configurable
SG: ok, just curious if you made claims about it or not. if you did, I am
thinking there might be enhancements to amtu, but if you didn't make any
claims, then don't worry about it
Cron, tmpwatch, mail, etc.
---------------------------
JA: I made some changes for cron to do the range checking and spoke with
Dan. I made the /etc/context contain security check. I think that is
roughly ready to go. I'll do some more testing and send to Dan for
approval.
GW: so that's another package we want to pick up early before it goes to
beta, so we can test on
JA: right, what I wanted to point out earlier is to not get packages from
rawhide since they are maintained by others.
MA: so there is no plan to incorporate your changes in fedora extra packages
JA: ...
SG: upstream might be thinking to do a release candidate. Maybe we should
submit that man page change to them
MA: I can submit that to them ..
SG: if you do that today or tomorrow, it will probably go in same release
MA: that reminds me I owe you a man page for cups.
GW: anything else we need to bring up?
SG: yes, Matt we were talking about changing runlevel and if that needed to
be an audit event
GW: I thought we decided it didn't need to be an audit event
MA: I think your reasoning george was that when runlevel changes, you said
audit would log a shutdown so that was sufficient.
GW: right, do you agree with that klaus? that we don't need audit msg for
run level changes
KW: it think the rationale was that users are not allowed to change run
level
GW: ok, that's a more clearer answer
KW: that's what it has been before, we never supported changing run levels
during operations
SG: ok, I just wanted to know it concluded
MA: would be nice to have init show audit record for that, but it is not
required, especially this late in evaluation
GW: I agree, it would be nice to have. Ok, anything else? thanks everyone,
let's adjourn.
Bugs / remaining tasks
----------------------
Final cutoff date
------------------
More information about the redhat-lspp
mailing list