On Mon, Sep 17, 2018 at 10:13 AM, Casey Schaufler
[off-list ref] wrote:

TOMOYO uses the cred blob pointer. When the blob is shared TOMOYO
has to be allocated a pointer size chunk to store the pointer in.
Smack has the same behavior on file blobs.

Oh dang, yes, I got confused over secid and other "extreme" shared things.

So one change of my series would be to declare tomoyo as "exclusive" too.

Today the distinction is based on how the module registers hooks.
Modules that use blobs (including TOMOYO) use security_module_enable()
and those that don't just use security_add_hooks(). The "pick one"
policy is enforced in security_module_enable(), which is why you can
have as many non-blob users as you like. You could easily have a
non-blob using module that was exclusive simply by using
security_module_enable().

True. With my removal of security_module_enable(), yes, it makes sense
to mark all LSMs that were calling it before as exclusive, rather than
focusing on whether they would be exclusive under the blob-sharing
situation.

Keep security=$lsm with the existing exclusive behavior.
Add lsm=$lsm1,...,$lsmN which requires a full list of modules

If you want to be fancy (I don't!) you could add

lsm.add=$lsm1,...,$lsmN which adds the modules to the stack
lsm.delete=$lsm1,...,$lsmN which deletes modules from the stack

We've got two issues: ordering and enablement. It's been strongly
suggested that we should move away from per-LSM enable/disable flags
(to which I agree). If ordering should be separate from enablement (to
avoid the "booted kernel with new LSM built in, but my lsm="..." line
didn't include it so it's disabled case), then I think we need to
split the logic (otherwise we just reinvented "security=" with similar
problems).

Should "lsm=" allow arbitrary ordering? (I think yes.)

Should "lsm=" imply implicit enable/disable? (I think no: unlisted
LSMs are implicitly auto-appended to the explicit list)

So then we could have "lsm.enable=..." and "lsm.disable=...".

If builtin list was:
capability,yama,loadpin,integrity,{selinux,smack,tomoyo,apparmor}
then:

    lsm.disable=loadpin lsm=smack

becomes

    capability,smack,yama,integrity

and

    CONFIG_SECURITY_LOADPIN_DEFAULT_ENABLED=n
    selinux.enable=0 lsm.add=loadpin lsm.disable=smack,tomoyo lsm=integrity

becomes

    capability,integrity,yama,loadpin,apparmor


If "lsm=" _does_ imply enablement, then how does it interact with
per-LSM disabling? i.e. what does "apparmor.enabled=0
lsm=yama,apparmor" mean? If it means "turn on apparmor" how do I turn
on a CONFIG-default-off LSM without specifying all the other LSMs too?

-Kees

-- 
Kees Cook
Pixel Security