Re: A basic question about the security_* hooks

[Michael Stone <michael@laptop.org>]

> Well, taking a step back - what exactly is the motivation for making this
> an LSM? Is it just to re-use the callsites?

Yes. Alan Cox, referencing earlier versions of my patches, wrote:

   "This is a security model, it belongs as a security model using LSM."

> I ask bc the API is in the prctl code, so the LSM
> is conceptually always there, which is different from other LSMs.

The goal is to provide a stupidly simple unprivileged per-process network
isolation primitive which is broadly available "without jumping through hoops".

(See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.) 

I need a primitive like this to further my work on the OLPC Bitfrost security
architecture and to further my more general work on advancing the state of
sandboxing technology. (See sandboxing.org.)

I'm willing to entertain pretty much any implementation or interface request
which meets that goal and which implements the desired semantics.

>>>> In particular, what would be worse about a kernel in which each security
>>>> hook contained nothing but conditionally-compiled function calls to the
>>>> appropriate "real" implementation functions with early-exit jumps on
>>>> non-zero return codes?
>>>
>>> The problem is that composing any two security policies can quickly have
>>> subtle, unforeseen, but dangerous effects.
>> 
>> Have you any specific examples of problems that have been clearly averted
>> by the current arrangement?
>
> If you look back over the archives of when I was pushing the LSM stacker
> around 2005, there were several cases where just stacking capability and
> selinux were problematic.

Thank you for the pointers to your earlier work and for the work itself. We
probably wouldn't be having this conversation if your work had been merged.
Unfortunately, that happy event did not come to pass.

Thus, returning to today: the most serious objection that I've heard so far
about LSM stacking is that making it too "automatic" is likely to result in
preventable security faults.

For this argument to be valid, there *must* also be a second clause which
states that the cost of the unknown security faults prevented by making
stacking hard exceeds the cost of the known security faults which would be
prevented by the additional security primitives that stacking, in any usable
form, would permit. Otherwise, the sustaining the objection leads to a worse
outcome. 

Now, given this argument, what do you actually think about systems that, like
your work, enable stacking but which do so "less automatically", e.g. by
hand-writing the implementations of the security_*() hooks like so:

   int security_socket_create(int family, int type, int protocol, int kern) 
   {
           int ret = 0;

   #ifdef CONFIG_SECURITY_SELINUX
           ret = selinux_security_socket_create(family, type, protocol, kern);
           if(ret)
                   goto out;
   #endif

   #ifdef CONFIG_SECURITY_TOMOYO
           ret = tomoyo_security_socket_create(family, type, protocol, kern);
           if(ret)
                   goto out;
   #endif

   #ifdef CONFIG_SECURITY_SMACK
           ret = smack_security_socket_create(family, type, protocol, kern);
           if(ret)
                   goto out;
   #endif

   #ifdef CONFIG_SECURITY_PRCTL_NETWORK
           ret = prctl_network_socket_create(family, type, protocol, kern);
           if(ret)
                   goto out;
   #endif

   out:
           return ret;
   }

This way, the behavior of the system is as predictable as possible, we can
statically check for known unsafe configurations, manual tweaking of the order
in which functionality is composed is possible, and security is fully
"pay-as-you-go".

Where is the flaw in this approach?

Regards,

Michael

P.S. - I think I will write up some new patches for prctl_network based on this
idea so that we can see what they look like.