From:	 Emily Ratliff <ratliff@austin.ibm.com>
To:	 <linux-security-module@wirex.com>
Subject: Kernel Security Extensions USENIX BOF Summary
Date:	 Mon, 2 Jul 2001 12:18:10 -0500 (CDT)

Hi,

For those of you who could not make the Kernel Security Extensions BOF at
USENIX last week, here are a few notes and comments. Those of you who did
attend please weigh in with your corrections and additions.

The BOF started off with Robert Watson talking about his TrustedBSD
project. Amon Ott spoke about RSBAC. Peter Loscocco spoke about SELinux
and Crispin Cowen spoke about the LSM project. (Interesting sidenote:
Crispin said that there are now 470 addresses subscribed to the LSM
mailing list.) Each talk was fairly short. When the talks were completed,
the floor was opened to questions and comments about the LSM project.
Peter Loscocco spoke about what happened at the Kernel Summit in March to
get the project started.

The primary issues discussed included
- Steve Kramer of HP expressed a strong need for a dummy
module that exercises each hook to use in regression testing each new
kernel. About half the audience seemed to agree, with the other half
saying that the hooks that were interesting for active security modules
would thrive and be tested against each new kernel version by default and
that it would be ok if the other hooks died out.
- Peter Loscocco expressed that it is important that the LSM project be
able to communicate an architecture for the hooks to be accepted by the
kernel developers. There was no further discussion of this point.
- The question of allowing permissive as well as restrictive hooks was
discussed. The general consensus was that it would be best to allow
restrictive hooks only at this point. The goal is to get the basic hooks
into the kernel and expand into permissive hooks if they are deemed
necessary and prudent at some later date.
- The question of whether capabilities should be a module came up but
was not really discussed.
- Stephen Smalley brought up the issue of duplication of some of the
hooks. For instance, some code paths call two separate LSM hooks. One
example of this is the hook at attach_pathlabel and at the inode level.
Stephen felt that this would be frowned on by the kernel developers. One
member of the audience (didn't catch his name) felt that the LSM project
should argue that this duplication was inevitable and that rather than
calling it a "duplication" which has negative connotations, it should be
called an "overlapping" of functionality. Douglas Kilpatrick who does the
wrappers project for NAI said that they use pathnames for convenience but
he feels that making security decisions at the inode level is the correct
thing to do. Stephen Smalley is ok with that as SELinux makes decisions
at the inode level, but other project like SubDomain and LOMAC make
security decisions based on the pathname. Someone said that eliminating
the duplication of these hooks would impose limitations on the policies
which could be LSM modules which is clearly not what LSM wants to do. The
discussion was tabled with no decision made.
- Crispin Cowan said that the LSM project is near snapshot level ready to
be sent to Linus when development on the 2.5 kernel is opened. There was
only lukewarm support for this. Many people seemed to feel that some of
the other issues should be worked out first.
- Stephen Smalley brought up the issue that the LSM patch hasn't had
sufficient testing or documentation to know what locks are held when the
hooks are called and what locks should and should not be acquired in the
hook code. The LSM patch hasn't been sufficiently tested on SMP machines.
More performance testing also needs to be done at both the macro and micro
test level.

Finally it was agreed that there would be a LSM specific BOF at the USENIX
Security conference in Washington DC in August. Timothy Fraser of NAI Labs
is setting up that BOF as well.

Please let me know about any misrepresentations, errors or ommissions.

Emily

Emily Ratliff
IBM, Linux Technology Center



_______________________________________________
linux-security-module mailing list
linux-security-module@wirex.com
http://mail.wirex.com/mailman/listinfo/linux-security-module