[cap-talk] [Apparmor-dev] [ANN] FastRPC, a continuation of imsep

[Mark Seaborn]

Crispin Cowan <crispin at novell.com> wrote:

> Mark Seaborn wrote:
>
> > A process's privileges are the actions it can perform on objects it
> > can directly access, by direct requests to the kernel.  "Permission"
> > means the same as "privilege".
> >
> > A process's authority describes the actions the process can cause to
> > be performed on objects it can access, either directly by permission,
> > or indirectly by permitted interactions with other processes.
> >   
> So "authority" is just the transitive closure of "privilege"?

Not exactly.

Authority takes into account program behaviour as well.

The transitive closure of privilege gives you a conservative
approximation to authority, an approximation that overestimates
authority.

For example: The "passwd" utility has write access to /etc/shadow.
I have the ability to run "passwd".  Taking the transitive closure of
permissions would give an approximation of authority that says I have
write access to /etc/shadow and can alter anyone's password.  However,
"passwd" is a security property enforcing program, and its behaviour
is such that I can't actually use it to change anyone's password (or
so you'd hope).  So the approximation is not very accurate in this
case.

Generally an authority analysis will get an approximation by making
assumptions about the behaviour of some security-enforcing processes,
while taking other processes to be unknowns.


> > Process B therefore has the authority to write to file F, even though
> > it does not have permission.
> >
> > Process A has the ability to revoke this authority by ceasing to
> > follow B's requests, but until then process B has that authority.
> >   
> .. so then when Process B tells Process A to do something, it is of the
> "mother may I?" variety, and not the "thou shalt" variety.

Right.  Process A *wants* to share its authority with process B, or
more accurately, the author of the code running in process A wanted to
share this authority with process B.

> This doesn't sound like the canonical human cultural use of "authority"
> at all. I realize I am arguing with established definitions, but they
> still suck :)

Right, the non-technical definitions of "authority" should be thrown
out the window when dealing with computer security. :-) The only sense
of "authority" that applies is "power" (as in ability to do things or
find out things), with no connotations of whether the power is
legitimate, justified, etc.

To be fair, the technical meanings of "privilege" and "permission" are
also rather different from their everyday meanings.  The two words
usually have different connotations but in this context they are the
same.


> > I agree.  Preventing delegation of authority between processes that
> > can communicate and want to share the authority happens to be
> > something that cannot be enforced.
> >   
> Ok. So using the above definitions of "privilege" and "authority", I
> agree that preventing delegation of "authority" is effectively
> impossible so long as processes A and B can communicate, and in the
> presence of covert channels and steganography, that is very hard indeed.
> 
> This sheds some light on the problem. I have always views "authority" in
> this sense as "not my problem" and AppArmor is about managing privilege.
> The recent change in handling file descriptors was to close a hole so
> that privilege really cannot be delegated. We do this because an AA
> profile is supposed to be a complete specification of that program's
> privileges.

OK, my question is, why do we care about privilege at all?  We should
only care about privilege to the extent that it enforcably limits
authority.  Beyond that, we are not talking about enforcable security
any more.  Authority is the property that we should really care about
where security is concerned.

If malware causes damage, it really doesn't matter whether it does the
damage by making direct requests to the kernel or by making requests
that go through other processes.


> >>>> I can't speak for what the SELinux developers intended. What the
> >>>> AppArmor design intended was that the policy for the program receiving
> >>>> the FD should describe all of the files it can access, regardless of how
> >>>> it came to access them.
> >>>>         
> > (I was taking "all of the files the program can access" to be an
> > authority property.)
> >   
> I see what you are getting at, esp. when I said "regardless of how it
> came to access them" would suggest to you that I meant authority.

I would see "all of the files the program can access" as an authority
property unless it were otherwise qualified, e.g.
"all of the files the program has permission to access"
or "all of the files the program can access through direct requests to
the kernel".

> However, I view delegating FDs as delegating privilege, not authority,
> because when Process A hands an FD to process B, the result is that A
> *loses* the ability to revoke access to the file to process B. Thus an
> FD is a privilege, not an authority.

It is both.  A process's authority is a superset of its privilege.


> >   Are there restrictions on communicating
> > across pipes/sockets?
> >   
> File descriptors passed through a pipe are "revalidated" at the
> receiving end before being handed to the process. We check that the
> receiver has the privilege to access the file pointed to by the FD.

OK, I meant restrictions on communicating at all, i.e. communicating
data across a socket or pipe.  But it sounds like there aren't any.
Which is fair enough.


> More importantly, Mike Hearn's application does poorly in AppArmor
> because he wrote it with object capabilities in mind, and AppArmor is an
> ambient capability system that is doing its best to prevent privilege
> delegation.

Do you mean that the problem of writing a limited-authority image
decoder inherently does poorly in AppArmor, or that Mike Hearn chose a
way to implement it that is not suited to AppArmor?


> It is a typical AppArmor design trade-off: We give up specicifity in the
> security policy (resulting in looser "least privilege") to obtain easier
> comprehensibility and manageability. An administrator can look at the
> profile (privilege set) for an application and *know* that that is all
> it can ever do, no matter what kind of bamboozling an attacker might try
> on it.

Again I would take "all it can ever do" to be an authority property,
even if it were not suffixed with "no matter what kind of bamboozling
an attacker might try on it"!

You could say you intended for "all it can ever do" to refer to
privilege.  I think this could end up in a Lewis Carrollesque
discussion.  An analagous dialogue might be:

Alice: "I printed this document..."
Bob: "No you didn't, the printer printed it, all you did was ask the
      printer to print it!"
Carol: "Actually, Alice asked the computer to ask the printer to print it."

I would rather go with Alice's use of the language.  Alice can't
directly ask the printer to print documents, but usually that is not a
concern and we abstract it away by saying that "Alice can print
documents".  Similarly, we would say "process X can do Y" even if the
process has to send requests via another process to do so.


> AppArmor is not trying to be EROS.

Just as well, there aren't many programs that run on EROS. ;-)

> AppArmor is trying to sneak capabilities into the typical UNIX
> administrator's life without the UNIX admin even noticing they are
> there.

> There are lots of things you can do with an object capability system
> that you cannot do with AppArmor, but those things (mostly?) are
> things that require application awareness of object capabilities,
> and AppArmor was designed to provide enhanced security to
> applications that are oblivious to object capabilities.

But it would be good to allow applications that *are* aware of
object-capabilities to use them where doing so improves security,
wouldn't it?

Cheers,
Mark