Re: do user space object managers really provide mandatory access control

[Joshua Brindle <brindle@quarksecurity.com>]

Dominick Grift wrote:
> On Mon, 2014-07-28 at 11:13 +0200, Andy Warner wrote:
>> MAC is usually defined as not being discretionary (it is mandatory). That
>> is, the enforcement of the policy is not at the discretion of a user or
>> owner. In my experience it is not defined as "being enforced by the kernel."
>> Generally MAC also implies (and sometimes demands) implementation principles
>> like encapsulation and non-bypassibility, which a kernel based
>> implementation might satisfy, but it is not a requirement of MAC to be
>> implemented in the kernel.
>>
>
> Thank you. I should rephrase "if one defines" to "when one defines"
>

One should not define MAC that way. MAC has nothing to do with where it 
is implemented. The original FLASK implementation [1] was actually 
implemented on a microkernel so most of the access control was in userspace.

[1] http://www.cs.utah.edu/flux/fluke/html/index.html

> I wonder whether the SELinux object manager related code implements any
> meaningful implementation principles like encapsulation,
> non-bypassibility, or others.
>

Insomuch as the policies prevent other, non-enforcing, applications from 
accessing the data, then yes. If the SELinux kernel objects that 
encapsulate SEPostgreSQL objects are only accessible by SEPostgreSQL 
then SEPostgreSQL can completely arbitrate access to its objects (rows, 
tables, etc) that the kernel does not know about.

>> I work in MAC based DBMS's which from your perspective could just be
>> considered an application layer, but it is implementing real MAC.  One
>> reason it cannot be totally implemented in the kernel is that the MAC is
>> arbitrating access to non-OS objects, such as database rows, tables, etc.
>> The DBMS can cooperate with the kernel and use the kernel for MAC based
>> decisions (if the MAC policy objectives are the same) but it cannot be
>> totally implemented in the kernel. At least, not without lots of tricky
>> theoretical work, which was my research topic years ago in grad school.
>> Enforcement of the policy is a key difficult issue.
>
> Depending on the answer to my question above that might beg the question
> then: why not implement a security server, and cache in the user space
> object manager itself. Although i think i know the answer to that
> question in advance: to facilitate centralized government of the policy
> rather than having that scattered all over.
>

You can. There was even a userspace security server project a few years 
back.

> All-in-all it sound like a lot of compromise.
>

Try getting Linus to let in patches that let the kernel understand 
database rows and tables for the sake of security and you'll quickly 
find that it is not a compromise, but the only practical answer.

> What, other than providing a central place of governance, would be the
> benefits of SELinux user space object managers, over any other "MAC"
> solutions implemented solely in the user space c.q. application layer?
>

You got it. The flask architecture is decide in one place, enforce 
everywhere else. Just because an object owner is in userspace does not 
make it fundamentally different from an object owner in the kernel. Who 
owns the objects should be enforcing access control. If all your 
filesystems were actually userspace processes, would it not make sense 
for them to still enforce access to files?

One practical benefit is the ability to get an active policy from the 
security server and run analysis on it. Granted you need to understand 
how object managers interact - this goes for kernel too. If you can 
access block devices directly then filesystem object managers can be 
bypassed. The policy needs to take that into account, and an analyst 
needs to understand it.