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? thanks, -serge -- Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Mon Dec 06 2004 - 13:49:43 PST