Re: in defense of SELinux

Hi Rob, thanks. This was very clarifying and makes sense.


On Thu, Oct 17, 2013 at 1:09 AM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

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