Re: Preparing Debian for using capabilities: file ownership.

[Raul Miller <moth@debian.org>]

>     Raul> [Also: both have extra baggage, but MAC+capabilities looks
>     Raul> like something safer to switch over to than capabilities
>     Raul> without MAC.]
> 
On Fri, Sep 29, 2000 at 03:20:22PM +1100, Brian May wrote:
> Where can I find out more about MAC? MAC is a completely new acronym
> to me...

Mandantory Access Control.

I did a web search on the term and only found references to firewalls.

I suppose you could go to the same place I did -- Andrew Morgan
<morgan@transmeta.com> -- and ask for references.  There's probably
an NIST publication or some such on the matter.  Let me know if 
you find some good references.

Prior to this week, I thought MAC was a poison information labelling
mechanism -- basically, if the label on the piece of information 
didn't match up with the labels you were allowed to look at, you couldn't
look at it.  The reason I'm advocating MAC, here, is that Andrew Morgan
suggested it to me:

<quote>
Date: Sun, 24 Sep 2000 22:25:27 -0700
From: Andrew Morgan <morgan@transmeta.com>
To: Raul Miller <moth@debian.org>
Subject: Re: file ownership capability?

This is really more suitable for implementation with MAC (Manditory
Access Control). The capability stuff is supposed to only redistribute
superuser privilege. What you are suggesting is really saying that
accessing your own files is a privilege. MAC is intended to do this sort
of firewalling.

Cheers

Andrew

Raul Miller wrote:
> On Sun, Sep 24, 2000 at 07:35:08PM -0700, Andrew Morgan wrote:
> > I'm not sure I follow this. Its hard to guarantee a process id, so how
> > would what you are suggesting work in practice?
>
> Um.. I said that wrong.  Instead of "process id", I mean "uid of the
> process".  So, for example, you could have a root process which did
> not have owner access to any files owned by root.
>
> Thanks,
>
> --
> Raul
</quote>

In retrospect, I think my original impression about MAC is correct, and
I think it would impose an unwarranted level of complexity on the system.
I'm going to write him back for clarification on this issue.

>     >> - what is the current status of capabilities in Linux? Last I heard,
>     >> it was so limited that it was next to useless. I hope this has/will
>     >> change.
> 
>     Raul> They're implemented in 2.4, but they're not ready for prime
>     Raul> time.  The set of capabilities may change, and ext2fs
>     Raul> doesn't let you do the capability analog to setuid (nor the
>     Raul> inverse -- where capabilities are supressed).
> 
> Will it be possible to limit individual processes access to individual
> files? I have a good reason for wanting to do this, but so far, all I
> can tell is that the list of capabilities is fixed/hard-coded in the
> kernel and cannot be changed.

MAC would do this -- though it's a rather ornate system, and it won't
be available for quite a while (if ever).  My rather attracted to my
idea of reclassifying "UID access" and "GID access" as capabilities,
but maybe they would screw up some existing capability-oriented software
which blindly drops all capabilities.

>     Raul> Not very practical. 
> 
>     Raul> kernel change time != package install time.
> 
>     Raul> Basically, we'd be committing to do a complete sweep of the file
>     Raul> system every time the kernel booted.  [Perhaps optimize this by
>     Raul> marking each partition with a stamp indicating what kernel 
>     Raul> has swept the partition?]
> 
> My guess is that supporting both systems could get very messy, very
> quickly.

Well.. if (once the technology has been stably deployed) dpkg (or maybe
dpkg-deb) was altered to implement a locally defined access policy,
we'd be punting the support issues onto the local sysadmin.  Which is
probably the proper way to go anyways (since good security policy,
by definition, is defined by the system owner, not the distributor --
the distributor should just define the default security policy).

> Perhaps enhancing suidregister to support capabilities might be a good
> first step.

It would be a good idea, but beware that linux capabilities are going
to change.  That's pretty much guaranteed.  And, it's very hard to keep
security promises in that context.

Thanks,

-- 
Raul