[cap-talk] Defining Mandatory and Discretionary

[Duncan Grove]

Toby Murray wrote:
> On Wed, 2007-08-01 at 17:31 -0400, Jonathan S. Shapiro wrote:
>   
>> On Wed, 2007-08-01 at 21:09 +0100, Toby Murray wrote:
>>     
>>> On Wed, 2007-08-01 at 08:58 -0700, Mark Miller wrote:
>>>       
>>>> Again, I have no idea what you or anyone else (except Alan) means when
>>>> they say "discretionary" or "mandatory". 
>>>>         
>>> The SELinux access controls are discretionary from the point of view of
>>> anyone who can modify them (that is, the policy). They are mandatory
>>> from the point-of-view of anyone who cannot.
>>>       
> These definitions were fleshed out in discussion with Duncan Grove, my
> old work supervisor. We started with the definitions of "mandatory" and
> "discretionary" given in
>
> P. Loscocco, S. Smalley, P. Muckelbauer, R. Tayler, J. Turner, and J.
> Farrel. The inevitability of failure: The flawed assumptions of security
> modern computing environments. In In Proceedings of the 21st National
> Information Systems Security Conference, 1998.
>
> <snip>
>
> It was Duncan who had the insight that, whether it was mandatory or
> discretionary depends on who you are.
>
> I have no idea whether he had read anything that directly sparked this
> insight but I've always believed it to be an independent discovery of
> his.
>
> Hopefully he'll chime in if I've misrepresented him here. 
>   
That's pretty much spot on Toby.

At the time I was reading the paper you mentioned above and also working
my way through the "Orange Book" and it occurred to me how flawed these
definitions of mandatory / discretionary were in modern computer systems
in general and in object-capability systems specifically. Truth be told,
I'd rather that we (the computer security community) all stopped using
the terms mandatory / discretionary entirely, because they imply black &
white when in reality we all know everything is just shades of grey.

I can think of only two exceptions to this, if we absolutely cannot
refrain from (ab)using these terms:

1) Talking about MAC/DAC in a historical context, i.e. as per Orange
Book, where a security administrator oversees the mandatory *policy* of
protecting classified information started by
http://www.fas.org/irp/offdocs/eo/eo-8381.htm. Note that SELinux has
such a policy, I believe, but I suggest that care should be taken to
make it clear that it is the *policy* that is "mandatory", not
necessarily the *mechanism* (as much as we would like it to be).

2) Mechanisms that *really* *are* mandatory, i.e. they are provably
completely non-bypassable / part of the fundamental operation of the
system. (Based on our current understanding of physics, gravity is a
good example ;-). Being a little less rigorous, perhaps we can say that
access-control checks (i.e. "is the capability valid?") are mandatory in
capability or reference monitor systems. But I'd really prefer it if we
stopped there, or else we're on a slippery slope!

For those that are interested I've attached my thoughts about this
question from the time.

Cheers,
Duncan

-------- Original Message --------
Subject: 	Definitions of mandatory security
Date: 	Tue, 07 Sep 2004 09:35:33 +0930
From: 	Duncan Grove <dag at rassilon.annex>
To: 	General Annex Discussion <annex-discuss at annex>


<snip>. In "The Inevitability of Failure: The Flawed Assumptions of 
Security in Modern Computing Environments" <snip> the 
authors say that "Mandatory security mechanisms in the operating system 
may be used to ensure that all accesses to the protected objects are 
mediated by the enforcer component". I reckon this gets to the 
centre of mandatory security, i.e. mandatory security is encoded in the 
unchangeable base primitives of the security architecture. It's just a 
matter of getting these base primitives right. This is why I like the 
notion of an object-capability based function/method dispatcher so much: 
not only does it support <snip> but it provides "mandatory security 
enforcement" at the zeroth-level i.e. whenever objects are 
named/accessed in any way at all, but where the "policy" about access 
rights that gets enforced <snip> [is a meta-problem, although probably
enforcing at least "connectivity begets-connectivity"].

Duncan


IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.