Re: in defense of SELinux

Yes, restricting access to ambient authority in a fundamentally non
capability system so we can do caps on top of that.

The AppArmor/MinorFs/E stack for example that I've been advocating in the
past is a good example. When running a program with persistent VATs
written in E, this program will need some place to store its
authority-rich state somewhere. On an OS that has no concept of private
storage for persistent processes (it actualy doesn't even have a concept
of persistent processes, so it could not have the concept  of private
storage for persistent processes either), the first thing that is needed
is taking away ambient authority to the places where the E program would
need to store its data.

You really can't do that without some kind of mandatory access control
system like AppArmor or (cough) SELinux.

That is, you need MAC to 'take away' excess authority (and probably some
required authority) and than you need DAC to 'give back' the required
authority and enable access control at both finer AND courser granularity
levels.

Without the MAC as provided by AppArmor for example, the concept of
persistent process private storage as provided by MinorFs would be
completely nullified by the ambient accessibility of /proc/$PID/fd/,
taking away E's ability to serialize its persistent VATS without making
everything in it available to any other process on the system, at least
those running under the same user id.

So in this example, AppArmor takes away excess authority that all the
processes have to the file-system, MinorFs gives back measured required
authority to each process including the program written in E. E uses this
authority to maintain its ocap security properties in regards to other
processes running on the same system.

I hope this is making sense, and shows why I feel that 'some' MAC is
indeed essential.

Rob

On Thu, October 17, 2013 01:39, Mark Miller wrote:
> If you could give a concrete scenario of an enforceable security property
> that mandatory access controls can enforce that ocaps cannot, that would
> be
> wonderful. If there is no such example, I don't understand the rest of
> your
> message -- please clarify. Thanks.
>
>
> On Wed, Oct 16, 2013 at 4:32 PM, Mark S. Miller <[email protected]>
> wrote:
>
>> Hi Rob, what do you mean by "mandatory access control"?
>>
>>
>> On Wed, Oct 16, 2013 at 2:08 PM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:
>>
>>> On Wed, October 16, 2013 20:18, David Nicol wrote:
>>> > On Thu, Oct 10, 2013 at 2:09 AM, Jed Donnelley
>>> > <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>wrote:
>>> >>
>>> >> ---  Just a mild style comment on the talk:  Dr. Watson seems very
>>> >> deferential in his discussion of comparisons with MAC mechanisms -
>>> such
>>> >> as SELinux.  I have to admit that I have an automatic gag reflex
>>> >> whenever I write or speak the word SELinux, but I think that even
>>> >> objectively Dr. Watson didn't make clear just how problematic the
>>> global
>>> >> policy mechanisms of something like SELinux are.  It's like trying
>>> to
>>> be
>>> >> God or a Communist government developing a 10 year plan and
>>> tracking,
>>> >> via explicit policy, everything that goes on in a computer system
>>> (not
>>> >> to mention network).  Things change too quickly.  It simply can't be
>>> >> done.   With capabilities (access control objects) you allow the
>>> >> programmers to manipulate access control where it makes sense
>>> through
>>> >> the communication channels between what he refers to as "sandboxes"
>>> (in
>>> >> other contexts processes or domains).  I believe this distinction is
>>> >> significantly more than religion.
>>> >>
>>> >
>>> > SELinux is appropriate for locking down production systems, and for
>>> that
>>> > purpose it works as designed.
>>> >
>>>
>>> >From my OHM2013 "defeating trojans" speaker notes:
>>>
>>> "Within a single domain of administration and at
>>> relatively course granularity levels, its often a good
>>> idea to create and enforce policies that hinder the
>>> freedom to delegate. That is, creating 'mandatory'
>>> access controls.
>>> While these policies can lead to tighter security, they
>>> don't scale up that well to inter organizational
>>> interaction, neither do they scale down very well to
>>> the finer granularity levels of individual objects.
>>> Mandatory access control policies are notoriously
>>> hard to create and maintain once you start to
>>> approach the granularity levels of processes. On the
>>> other side of the granularity spectrum, cross-domain
>>> mandatory control remains a challenge.
>>>
>>> When we look at access control on Linux we see the
>>> old UNIX discretionary access controls for the
>>> file-system. When we look at sub-user authorization
>>> granularity on Linux, we get into the area of Linux
>>> security modules that implement mandatory access
>>> controls. These two models can seriously get into
>>> each-others way. The best known Linux security model
>>> without any doubt is SELinux. SELinux is amazing for
>>> military organizations and government agencies
>>> working with classified documents and security
>>> clearances. If your main concern however are Trojans
>>> and software vulnerabilities, you will want to use an
>>> alternative that doesn't require system administrators to
>>> have master degree in information security. AppArmor,
>>> used by Suse and Ubuntu Linux, is such a security
>>> module. AppArmor's mandatory model and the
>>> sparse-cap based model also happen to be quite
>>> complementary."
>>>
>>> Needless to say I feel AppArmor for most non MLS purposes is by far
>>> superiour to the more complex and granularity restricted model provided
>>> by
>>> SELinux. While still doing MAC, unlike SELinux, AppArmor has a simple
>>> model thats quite compatible with capabilities and other forms of
>>> authority based access controll on other levels of granularity.
>>>
>>> There is definitely value in restricting delegation in certain settings
>>> at
>>> certain granularity levels, so at the risk as being stoned here for
>>> heresy, yes mandatory access control has its place. However,
>>> capabilities
>>> incompatible mandatory access control like offered by SELinux comes
>>> with
>>> the price of not scaling up (to inter organisational levels) and not
>>> scaling down (to object levels) as it provides a  model incompatible
>>> with
>>> the inevitably discretionary requirements at those courser and finer
>>> granularity levels.
>>>
>>> Rob
>>>
>>> _______________________________________________
>>> cap-talk mailing list
>>> [email protected]
>>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>> _______________________________________________
>> cap-talk mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
>>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>