Re: [RFC] [Stacking v4 3/3] Cleaned up stacker patch

From: Serge Hallyn (serue@private)
Date: Mon Dec 06 2004 - 15:01:59 PST

On Mon, 2004-12-06 at 11:44 -0500, Stephen Smalley wrote:
> - When would we not want stacker to short circuit processing upon
> encountering an error from any security module for hooks that return
> error codes?  The rationale in the comments is that some modules may
> change state when called, but the question is whether any such state
> update should occur when the operation is going to fail anyway.  In the

True.  If noone has an example of a pair of modules which would actually
want to use the shortcircuit_restrictive=0 option (I don't) I will get
rid of that code.

> - The last point highlights another issue if we were to try to stack
> capabilities and SELinux via stacker rather than via SELinux
> secondary_ops: we presently apply different orderings for capget and
> capset_set than for other hooks.  Possibly reflects a more basic problem
> in the capset code and hooks; capset_check is supposed to handle
> security checking while capset_set is supposed to just update state, but
> we often don't have the specific target task in capset_check, so
> capset_set has to apply a check too for completeness.  Also, looking at
> the core kernel, it looks like capset_check isn't serving a useful
> purpose anymore, as the core kernel is applying the same checks
> directly.  capget may not be a real issue, as it is only getting the
> bits into a kernel data structure and will not copy to userspace if we
> returned an error.  Possibly need two separate hooks at the same points
> where capset_set is presently being invoked to cleanly separate
> permission checking hooks from state update.

I need to investigate this further...

> - It seems like the alloc_security hooks are a problem for stacker,
> because you could have one or more modules succeed in allocating the
> security state before one fails, and the core kernel doesn't call the
> free_security hook upon an error from the alloc_security hook, as it
> reasonably assumes cleanup of any partially allocated state prior to the
> hook returning.  Either the stacker needs to internally call the
> free_security() hooks for all modules that returned success from
> alloc_security() to cleanup, or the core kernel needs to be changed to
> always call free_security() after any call to alloc_security(), even if
> it failed.

A very good point.  I will put this in stacker for now.  I can't think
of any reason why this would be useful to any case which was not using
stacker, and calling free_security() after a failed alloc_security()
could cause existing LSMs to Oops...  Does anyone think the alternative
would be better?

Serge Hallyn <serue@private>

This archive was generated by hypermail 2.1.3 : Mon Dec 06 2004 - 13:49:43 PST