10/30/2006 lspp Meeting Minutes:
===============================
Attendees
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Joy Latten (IBM) - JL
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
James Antel (Red Hat) - JA
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Chad Hanson (TCS) - CH
Tentative Agenda:
Pre-Meeting
-----------
GW: I loaded aide on my lpar, and played with policy a bit
JA: There is an issue with aide, when you upgrade the library, then the
relink runs and updates the inodes and c-times, so I am thinking to
remove that
KW: It is not important for certification. It is appropriate to rerun to get
the new baseline if you change software
JA: I assumed the lspp are patches on top of the rhel5 install
KW: people tend to upgrade packages and do that at their own risk. But no
need to worry about this for certification
GW: so it is fine to remove those
JA: right
MA: James, you know if anyone is working on aide policy?
GW: that would be me, I was discussing it with klaus earlier
MA: I am almost done working on one
GW: making it as secadm
MA: actually using sysadm
GW: I didn't think about it much, sysadm seems appropriate. what do you want
to do about var/log, klaus was suggesting we don't need ranged
directories. How about /var/aide?
PM: how about /var/db?
KW: there should not be ranged directories writable by non admins, it is a
potential information leak.
MA: I am thinking to have /var/lib/aide at SystemHigh, and var/lib will be
SystemLow-SystemHigh, so no information leak.
KW: that will be fine
JA: that's how it works at the moment
PM: there will be other programs that are not part of the security target
that will want to write to /var/lib.
MA: aide needs to be at systemhigh
KW: can't expect any general application to work in MLS mode. we don't
guarantee that.
GW: yeah, then you'll be getting in services work
KW: in some cases it is preferable, it is supposed to break programs that
are not meant to work in MLS mode
LK: can someone summarize what just got agreed on
MA: we will have /var/lib/aide in systemhigh and we will have /var/log/aide
GW: will run by secadm instead of sysadm
MA: yes, and aide will also run at systemhigh
GW: you can pass policy by me, and I can help you with that Matt
MA: great
GW: I have version of self test working, basically took its guts out and
replaced it with aide.
Kernel update
-------------
GW: should we be running .53 kernel with 24 beta refresh
DG: yes, I am building a kernel and it should be pushed out tomorrow
KW: is that the one with 20 in file name? heads up it seems to break lvm.
GW: also newrole is its own package. you need to add that to dependency
list.
KW: need to have policycoreutils newrole dependency added. I'll update the
kickstart also
DW: policy package will be fixed. I'll put the dependency check in selinux
policy
GW: other issues with current beta refresh
KW: am I supposed to be able to unmount /var/log while audit is running or
logging? I'll keep looking into that.
MT: on ppc 32 when calling faccessat, fchmodat, futimesat syscalls, the arg0
has 32 bit negative value, but subsequent values it has 64 bit value. so
32 bit record has 64 bit values
GW: klaus came across a mis-built module, maybe that has something to do
with what you are seeing Mike.
KW: yeah, basically the pam was causing segfault in sshd, it turned out that
pam module was built against a different library than the audit. We
should figure out why did this happen, and how can we make sure it
doesn't happen again
SG: not sure the audit library is the problem
KW: When I ran it with the debugger, I got 2 different sizes for audit log
struct.
SG: ok, I think I know what you are talking about. have you seen problems
with shadow utils, or password
KW: This was the only thing I noticed. Most of the fields at the beginning
are not affected. it seems only what uses the union is affected
SG: did you close the bug?
KW: still open, it is fixed for me now, but I want to know what is happening
SG: you have bugzilla number?
KW: it is an issue tracker (104436)
SG: I'll find out what is going on with that, seems we need to build 6 or 7
packages
KW: we need to be checking this.
GW: It is not something we want to have to explain to the evaluator, that
things can break and be undetected.
SG: I'll find out what is going on, and get it to bugzilla.
KW: Another issue is how stable the binary api is for audit, this might
affect fedora, just heads up, it is not relevant for the evaluation
GW: ok, other issues with beta?
Beta / Rawhide
--------------
SELinux base update
-------------------
GW: Dan, any policy updates?
DW: big thing I'm working on is the cron fix. stephen smalley and I are
discussing how to fix it and james antel is working on the multilevel
logging capability. we are also adding policy fixes as well.
GW: sorry that discussion got pulled off the list
DW: my fault, should have noticed. Also, now that fc6 is out, we have lots
of policy fixes coming in, so I am wrapped up in that stuff
LK: So is the cron conversation back on list? I am still catching up on
email, is there a place to catch up on that
DW: main thing is that we don't want to set TE capabilities inside that
application. We want to set MLS level and check to make sure are valid
for the machine. Right now the current cron theoretically allows you to
change SELinux type and role. what I want to do is pull TE stuff out of
it and leave MLS only. stephen smalley has concerns bout trojans running
at different levels
KW: if the goal is lspp compliance, no need to have crond with full
functionality; as long as it is not insecure, it doesn't need to have
full functionality. As plan B it is ok to have restricted version, or
even turn it off completely for the evaluation.
DW: we will have it run at one level.
KW: Ok, I just wanted to clarify, so people don't think we need something
complex for evaluation.
LK: you will specify what level to use with cron?
DW: yes. Everyone make sure you get a look at policy too. we will get it to
upstream packaging
MLS policy issues
------------------
Newrole & VFS polyinstantiation
---------------------
GW: what's the status on this Mike?
MT: as it was last week, I waited to see if anyone had any input, but there
has been no activity. I'll implement the -p option anyway since people
seems to want it. I am modeling it after su, so I'll add that and send
patches out again. I don't have a time frame, but sometime this week
GW: anyone had a chance to test james antel's pam module?
JA: The actual final patches limit MLS ranges in correct way, but they only
went out 1 hour or 2 ago.
GW: should I pull that out of your people page?
JA: I posted to the mailing list three patches, one against MLS reference
policy, one against libselinux and one against pam. I'll put srpms on my
webpage late today or tomorrow.
GW: don't know if I'll have time to patch and rebuild, so maybe I'll wait
for the rpms from you.
JA: stephen need to still sign off on them. if anyone can look at patches
and see how it's been done.
GW: absolutely, I was trying to get klaus to look at them and see how they
work.
PTY leakage
------------
Audit userspace
---------------
GW: Anything on audit Steve?
SG: last week, I was able to release version 1.2.9 and it was pulled into
the beta.
GW: Ok, I'll keep this item on the agenda until we don't have discussion on
it
Print
------
MA: Once I get the patch out today, print should be all set.
CIPSO
------
GW: how is that looking
PM: there is a little bit of discussion about setsockapp. I put a patch out,
and it was pulled in very quickly.
IPsec
------
JL: I ran stress tests, and it looked ok on not labeled
GW: so MLS labels look sane
JL: yes, my next step is testing the MLs labels
SG: I sent feedback about ipsec audit for kernel this morning
JL: Oh, I didn't see it.
SG: basically, it looks good only few things that need changing. the main
thing is secid needs to be captured out of the netlink and now it seems
propagated with audit id
JL: Joshua asked about racoon patches upstream. I am working on that
GW: when do you expect them to be accepted upstream
JL: I don't know. I am trying to break them into smaller patches. I broke it
up before, but maybe that was not enough, so I am breaking it down
further.
GW: you are upstreaming patches that are already in beta ... right?
JL: yes
GW: Ok, just checking. How are things with TCS?
DG: venkat asked about one small issue, I think he sent a question to the
list. He is working on few last pieces to get the base MLs transform
stuff as opposed to the secid stuff. that's almost done
GW: when do we expect to have a kernel with all ipsec stuff in it?
DG: venkat didn't give me a time, so I am not too sure, but I can't think
there is much to do considering where he is at. I'll ask him tomorrow
morning.
Labeled networking stabilization
--------------------------------
xinetd
-------
GW: Is there still an xinetd bug, or has that been put into beta? any
updates?
SG: no, forgot about that, I'll take a look at it again.
Self tests
-----------
GW: Matt and I have been playing with aide. Matt has policy, we'll work
together to get that going. I ripped the guts out of self tests and
replaced it with aide, in addition to aide, they check if selinux is
enabeld and audit records are generated. If folks have additional
things they want added, let me know. it seems this is more of a ticky
mark for the evaluation.
SG: aide doesn't come with any cron scripts at all, so self tests can get in
and kick it off. they don't want it running with cron jobs so someone
can't get in the machine and change it. self tests can have cron job and
kick it off since aide doesn't come with any cron scripts
GW: it seems heavy weight, so you might not want to run it very often
SG: I think you want to use audit system for some of the work it is doing,
if something changed, keep track of who did it; audit system should have
that info.
GW: true, particularly if sending audit records to another machine, would be
most useful. Ok, we'll hammer out policy for that and try running test
through cron job. Not sure if anyone cares about checking things against
rpm.
SG: for aide, we'll document that you need to turn pre-link off.
GW: once you set up evaluation, you can't upgrade packages at any time
KW: or you do that at your own risk
JA: problem was when you run pre-link and even it it doesn't change binary,
the c-time of inode changes.
KW: couldn't pre-link be fixed to not do that
GW: seems like the right answer
JA: probably yes.
GW: alright, so I'll play with it some more, and we can get something useful
out of this and get it done in near term
MA: dan, you know where aide policy should live
DW: it runs as service?
MA: no, not a service.
DW: I would put it in admin for now.
Cron, tmpwatch, mail, etc.
---------------------------
Bugs / remaining tasks
----------------------
KW: there is an interface for creating users, haven't gotten feedback on
that.
DW: I put fixes for that today, should be in rawhide tonight. I have not
tested it, but I put the missing pieces back in.
KW: apparently there are 2 problems in beta, mount_t can't mount on
var_log_t. The other serious issue is that I can unmount /var/log while
programs are running on /var/log. if you tail on auditlog it says it is
busy while I am unmounting. auditd, syslogd, and cups are using that
partition, and I can still unmount it
SG: are you on polyinstantiated directory.
KW: my bad, I need to get used to that. ok that explains
GW: so you can unmount it in your namespace?
DW: so at some point var/log was unmountable and now it is?
KW: 2 issues. I added a fix to make it mounted. other issue is because it is
in different namespace, I can unmount it. It is just not expected, if
you ssh in and change to root, you can unmount.
MT: basically you are making changes that affect you only rather than the
system at whole.
KW: if you ssh in and mount a CD, it can only be visible in the current
namespace.
MT: if you log in as root, then make changes, they'll be system wide.
SG: I though there was a change added to ...
KW: if you are already in another namespace you can't do anything to affect
your parent namespace or other namespaces
GW: can we make the ssh session affect all namespaces
KW: should be easy to add .. sorry about confusing people, but didn't expect
this behavior based on namespace
DW: are there any other directories you expect by default to be able to
mount on top off
KW: I just didn't expect this
DW: there is a boolean that says you can mount over anything...
KW: I think /var/log/audit dir would also make sense
DW: we already have that
KW: and /var is also popular.
GW: any other general issues?
LG: when will you post patch for lspp for cron
DW: will post patch in another week
LMS: is this for the vixie cron package
DW: yes, it'll decide if it is legal for the user
LMS: was wondering how this mechanism will work
DW: same mechanism of how you log in and try to newrole
LMS:when you put the command in, then it'll make all the changes?
DW: It will not change the crontab, when the job actually runs, then it'll
do the check. better to check when job runs, rather than when created,
since context could have changed by then.
DW: I'll send a list of all current mount points to the list
KW: I think it is better to have the boolean be turned off and allow all
mounts, since it is not well documented
DW: so allow all mounts on anything
MA: is this on targeted or MLs
DW: they are a bit different. problem with mount, you can mount files on top
of files, so you'll end up with mount working on anything
KW: maybe you can approach this differently, when you install with
partitioning info, you expect it to be as it is without having to change
types
DW: sounds like an enhancement
GW: I think it is a bug
KW: I think when you mount, you would expect it to be correct and be able to
mount, so I would think it is a bug.
DW: I can file it against anaconda, but I think they'll send it back to me.
GW: any other issues to bring forward?
KW: Well, in kickstart script, is there a way to tell it to not ask question
about install keys.
MA: I don't think we are install script experts. speaking of keys, do you
think the import done by rpms should be auditable
GW: not as part of the evaluated certification
KW: but in evaluation you are not running rpm. I don't think this is an
issues. Beyond the scope of lspp, you shouldn't be installing packages
even from the RedHat site
SG: I just wanted to check if rpm importing keys was ok,
MA: if rpm is importing keys automatically, then you should file a bug about
that probably.
GW: I agree with Matt, it usually asks me about the keys.
KW: I think there is some config option in the repos.conf file
GW: ok, anything else? alright we'll adjourn. thank you all
Final cutoff date
------------------
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
