Linux Security Module listsecurity (and security xattr hooks) only one called?

[Valdis.Kletnieks at vt.edu]

On Tue, 06 Sep 2016 07:05:54 -0400, "Pasquier, Thomas" said:

> If one of the module return a non-zero value, the other are not called.
> That means that the list of security of xattr is not built (or rather that
> it only contains the first module being called), as the lenght of inserted

That's working as designed, and won't be changing.

The LSM framework is designed as restrictive, not permissive. In other words.
the exit can deny an access, but cannot allow an otherwise denies access.

In other words, as soon as the access is denied by any one exit, there's no
reason to bother calling other exits - we can short-circuit the evaluation
of the list.  Think of it as being logically:

	if (exit1 || exit2 || exit3 ||.. |exitN)  return access_denied;

The reason it won't change is because doing analysis of a security system
that has parts that are both restrictive and permissive is almost impossible.
Even trivial stacking can produce problems - consider 3 exits that all
can either deny a request or force it to be allowed.  Now think of the
game of rock-paper-scissors....

And if you're playing rock-paper-scissors-lizard-Spock, it gets worse....

> element is returned. Similarly for setsecurity and getsecurity, it seems
> that only one module will be called as if the given module does not support
> the security xattr, it returns -EOPNOTSUPP (instead I believe the next
> module being called, until one supporting the attribute is met).

That is because currently, there's only support for one stacked module
that uses xattrs at a time.

> What is the rational here? I could change the code to support multiple
> security xattr, but don't want to do so before I am sure I understand why
> it was done like this. Any help is welcome.

Compositing two or more security schemes complicated enough to need xattrs,
and doing so in a secure manner, is a lot harder than it looks.  You'd be
amazed at the number of ways things can go pear-shaped when things start
interacting... (See the challenges of beating the original POSIX capabilities
into submission for inclusion.  Turned out the POSIX draft had some very
subtle bugs in the ruleset....)

If you're interested in chasing it further, you should probably
ask on the linux-security-module at vger.kernel.org list.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 830 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160906/96f1228f/attachment.bin