[PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock

On 9/14/2018 1:05 PM, Kees Cook wrote:

On Fri, Sep 14, 2018 at 8:57 AM, Casey Schaufler [off-list ref] wrote:

quoted

On 9/13/2018 5:19 PM, Kees Cook wrote:

quoted

We already have the minor LSMs that cannot change order.

Are you saying that we don't have a mechanism to change
the order, or that they wouldn't work right in a different
order? Well, there's the capability module that has to be
first.

I just meant their order is explicit in security.c.

quoted

quoted

They aren't
part of security= parsing either.

True, but there's no reason now that we couldn't change that.
Except for capability. Hmm.

Right, we have at least one that MUST be first (and must not be disabled).

quoted

quoted

Should "blob-sharing" LSMs be like major LSMs or minor LSMs?

I like the idea of changing the minor modules to do the full
registration process. That would make them all the same.
Except for capability. In any case, the "blob-sharing" LSMs
need to do the full registration process to account for their
blobs sizes, and that brings the "major" behavior along with it.

I agree. I'm working on some clean-ups that I'll send out soon, though
I'm worried about some of the various boot-time options...

Looking forward to seeing them.

quoted

quoted

If someone is booting with "security=selinux,tomoyo" and then SARA
lands upstream, does that person have to explicitly add "sara" to
their boot args, since they're doing a non-default list of LSMs?

Yes. security= is explicit.

quoted

(I actually prefer the answer being "yes" here, FWIW, I just want to
nail down the expectations.)

For now let's leave the minor (capability, yama, loadpin) as they are,
and require all new modules of any flavor to use full registration.

I would even be fine to convert yama and loadpin.

That shouldn't be difficult.

quoted

We could consider something like

security=$lsm           # Stack with $lsm at priority 2 - Existing behavior
$lsm.stacked=N          # Add $lsm to the stack at priority N. Delete if N == 0

It's OK to specify "selinux.stacked=2" and "sara.stacked=2". Which gets
called first is left up to the system to decide. Whatever the behavior is
gets documented. Capability will always be first and have priority 1.
It's OK to specify "smack.stacked=1".

I'm less excited about this kind of stacking priority, but, whatever
the case, I think my cleanups may help with whatever we decide.

OK

quoted

The default stack is determined by CONFIG_SECURITY_$lsm_STACKED at
build time. CONFIG_SECURITY_$lsm_STACKED changes from a boolean to
an integer value to establish the default hook order.

/sys/kernel/security/lsm reports the modules in hook call order.

Didn't I send a patch to new-line terminate this list? I always get
annoyed when I "cat" it. ;)

SELinux set the precedence on that one. Not my fault!

quoted

/sys/kernel/security/lsm-stack reports the list with the hook call priority

        capability:1,yama:1,selinux:1,sara:5,landlack:17

If stacking is not configured $lsm.stacked=0 is treated as security=none.
For other values of N $lsm.stacked=N is treated as security=$lsm.

I feel like "order" is bad enough. Can we avoid adding "priority"?

Sorry. I changed terminology (order and priority) halfway through the
message. Yes, I like order better. We should stick with that.