On Thu, Jun 27, 2002 at 01:16:31PM -0700, Chris Wright wrote:
> Tonight at 8pm the LSM BoF will be in Room B. If you are OLS, please
> consider attending. Some of the topics that I'd like to cover include:
>
> 1. Quick review of the current status
> 2. Poll for projects that are present.
> 3. Look at any project specific needs.
> 4. What's left in order to submit to 2.5...
Here are the quick notes I took down during the BOF. Thanks to those who
attended.
Please forgive my inevitable typos, thinkos, blatant mispeeeelings, etc.
Brief status update:
Stable interface for six months or more, up to date on 2.4.19-rc1 and
2.5.24. Only a short TODO list at the current time, it is expected the
TODO list will grow iwth feedback.
Q: "Is october still the deadline?" A: "No, we are far ahead of that."
Greg will be working with Linus to feed pieces of the patch to Linus for
2.5.
q: "What are the pieces?" A: "We need to add opaque security blobs into
some important structures, but the structures are placed into .c files
at the moment; they need to be moved into include/linux/ so that they
will be accessible everywhere. There are several other changes like this
to the infrastructure. IPC is the major one, with several other quirky
problems where the order of logic needs to be modified. Also, the
modules need to be split."
Q: "Is there still a qwait for p[ending VFS changes?" A: "Al Viro claims
to be working on it, not likely this is his highest priority. We could
make the changes for him, but it would require making changes to
filesystems, which would be a lot of work; since it is Al's subsystem,
we need to work with him."
q: "If we are waiting on VFS, is it just the VFS piece that needs to
wait, or the whole patch?" A: "It is only the VFS pieces that need to
wait, but the other pieces are useless in comparison." "The major
rearrangements to the VFS subsystem are probably done, but we've been
trying to get him to finish it off since December; the extended
attributes people have asked him to do add the same functionality."
Q: "What modules will be distributed with the patch?" A: "Capabilities
and root-check are going to be submitted, but the other modules need to
be cleaned up before they are submitted, if the module authors are
interested in having their modules distributed with the kernel. It
should be handled much like the driver subsystems."
Q: "What is the hurry? If VFS is broken, why push?" A: "The networking
portion will be difficult to add to the kernel, especiallyu since there
should be some changes. It would be nice to have a lever such as the VFS
layer to help out."
Q: "describe netgworking problems?" A: "hooks in interrupt code,
screwing up cachelines, bitmasks; we show up on benchmarks. LSM does
_not_ incur a 20% overhead in network loads."
Q: "Aren't the hooks minimal?" A: "5% is perhaps too intensive for the
networking folks; we don't show up in the 100mbit range, but in the
gigabit range. We will make a very big dent on 10gigabits, which is
where the networking stack people really care. It is important to show
that the framework itself is as lightweight as possible, whatever the
form of the hooks."
Q: "Self modifying code?" A: "Everyone was opposed to it." "Self
modifying code might be faster, which could be used for more than access
control, it might still be useful." "Linus appears not to mind
self-modifying code, even though it is arch-specific, and performance is
arch-dependent." "If we split networking into a specific config option,
we can probably avoid the speed problem."
Poll for project presence:
Free:
SELinux
DTE
OWLSM
LIDS
DSM -- five months project -- distributed security module -- part of the
DSI project, intended for telecom servers. Have so far used a few
of the socket.c changes, changing the source and destination
hooks; Linux Journal article and OLS presentation.
TPE -- one-month ETA -- trusted path execution: trusted users, trusted
paths (Niki at IBM)
Securelevels -- three-four month ETA (Robb at IBM) -- port from the BSD
security levels; integer specifies large-grain monotonic security
features.
NonFree:
one proprietary module
Discuss project needs:
DSM considers the framework mostly well-placed, simple to use. Combining
IP Options with FreeS/Wan and LSM (with James Morris's SELinux CIPSO
work) has given some problems.
The static module structure of function pointers requires filling out
all functions; perhaps there are more dynamic methods that would be more
useful. The biggest problem to consider is having a module work with an
interface that it might not know. It is possible to export all the
symbols explicitely, but it is ugly. the current sanity checks _may_ be
architecture specific.
We haven't compared linux with the dummy module, only the capabilities
module, because the kernel is currently capabilities.
We also don't know any performance differences between, e.g., SELinux as
a module versus SELinux compiled into the kernel.
Performance is going to be a sales issue. We need to make sure that we
don't hurt performance those who don't care about security.
Chris offfers a beer to whoever can come up with a slick solution so
that module authors don't have to define functions they don't care
about.
We discourage module composition, because composing policies is
non-trivial, and can lead to difficulties. The kernel internals are so
intertwined that composing different modules are almost certainly going
to conflict on kernel internals. We have pushed the problem to the
module authors to make sure they consider all the problems. We have
considered doing an AND module to marshal the opaque security blobs, but
it would be difficult, and almost certainly easier to just inject
functionality of one module into the other module.
Q: "How does the system deal with crashes? How does this interact with
Journalling?" A: "Access control is handled above the filesystem,
journalling is handled by the filesystem; so, an action in the journal
has already been authorized by the access controls."
We may need to modify the kernel booting mechanisms so that modules load
earlier in the boot sequence. Chris wants the mechanism before initloop
device loading, such as PCI. Gregkh seemed to disagree initially, but I
sure don't understand the issues well enough to write down the
arguments. (Which is too bad, since Patrick Mochel appeared to have good
questions.)
Q: "Is there a security difference between compiled-in and modularilized
security policies?" A: "Sort of not really. once booted, things are
identical with the exception of address space performance problems.
However, between boot and module load, some amount of code runs, so
preconditions will be even more important in module than in static."
"Modules aren't much worse than other security problems; they are just
convenient."
Module authors really need to be aware that non-standard filesystems can
be unique; as an example, NFS servers are controlled through a
filesystem. Modules need to be aware of the many potential RAM-based
filesystems that can be mounted on the machine.
How should module authors detect loops in their code paths? Write SMP
code use proper locking; you'll find infinite loops in a hurry. :)
Unloading modules suffers a similar problem.
2.5 submission:
We will need to flatten the security structure; who wants grunt work?
We might want to ask Trent of IBM to re-validate the framework.
We will probably need to get the networking hooks configurable.
Chris wants to convert the VFS interface to a stackable filesystem
layout. Who knows when he will get to it. This ought to eliminate pre,
post, and mediation hooks. (Patrick jokes VVFS.) This functionality
would be useful to more people, such as server-based filesystems,
compressed filesystems, encrypted filesystems, etc. What might be lost?
How will we deal with async io? It might require a wholesale change to
the API.
--
http://sardonix.org/
This archive was generated by hypermail 2b30 : Thu Jun 27 2002 - 18:29:31 PDT