[redhat-lspp] LSPP Development Telecon 01/23/2006 Minutes
Debora Velarde
dvelarde at us.ibm.com
Thu Jan 26 19:41:40 UTC 2006
-----------------------
LSPP Meeting 01/23/2006
-----------------------
Known Attendees:
Matt Anderson (HP)
Janak Desai (IBM) - jd
Steve Grubb (Red Hat) - sg
Chad Hanson (TCS)
Dustin Kirkland (IBM) - dk
Linda Knippers (HP)
Joy Latten (IBM)
Paul Moore (HP)
Emily Ratliff (IBM)
Stephen Smalley (NSA) - ss
Mike Thompson (IBM)
Debora Velarde (IBM)
Al Viro (Red Hat) - av
Klaus Weidner (atsec) - kw
George Wilson (IBM) - gw
Kris Wilson (IBM)
Venkat Yekkirala (TCS)
Catherine Zhang (IBM) - cz
Tentative Agenda:
IPsec labeling, getockopt(), xinetd
ipsec-tools
VFS polyinstantiation
AuditFS completion
Audit enhancements
Audit by role
Audit of network events
Audit API and binary records
Print
SELinux base update
MLS policy gaps
Device allocation, udev, DBUS
Self tests
Cron, mail, etc.
Remaining tasks
Package list
Unit and functional tests
Documentation
-----------
ipsec-tools
-----------
Joy forward ported but has not tested it yet due to OF oops
test 2 rawhide, 2.6.16 kernel
stopping her from testing her stuff and nethooks stuff
George also got oops on 64way when trying to do performance test
kw: preferred way to report bugs? redhat bugzilla or mailing list?
sg: kernel.org kernel needs to go to linux kernel mailing list
sg: rawhide kernel should go to rawhide
-----------------------------------
IPsec labeling, getockopt(), xinetd
-----------------------------------
kernel crash due to ipsec patches
- sg doing tests on friday, disabled selinux caused networking errors
- sio error msg, not selinux denial msgs
cz: if kernel and patches are not the same version sometimes get crashes
sg: kernel used was rawhide, pretty close to what's upstream
Trent's patches already included in rawhide kernel
appears to be due to additional patch, labels
sg: Have you tested it with selinux disabled?
cz: No, will do that
getsockopt update
cz: not much work this (has paper deadline)
cz had problem with the mailer, trying mutt mailer,
sent out to a few to see if people received fine
gw received it and it looked fine
cz to send to the mailing list
xinetd
cz: need to pull that patch in and do testing on it
---------------------
VFS polyinstantiation
---------------------
unshare is in -mm tree
last week Andrew Morton asked:
1. for automated test for system call
Janak working on test; should be ready by end of day
2. If code has been reviewed enough?
av: only #1 is an issue now
problem found by sg while testing userspace module, couldn't delete a dir
narrowed down, not coming from unshare
av: will look into that tonight
pam modules - sg has been testing, augmenting, fixing problems
pam namespace - trust putting it on a machine
sg: real close
gw: is unshare avail on all arch's?
ppc, x86_64 (janak testing), i386 (janak testing)
IBM should try it on ppc
------------------
AuditFS completion
------------------
Amy not here, Linda has status
Tim had comments on it last week
Amy's patch out last week
updated patch on the 19th
updated patch for the 3rd chunk of work
1st draft of the inotify client
hoping to get some feedback on that
Amy out of the office until wed, and moving offices that day
Amy will send an update at end of week
Are changes to Amy's patches gated on decision or gated on doing the work?
- Dustin currently using hers as if its untouched
- up to Amy if she wants to change her code
another comment from serge:
- statically sized arrays, 54 elements,
- already making new struct arbitrary,
- usually only 1/54 filled w/ data
- could be a lot more efficient w/ that
------------------
Audit enhancements
------------------
-------------
Audit by role
-------------
arbitrary string coming in and out of the kernel
using audit_rule_data struct
Feedback given to Amy suggested fields be dynamically allocated.
If Amy does change that then Dustin's audit by role will need change too
dk working on filter to path now
will work on filter on syscall later
should finish next day or two
once that's done, will be out on the mailing list
gw: would be interesting to do perf runs
dk: patch out within next couple of days, certainly by the end of the week
2 dependencies before Dustin's patch gets upstream:
1. work Amy's put forth, audit_rule_struct
2. Tim's user data patch
Getting patches upstream:
David has been taking care of that
Al Viro taking over role from David
TODO: gw to add Al Viro to meeting list, but don't remove David yet
Will we still have git tree?
sg going to check on getting an updated kernel
new place to save the test kernels
maybe in sg's people's page?
hopefully later this week
-----------------------
Audit of network events
-----------------------
last week, decided need to do a bit of testing to see what coverage is
to ensure getting sufficient info from network events
get label off of inbound connections and record that?
maybe goes along with xinitd, userspace audit records?
----------------------------
Audit API and binary records
----------------------------
sg will schedule a meeting to include all interested parties
-----
Print
-----
update from Matt
- audit patch in a way works that with 1.2 and older one
- 1.2 won't be ready in time for RHEL5
- breaking up MLS patch
- some for doing page resizing
- selinux type, storing in spool dir, still needed untrusted one to save
types
- getting proof of concept further along
- send audit patch out end of this week
- other not ready for a while,
part of a bigger glue that will hold 2 pieces together
cut off date?
- fedora core 5
feb 6th - test 3 freeze
need everything a couple days before that
-------------------
SELinux base update
-------------------
Dan not on the phone
ss: James Morris did an updated MCS document
maybe can mutate that for MLS documentation
chad: ??con interface yet?
ss: no, if its a priority to you, let people on the list, ss, and Dan know
---------------
MLS policy gaps
---------------
mls policy rpm
when we see deficiencies, need to update and post on the list
high and low at the same time
another problem: getting created w/ wrong label
-----------------------------
Device allocation, udev, DBUS
-----------------------------
debbie volunteered to look at what happens when you disable dbus, hotplug,
udev
udev, already not starting on gw's pseries lpars
all device nodes getting created, and not
dbus, in some testing, prior level
dbus drops the audit capability when switches from root to user
if it does should go to bugzilla
----------
Self tests
----------
DISCUSSION
gw: want reading from klaus
gw's read:
- need something minimal to meet RBAC, PP
- might want to go a little beyond that for people expecting to verify
policy
- policy is being composed from modules,
a little more interesting to verify the policy is the policy you really
want
make sure the policy you build is what you expect when you load it
How far do we need to go? opinions?
- Do we need Tripwire?
- policy verification?
- like what ss posted on the list?
kw: start w/ something minimal
- trusted solaris - argued away need for something like this
- make sure things that are supposed to be denied by the policy are denied
DAC would allow but RBAC would deny
- check if you're in that mode,
that some very basic security functions are working
Easier to do w/ rpm checking or tripwire?
- rpm not a good choice for checking config files
gw: verifying the policy?
kw: same kind of thing, when loading the policy and error occurs
make sure you're not able to access the audit record unless you're in
the right role
gw to ss: how much work beyond this should we do?
ss: which parts do you want to verify?
if you don't do all of them then not really buying us anything
- Would be nice to know the admin is running what he knows
chad: change a boolean to updated the checksum, otherwise when you do a
check its going to be inconsistent
sounds like we should do more
given date, diminishing # of people working on this
probably just going to meet RBAC, doesn't really give us any measurable
rpm db - portion of the db that are included in verification
when do i update this?
if every time then the same thing that corrupts the policy might affect
the checksum
things to think about before diving into
ss: may not be necessary
gw: rpm verify, at policy load time (maybe not even at load time)
as ss said if not going to build the whole chain then not really adding
to it, so could just add the letter of the law
ss: people investigating #5 other space, integrity verification
simple mechanism for verifying the policy
- tripwire? needed for what?
- rpm verify
- tripwire for the config files? example: audit-rules
- test the desired behavior of
- lighter weight utility or modify tripwire?
- kw: testcases needed for eval already, just reuse a subset of these to
verify this
How to go about defining that set?
- policy isn't completely broke and that its doing its job
- fundamental features
Kicked off in a cron job periodically?
- Do it at start up and admin has the opportunity to run when he wants
admin should get
- kw: automatically at start up doesn't mean periodically, he'll check
- RBAC: periodically
Resurrect tripwire? or write our own?
- simple to recreate something tripwire light
- going through all the files
- utility to snapshot the md5sum DB or flat file
- more baggage than you want to resurrect tripwire
- shell script or something that verifies the binaries and the config
files a different way
- augmenting of sestatus - selinux health check
- what it got when it just ran
- could script something together rather simply
CONSENSUS - direction moving forward
- given date, diminishing # of people working on this
probably just going to meet RBAC
- start w/ something minimal
- make sure things that are supposed to be denied by the policy are denied
(DAC would allow but RBAC would deny)
- make sure you're not able to access the audit record unless you're in
the right role
- reuse a subset of testcases needed for evaluation to verify fundamental
security features
- will NOT use Tripwire
- need to create utility (could be shell script) that verifies the
binaries and the config files
- utility to snapshot the md5sum DB or flat file
- to be kicked off at start up and periodically by the admin
such as in a cron job
- could use rpm verify
- augmenting of sestatus - selinux health check
----------------
Cron, mail, etc.
----------------
jd: no new news other than incorporating Steven's comments
should be on the list soon w/ latest changes
---------------
Remaining tasks
---------------
gw went through tasks lists and will publish that to sg, Linda, and Ken
Hake
task list - remaining items:
- debbie on dbus
- multilevel sshd, multilevel xinitd might alleviate
- at and tempwatch on hold for Janak's completion of cron
- documentation and test in general until we get development pieces
- James' MCS guide update
- non-upstream kernel features - gap in getting updates
need to augment test 2 system
install mls system that will look like lspp system
- restricting access to kernel key ring
part of MLS policy
haven't done any explicitly work
- audit of selinux booleans - done, upstream
- audit records patch for userspace records rejected - Tim working on that
- configurability
panic or fail to single user mode
variable in selinux config
we haven't done anything yet
- util to compute closure,
steve had customer who wants that
want to be able to tell, any given file who has access to that
want to be able to point it to a file
tresys has a tool, apol
need to add DAC permission check
sg: need to see how it works
not a command line tool?
have a couple of command line tools, but don't know that it uses those
libraries do all the real work
sesearch tool, put types in and it will search the rule
- packet analyzers - handle labels
not a nice to have, need to understand
display labels and match against them
not strict lspp requirement but sounds like something that would be
really useful
------------
Package list
------------
-------------------------
Unit and functional tests
-------------------------
IBM and HP interested in tests you're willing to opensource
- certification work and functional tests
- go into LTP
-------------
Documentation
-------------
ss: James Morris did an updated MCS document
maybe can mutate that for MLS documentation
issues?
none
lspp wiki: http://cable.coker.com.au:800/wiki/index.php/Main_Page
More information about the redhat-lspp
mailing list