Quoting Stephen Smalley (sds@private): > On Mon, 2005-07-11 at 09:49 -0400, George Beshers wrote: > > 1) Is stacker intended mostly for experimental systems or for > > production systems also? I have the impression that there are > > concerns in this area. > > I'd say that submission for inclusion in the mainline kernel implies > intent (by the author of stacker) for production use. Whether or not > stacking of LSMs is truly appropriate for production systems has been > debated previously. Yes, the hope would be that stacker would be suitable for production use. > > 2) Because Auditing is an integral part of my LSM it is important > > that the methods be called even if another module is going to As Stephen points out, you can't very well use an LSM for generalized audit as even denied DAC checks will cause false negatives. Could you tell us a bit more about what you're trying to do? Depending on the details, you might be best off bulding on the audit subsystem itself. > > deny permission --- this is not the semantics of > > RETURN_ERROR_IF_ANY_ERROR. It appears that SELinux also > > might have a similar concern. > > > > Come to think of it, an LSM might want to modify its data > > structures also. > > I think stacker has been intentionally constrained in order to reduce > concerns about generic stacking/composition. Note also that the issue > you raise isn't truly new to stacker - LSM itself is constrained in this > manner, as the LSM hooks are not even reached in most cases if there is > a DAC denial (or other kinds of basic checking applied prior to the LSM > hook call). SELinux only audits its own permission checks, and will > generally be the first module (other than stacker, if using stacker) due > to its requirement for early initialization. Earlier versions of stacker allowed the shortcutting of hooks to be optional. It was generally agreed that this is undesirable and dangerous. If possible, you can, as Crispin points out, load your LSM first, so that the others can't shortcircuit it. Or, you can use a customized stacker, based on the current stacker module, to better suit your situation. We can't safely overgeneralize module stacking. Even with this very simple stacking behavior, there are many issues to be considered in module interaction, and generalizing stacker behavior would only make it worse. However, if you give us some details about what you want to do, it may be possible to facilitate it one way or the other. > > > 4) What are the circumstances where an LSM would need to > > modify something other than its own data structures? > > In other words, what is the argument for not insisting > > that security methods are side-effect free except for there > > own data structures? > > You'd at least need an exception for capability, unless you undertake > the work to migrate the capability bitmaps into the security blobs (and > decompose apply_creds cleanly in a safe manner). > > SELinux can also have side effects on data structures other than its own > e.g. flushing/resetting various elements of process state upon a > security context transition to prevent unauthorized leakage and to help > protect the new security context from subversion by the caller. It may be worth specifying in the stacking FAQ: 1. that security methods are side-effect free 2. with the following exceptions: ... However this would be hard to keep up to date. Providing documentation which is likely to quickly be wrong may be worse than providing no documentation. thanks, -serge
This archive was generated by hypermail 2.1.3 : Mon Jul 11 2005 - 10:40:09 PDT