[redhat-lspp] LSPP Development Telecon 05/08/2006 Minutes
Loulwa Salem
loulwas at us.ibm.com
Tue May 9 00:19:44 UTC 2006
5/08/2006 lspp Meeting Minutes:
===============================
Known Attendees:
Matt Anderson (HP) - MA
Amy Griffis (HP) - AG
Steve Grubb (Red Hat) - SG
Chad Hanson (TCS) - CH
Linda Knippers (HP) - LK
Joy Latten (IBM) - JL
Paul Moore (HP) - PM
Loulwa Salem (IBM) - LS
Al Viro (Red Hat) - AV
Dan Walsh (Red Hat) - DW
George Wilson (IBM) - GW
Janak Desai (IBM) - JD
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Valdis Kletnieks(VT) - VAL
Venkat Yekkirala (TCS) - VY
Michael Thompson (IBM) - MT
Kernel update
-------------
LSPP kernel issues
------------------
AV: An unrelated bug in Fedora kernel created problem, but it got sorted out
yesterday, it was a small problem. As far as mainline is concerned, we
are much closer to 2.6.18 so everything els has to wait for 2.6.18.
There is 1 patch that fixes deadlock that will go to Linus tomorrow. As
far as mainline is concerned, we are doing pretty well. There is also a
new lspp.b12 that will keep growing and a new lspp kernel out.
SG: the lspp.23 kernel has everything in it.
AV: You probably need to move to Fedora kernel. if you look at this thing
with the uninitialized spinlocks.
SG: T tested this morning with 2196 kernel. I worked with David Woodhouse to
resolve the issue.
GW: I loaded the .23 kernel Steve, and it behaved like .22 kernel. I need
audit-1.2.2 to clear the ENOBUF issue.
SG: I am working on ppid issue, and will release a new version.
GW: Good. I saw no regression in this kernel, hopefully it will be better
performance wise. thanks Al for the help. We are doing better.
Audit performance and stability issues
--------------------------------------
GW: Amy, how is auditfs and inotify doing.
AG: I just walked in the room and heard my name, can you repeat your
question.
GW: I wanted to know how the inotify work is going.
AG: Last week I finished patch to add audit rule. I am finishing up inotify
tests today. I sound out that I'm missing some events, at this point it
might be bug in my test program and not in inotify; I need to test and
see. Later on this week,I'll work on filesystem auditing patch where
files/directory removes aren't being auditd. This work is for this week
AV: if u need help.. just let me know.
GW: We have new kernel out, and we need to do some regression testing. Are
we ready for another performance run.
SG: yes, I'd so wait for .24 kernel though.
GW: This gets us back on track in terms of stability. I updated my discount
patch, I moved some hooks a bit to capture parameters. I'll put it out
since the more I keep looking at it, I'll keep finding problems. Also I
put a user space patch for it; the functionality should be there.
AuditFS/inotify completion
---------------------------
Audit of POSIX message queues
------------------------------
Audit API
---------
GW: Steve, any updates on audit user space
SG: I am working on ppid . Use auditctl to audit on ppid. It will be in next
release.
Audit failure action inquiry function
--------------------------------------
GW: Any updates on that? I know lisa is out.
LK: Lisa is out, but we talked about it before she left. You'll see
something on the mailing list tomorrow probably.
Audit of service discontinuity
------------------------------
GW: This item has no owner still.
Maintenance mode for secure recovery
------------------------------------
GW: Any one worked on that. Is this item still unowned. Steve still had a
question about if we still need to audit on startup.
SG: Al and I exchanged emails about that.
AV: we can get auditd to start early. it'll stir all messages in kernel,
then put them to auditd later. the point is we can get some formal
auditd running as soon as we get in initrd, that is as early as we get
any logging, as soon we get in initrd.
KW: I think this is more than enough and what's needed for evaluation. What
evaluation cares about is having functioning audit system running before
some processes like ssh and login are run.
AV: auditd will be the second user-land process being run. How to do it? We
can start auditd, kernel knows what process id it's starting. what we
can do is we can tell already running auditd to have its parent run exec
on new binary and then have child which still keeps original binary.
Same trick is done to init, it's a fairly old story. We used to have
rather ugly process for updating sbin/init. We can't queue pruning init,
if you want to change binary, we could do it in place. it requires
reboot, and it gave us a dirty filesystem. Back in '98, that's when init
had been taught to do the following: transfer all its state to its new
binary so you do upgrade in place. init needs more states than we need
for auditd. We should go grep for that code and see how it is done
easily. I think that's doable. I don't see any non trivial issues with
it. Again we can get minimal auditd into initrd, we can get it running
as early as any user land process can run, we can have what it receives
from kernel do a new one.
SG: klaus, you think we don't need this much in depth? or only when it goes
under user control.
KW: It's sufficient. If things run in non privileged user behalf you need
audit to run before those processes.
AV: There is one addition we want for real world use. We want to upgrade
auditd without bringing the system down.
KW: That would be a nice to have feature. if it is necessary we can put the
system in single user mode.
SG: In single user mode do we need to register user action? here auditd
turns off.
KW: We need to get messages of who initiated to a single user mode, after
that it's ok not to audit.
SG: so we just need the message initially.
KW: if an admin initiated switch to single user mode then we need a record.
If the system decides to switch to single user mode due to failure for
example then we need some event to show up in the log.
GW: So we need run level messages. Is it sufficient to know what happened or
do we need explicit messages?
KW: It will be nice to have explicit messages. Is there anther mechanism to
write messages.
AV: We used to have other ways, but not anymore. We can put a watch on
auditctl, and we look for attempts to open it.
VAL: Do you have any need to audit the case when someone hits reset and
reboots in single user mode?
KW: We require that physical access is restricted to trusted admins.
VAL: I'm thinking a TPM hook to get a log of what happened
KW: It is nice to have, but not required for the evaluation.
AV: We are considering having physical access to reset is having physical
access to the disk as well.
VAL: We always end up with systems where physical security ends up to be an
issue.
KW: We try to enforce security through software not hardware.
VAL: in that case, i can live with that.
KW: Put a requirement that the office should be locked.
VAL: try telling that to a university VP? :)
KW: One additional comment on upgrading auditd, we have 2 options, they can
have system availability but loose audit records, or switch to single
user mode, but not both
AV: Bottom line is, this switch from initial to normal user, it's doable but
not high priority.
GW: what about run level messages? when you switch run levels, auditd is
killed.
SG: auditd will get messages that it is terminating.
KW: we can put watches on init, but in this case it would be easier to
modify init to send messages directly to auditd.
AV: we can have init generate messages. duplicate its login
KW: I meant send user messages when run level changes.
AV: wouldn't be useful. It is getting asked by a user to do it, but all
action and login are done by same process with same credential, no way
to tell who asked it.
KW: unless we pass it the id, it will be lost.
AL: probably what we can do; on the other hand we use something like selinux
to restrict access to main pipe, to tell init, which is how we should do
it.
KW: sounds reasonable. Make access to main pipe restricted to admins.
AV: they are already told that in every text book anyway
KW: selinux might also be nice to get assurance that people stick to the
rules. I like the idea to put audit hook in tel-init.
Print
-----
GW: Matt, would you like to tell us how print is going?
MA: I've been messing with using various filters, found way to enforce
postscript files without going to a second cups server. It reduces
complexity and shows we used the trusted path. In that process, I
thought of using pdf as container rather than bitmap file. In bitmap
the text is illegible, but in pdf it remains legible. I need to work on
the bitmap portion of the filter. The problem I'm getting is in multiple
pages we don't get image files.
KW: I am not sure if going in this direction is helpful. Initially we wanted
to use bitmap to have a simple interface between trusted and untrusted
parts of the print queue.
MA: If original input is postscript, the input gets rendered to bitmap
image. and is completely generated by filter without user input. that
will go through to another filter that will put label of original file
overlayed on that postscript file
KW: the postscript file might be from untrusted source. postscript file can
redefine operators.
MA: original input file has already been converted to .tiff or ppm.
KW: but I though it is still running in user context.
MA: no it's running is server context. filters are always running in server
context.
KW: split the context operation, and treat it as untrusted. You want to
avoid postscript interpreters to be trusted. if you get complex
intermediate formats, you may run into trust issues.
MA: we are not using user files, it is already been converted.
AL: what context is it running in
MA: server context
KW: too late, you already trusted it.
MA: labeling operation already handles it separately. labels are applied to
file containing bitmap. The difficulty is how you do different bitmaps
in separate pages. you need containers for that.
AV: bitmap is not a big deal, the problem is the postscript. it's not the
same as running shell script from trusted.
MA: I am running in sandbox, taking output and running it as an image.
KW: output of sandbox needs to be simple. you get assurance if u assume
sandbox is doing the right thing, and if it is, then you don't need the
sandbox then anyway.
MA: postscript output is a small part of previous image file
AL: you can verify that?
LK: don't you need interpreters to make sure you get right output
AV: completely suspended sequences.
MA: postscript containers holds individual bitmaps. we need to have mini
parser to validate input
KW: how about put them in tar file, if you need single file
MA: you can't lpr a tar file
LK: are we sure there is no way to fix image problems
MA: that's where pdf comes in. we don't need to worry about multiple
containers. pdf can use many pages.
KW: pdf is not a full programming language, it does what you want, but it is
complex. Yo use it you need a LLD for the pdf parsing engine. I think
that's probably happening is that you have bitmaps at wrong resolution.
might need to change it.
MA: been using 600 dpi I think .. I'll try changing resolution and see
KW: you should be able to get something readable at 600 dpi, maybe not
beautiful
MA: maybe it is my resolution
KW: 600 is good, if not, there might be other problems
MA: I also tried multiple image types to see it.
KW: if just the bitmap printouts are not readable, it's fixable problem. if
characters are readable but fuzzy in magnifying glass for example that's
another issue, but if not readable at all, then there is a bug
MA: I put a sample a while back
LK: I saw that sample, it is not readable, we have to check
KW: it should not look like a fax hopefully, but at least not worse
MA: I don't want it to look like a fax. but faxes are more readable now that
what it is currently
KW: if you need hight quality option, I know ghost scrip has a flag to get
output in high resolution, see if you need something similar.
CIPSO
-----
PM: I posted to list last week. Stephen made comments about how do we resolve
different access control messes. I posted on friday, and it was largly
ignored.
JL: i'll review it. i talked to Trent Yager and alerted him too
PM: i'm talking about the posting to selinux list, not lspp list. James
Morris said there is another group that can use the patch, I posted to
thier LSM list. Apparently it was good timing, since they didn't port
their CIPSO stuff yet, so they were happy to see some work is being
done. There is plenty of work to do. Starting tomorrow I'll start
implementing changes they suggested on list.
SELinux base update
-------------------
GW: Dan, anything for selinux?
DW: we have a library update. we are submitting upstream. dev-audit is
awaiting approval into fedora extras. Klaus, you had questions on how to
set up roles and users. I have a blog that is half way done about that.
Also, I want to move audit.conf and audit.rules into another directory
to make it easier to control policy. As soon as libraries get updated,
there will be a major update to selinux.
CH: did you run into problems with changing context.
DW: I also put a cookbook on how to do that. need to be staff_t rather than
user_t.
GW: thanks for update Dan. Any other other issues with the roles Mike.
MT: what are roles supposed to do in the separation of roles. Notheing is
concrete to test, which is mainly why I'm asking. I can't test if I
don't know what to test. there are three roles secadmin, sysadm, and
auditadm. auditadm role is clear, but it should be better documented. as
for sysadm, it was cleared a bit but there is an overlap with secadm. So
the question is: what is expected of auditadm, and how do secadm and
sysadm differ?
DW: auditadm manages audit system, runs auditctl, and manages /ets/audit
files, start and stop audit service. secadm, is the manager of selinux
stuff, manage policy, use semanage, turn off and on enforcing. Now
sysadm does everything the first two don't do
MT: Ok ... so auditadm controls anything audit related. what does sysadm do
that falls in secadmin domain?
DW: stop and start audit
MT: should sysadm modify those roles. << not sure if this was sys or sec
admin>>
DW: I'd say no. if u have different file context or sensitivity level, it
become difficult to manage it. directory is easier.
MT: should sysadmin be able to do auditctl -l, or not? He can't modify
config, but can he get rules information
DW: I would say no
KW: It's up to the implementation to decide. only thing required, is that it
is not allowed to change the configuration.
DW: I was playing with it in the afternoon. I believe sys and sec admin
should not be allowed to run auditctl.
KW: It is reasonable to not let them run it.
DW: sec and sys admin are running in system low, and audit is running in
system hight. MLS will restrain them.
MT: what about for audit log?
DW: leave to secadmin
MT: great .. now i can write and run test
GW: we need to document that clear distinction and put on the Fedora wiki.
MT: I can write that up. I also wrote a page on how to add users, but I
don't have access to wiki, do I need to request access.
SG: You need an account, and to accept the terms of use ..
DW: You need specific access to the selinux pages
GW: Is that why it says immutable page.
DW: You need special access.
GW: It is not very intuitive as the old wiki
DW: Carston Wade is one to contact about this. If you can't get it on there
Mike, send it to me and I will.
MLS policy issues
-----------------
GW: Are there any other policy issues. Klaus are you happy with the
definition of roles.
KW: I think we can simplify by having 2 roles, no sec admin, but it is also
up to the implementation. The requirement is to split the audit and
other system tasks. Actually lspp doesn't even mention roles, and RBAC
is easy on that.
GW: Steven Smoogen has said that they have other roles, but customer can
define that.
DW: if we want to get rid of secadm, we can get rid of it, I don't mind
KW: Ok ... anyone wants secadm?
GW: let's put this on the list to get some feedback
SG: someone wanted auditadm instead of secadm, so now we ended up with
three.
CH: there is a difference. We do that sometimes to keep security people
happy and show potential role breakout.
DW: audit, sec, user, staff, and sys admin role. user and staff are default
login roles.
GW: are we happy with those as default.
DW: I am always confused with those, end up with 3 windows
GW: what are the expectation from a customer set point of view
DW: need to put on list. people using MLS will have a more valued opinion.
IPsec labeling, xinetd, secpeer
-------------------------------
GW: James Morris created patch that embodied the dicussion at seLinux
summit. how is that going to interact with existing ipsec labeling and
Pauls CIPSO patch. Joy?
JL: I'll review both patches. James also sent his patches.
PM: I looked at his patch. looks like he got rid of the port and node cache.
JL: I did not look at code yet. Are you saying we don't need those hooks
anymore.
PM: they are still there for compatibility mode, but might not need them for
long.
JL: we don't need that look up anymore? I havn't looked at CIPSO patch yet.
Steven smalley had some concerns about it, but I'll look at it
ipsec-tools patches: Base, SPD dump, and racoon MLS
-----------------------------------------------------
VK: no progress
JL: You made progress on the mls portion?
GW: no ... he already just talked about that.
GW: any word on your work Joy?
JL: We should see stuff on xinetd patch. I did some test, and Trent is
pretty happy with it.
GW: we'll write him if we don't see it on list.
JL: I'll write him on Wednesday if there is no listing yet. Also, good news
IPSEC manual portion is finally accepted, after about 6 months
Device allocation
------------------
GW: Dan talked about those earlier..it seems like a done deal.
Label translation daemon
-------------------------
Self tests
----------
GW: I need to produce new iterations of those
VFS polyinstantiation
---------------------
JD: namespace module is in rawhide. there are bugzillas, one i fixed and
have a patch, mainly moving instant initiation from polyistantiated
directory to another secure directory. Russel had some suggestions also,
which we are going back and forth on mailing list about, he wanted to
add another intermediate directory, but I am not sure about it, but we
are discussing the issue.
Cron, tmpwatch, mail, etc.
--------------------------
JD: As far as cron havn't heard about that.
SG: Jason said he put it in, he wants to release it with the new version of
cron.
JD: For the shared tree work, Adriane is trying to get input but not getting
much response. Do anyone know how to get a response. This is usefull for
pam name space so admins can get information. Is there a Fedora util
maintainer that can ping Adrian? that would be useful.
SG: has the patch been posted?
JD: I think he posted it, but I'll double check
SG: we can carry it in util-linux to start testing.
GW: still need to determine what mail wrapper to use for cron. I beleive
Dustin was working on that, but he didn't finish.
Closing
-------
GW: Ok.. this time I'll focus on the positives ... We are better than 90%
complete andbetter than 80% upstream. We are doing well, and we need to
continue testing and submitting upstream and stop development. As Steve
had said last week, we need to make sure our code is submitted as the
window opens for the .18 kernel.
More information about the redhat-lspp
mailing list