do user space object managers really provide mandatory access control

do user space object managers really provide mandatory access control

[Dominick Grift]

I admit that my knowledge of this leaves much to be desired but i will
ask anyway:

If one defines mandatory as "enforced by the kernel", then do user space
object managers provide mandatory access control?

from my understanding user space object managers enforce security
decisions made by the Linux security server.

So can a compromised user space object manager ignore these security
decisions made by the Linux security server?

In other words are user space object manager really a way to enforce MAC
or are they just another application layer access control when push
comes to shove.

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

[Andy Warner]

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.

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. 

-----Original Message-----
From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of Dominick
Grift
Sent: Monday, July 28, 2014 10:33 AM
To: selinux
Subject: do user space object managers really provide mandatory access
control

I admit that my knowledge of this leaves much to be desired but i will ask
anyway:

If one defines mandatory as "enforced by the kernel", then do user space
object managers provide mandatory access control?

from my understanding user space object managers enforce security decisions
made by the Linux security server.

So can a compromised user space object manager ignore these security
decisions made by the Linux security server?

In other words are user space object manager really a way to enforce MAC or
are they just another application layer access control when push comes to
shove.

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
To get help, send an email containing "help" to
Selinux-request@tycho.nsa.gov.

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

[Dominick Grift]

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"

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

> 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.

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

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?

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

[Joshua Brindle]

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.

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

[Andy Warner]

-----Original Message-----
From: Dominick Grift [mailto:dominick.grift@gmail.com] 
Sent: Monday, July 28, 2014 12:44 PM
To: Andy Warner
Cc: 'selinux'
Subject: Re: do user space object managers really provide mandatory access control

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"

I would refute a definition of MAC that restricted it to the OS kernel. But if you did, then obviously you would definition exclude the possibility that MAC could exist outside the kernel, which makes your original questions seem moot. If you presume any MAC implementation is compromised, in user space or kernel, then obviously you have a problem. I do not think it is valid to assume that because something is in "user space" that it is easily compromised, though I understand that OS-centric viewpoint.

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

I would assume they had to make some assurance arguments when they were officially evaluated (RHEL has done this, no?). Some non-bypassibility argument and strategy must be made for any MAC policy enforcement.

>> 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.

For us, we do not want to reinvent the wheel and duplicate functionality of the MAC policy of the OS matches our MAC objectives for the database. If we can rely on a preexisting implementation in our OS, then why not? Also, if the underlying MAC implementation has been officially evaluated (e.g., EAL-4), then that makes our security arguments and evaluations easier.

We also implement a MAC policy within the DBMS that is based upon the XACML policy language. In this case we do it all within the DBMS kernel. Our TE relies upon the OS for security decisions, while our MLS is implemented within the DBMS kernel but mirrors and cooperates with the SELinux MLS mechanism. So, we have varying degrees of what we use the OS for and what we do ourselves.

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

Sure. I would say the same about using a complicated TE MAC policy as opposed to a more simple MLS policy. It's a compromise between flexibility and insurability. 

>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?

For us, a single point of evaluation is a big deal. OS's tend to be evaluated relatively quickly and commonly. 

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

[Dominick Grift]

On Mon, 2014-07-28 at 13:07 +0200, Andy Warner wrote:
> 

> >Thank you. I should rephrase "if one defines" to "when one defines"
> 
> I would refute a definition of MAC that restricted it to the OS kernel. But if you did, then obviously you would definition exclude the possibility that MAC could exist outside the kernel, which makes your original questions seem moot. If you presume any MAC implementation is compromised, in user space or kernel, then obviously you have a problem. I do not think it is valid to assume that because something is in "user space" that it is easily compromised, though I understand that OS-centric viewpoint.

Thank you (and Joshua)

I think i got it now. I was not so much referring to the kernel itself
for the sake of the kernel but it just happens to be the core.

I suppose the take-away for  me is:

SELinux is by definition centralized governance, but not centralized
enforcement. (the latter in part due to practical limitations)

Better this than nothing

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

[Dominick Grift]

On Mon, 2014-07-28 at 13:07 +0200, Andy Warner wrote:

> 
> I would refute a definition of MAC that restricted it to the OS kernel. But if you did, then obviously you would definition exclude the possibility that MAC could exist outside the kernel, which makes your original questions seem moot. If you presume any MAC implementation is compromised, in user space or kernel, then obviously you have a problem. I do not think it is valid to assume that because something is in "user space" that it is easily compromised, though I understand that OS-centric viewpoint.

In my defense: I am not implying that user space is more easily
compromised than the kernel. I was just hoping for a single point of
failure when it comes to enforcement.

I made a mistake by associating "MAC" with "centralized".

although SELinux is a "MAC" system that facilitates centralized
governance (but unfortunately not always centralized enforcement), this
does not mean that this is also a property of "MAC".

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

[Stephen Smalley]

On 07/28/2014 06:44 AM, 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"
> 
> I wonder whether the SELinux object manager related code implements any
> meaningful implementation principles like encapsulation,
> non-bypassibility, or others.

It certainly provides encapsulation of security policy by virtue of
using the same general interface exposed by the kernel security server
and deferring security attribute and policy logic interpretation to the
security server.

It also provides a way to define and enforce a consistent security goal
across all forms of data sharing, whether by file or database record or
D-BUS message or whatever.

It also provides a way to support dynamic policy and atomic policy
updates spanning all forms of data sharing.

And since it is built on SELinux, you have a kernel mechanism in place
that can be used to reliably identify subjects/processes (e.g.
getpeercon, SCM_SECURITY) and to ensure non-bypassability of the
userspace object manager, although it does not mandate that you do so.

None of those benefits are provided by your typical application layer
access control mechanism, nor are they even often considered.

>> 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.
> 
> All-in-all it sound like a lot of compromise.

No, it isn't a compromise at all.  The access control policy enforcement
logic properly belongs in the object manager that manages the object and
implements the operations on it that are being controlled; anything else
leads to insecurity.  In contrast, reimplementing the access control
policy decision making logic in two (or more) places not only provides
no benefit, it causes harm:
- You have to validate each such implementation (evaluation/testing cost),
- You have to maintain each such implementation (maintenance cost),
- Coordination of policy changes that span more than one object manager
is more complex,
- Defining and enforcing a uniform security goal that spans more than
one object manager is more complex,
- Policy analysis is more complex.

> 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?

If I implement an XACML engine in userspace and use SELinux at the
kernel level, then how do I reason about the composition of the two?
How do I know that A can never leak data to B via any form of data
sharing, kernel or userspace?  How do I coordinate a policy change that
spans both engines?  It is of course possible to tie the two together,
but that requires additional infrastructure, introduces additional
complexity, etc beyond what is required for either one separately.

If I only use an XACML engine in userspace and don't use SELinux at all,
then how do I ensure that the XACML engine can't be bypassed?  How do I
reliably identify subjects/clients/processes for access control purposes?