linux-security-module November 2007 archive
Main Archive Page > Month Archives  > linux-security-module archives
linux-security-module: Re: [Apparmor-dev] Re: File descriptor ob

Re: [Apparmor-dev] Re: File descriptor object capability LSM module. Feasability?

From: Crispin Cowan <crispin_at_nospam>
Date: Tue Nov 13 2007 - 08:15:36 GMT
To: Mark Seaborn <mrs@mythic-beasts.com>


Mark Seaborn wrote:
> Crispin Cowan <crispin@crispincowan.com> wrote:
>> The other issue with the object capability model is analyzability.
>> Stephen Smalley complained about this in some public setting a while ago
>> when someone basically asked for an object capability enhancement to
>> SELinux. Stephen is correct, in that with a pure ambient capability
>> model, you can analyze the text of the complete system policy, and
>> readily determine the maximum permissions that any given entity will
>> have under that policy. With an object capability model, the scope of
>> access of a given program is determined by what gets passed into it, and
>> so you would have to resort to tools to compute the transitive closure
>> of all capabilities that *could* be delegated to it.
>>
> That is not true in the general case. If process A and process B can
> communicate, process A can delegate any authority it has to process B,
> if both processes want to do that. Putting object-capability support
> into the kernel is just a way of making that more efficient and
> convenient. SELinux/Apparmor are no more analyzable than
> object-capability systems.
>
> There is only a difference in analyzability if:
> - you decide you're not including malicious programs (i.e. not an
> adversarial model), or
> - you define analyzability so that you're measuring something that
> is not important (permissions) rather than something that is
> (authority).
>

E.g. if process A acts as a proxy for process B, then it is just as if B has access to A's resources.

SELinux deals with this with their information flow analysis, assuming that the security policy will only permit A and B to communicate if the policy allows them to. So they regulate authority through control of message passing.

A conservative estimate of worst-case damage would say that if two processes can communicate, then they have the same authority. Transitive closure of IPC could put a *lot* of processes into the same authority domain.

AppArmor is relatively weak at information flow control. You *could* do information flow analysis in AppArmor, but you would have a hard time, have to build some exotic tools, and add some features. As such, it seems intuitive that AppArmor and object capabilities would be a good fit.

So lets try a thought experiment using Rob Meijer's idea of object capabilities for file descriptors passed around, as it is a relatively natural fit for UNIX. In AppArmor, this would mean that we *never* check whether a passed FD is allowable in the receiving profile. Now consider that against the standard AppArmor design metrics:

  • does it pass 'least surprise' for UNIX users? for AppArmor users?
  • is it learnable?
  • is it excessively complex?

So, does it pass 'least surprise'? Kind of. It is intuitive for people from the object capability world, but it is counter-intuitive for AA users: you look at the profile, it says what files the program can access, and you find it accessing something not in the profile without any mediation going on. WtF? One hybrid suggestion has been that AA profiles continue acting the way they currently do, unless there is an "object capable" notation in the profile header or something, alerting the reader that this profile can fully accept FDs from elsewhere.

Is it learnable? I think so. The module could notice if a file was accessed without first being opened. If it was in complain mode, it would issue a record to add the "object capable" notation to the profile. If it was in enforce mode and there was no "OC", then block as AA traditionally does.

Is it excessively complex? I don't think so.

So, all that said, I would be happy to see object capability features added to AA, if it is optional, and off by default.

>> o Show a use case of a real program (not a straw man) such
>> that with the current features, your choice is to either
>> provide a dangerously permissive security policy, or the
>> policy breaks the program.
>>
> An e-mail client. With a static security system, if you want to be
> able to use the e-mail program to send attachments, you must grant the
> e-mail program access to all of your files in advance, because you
> could want to send any file as an attachment.
>

I don't see how OC actually helps this case, *unless* you hack the software to use a proxy program that has access to all files. This is what I meant in other discussions about OC being better for OC-aware software, and ambient capabilities better for legacy software. To take advantage in this situation, you must hack the software as well as use policy.

Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html