| Main Archive Page > Month Archives > linux-security-module archives |
Re: File descriptor object capability LSM module. Feasability?
From: Crispin Cowan <crispin_at_nospam>Date: Fri Nov 09 2007 - 23:01:22 GMT
To: rmeijer@xs4all.nl
Added apparmor-devel because Rob proposes something that could be an
enhancement to AppArmor.
Rob Meijer wrote:
> A while ago I asked some questions on the subject of at* system calls
> on the list and got rather dismissive responses.
> After having given up on the whole concept for a while, the recent
> discussions on this list have made me put some more efford into trying
> to define more clearly what I would like to try to achieve.
>
> http://polacanthus.net/fdoc.html
>
> I am interested to learn if from this short document it is clear what I
> would like to accomplish with an FdOC LSM module, and if this is clear,
> if the things that would be required as patches to the LSM base code would
> potentialy be acceptable to achieve the goal of making an LSM module that
> more or less confirms to the object capability model.
>
The goals are reasonably clear.
I really like the idea of striving for POLA/object capabilities with respect to open file descriptors rather than files, as it will fit better with the traditional UNIX DAC model.
Your document talks about LSM having a security syscall. I think this was removed long ago, and if you want to have a syscall, you are supposed to implement it as a user-level library on top of a file system. AppArmor does this for the change_hat() API for an example.
> Further I would like to hear (if the abouve are feasable), if I should build
> an LSM module for just this purpose, or if I should try to put the sugested
> functionality in a patch set proposal for an existing LSM implementation
> that could be complementary (AppArmor would seem like a good complementary
> functionality).
>
AppArmor has traditionally been a purely ambient capability system (none
of the privileges can be delegated). More recently, JJ and I have been
discussing hybrid models, where some things can be delegated, especially
with respect to network access controls. In particular, consider the
case of xinetd, which accepts connections, then passes the open network
connection to a child for processing.
The reason I prefer an ambient capability system for AppArmor is that ambient capabilities are superior for confining legacy applications that are oblivious to capabilities, and thus unable to sensibly delegate them. File descriptors and network connections make an interesting exception, precisely because UNIX applications already know how to delegate file descriptors, so there is a sound reason to consider using an object capability model for file descriptors.
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.
Tractability of global policy is already a strength of SELinux vs. AppArmor, and so this also argues that it would be a good idea to tend toward object capabilities to enhance the difference between SELinux and AppArmor.
I have two design philosophies that would tend to limit how far we go into object capabilities:
- Keep it simple: a lot of why it is so nice to use AppArmor is because it is simple. Therefore, for any proposed new feature I apply this litmus test: 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.
- Be learnable: Most of the current AppArmor policy features are generated in policy by the automated learning tools. There are a few features that are not "learnable" (use of variables) and to this day they are not used much. This is not an absolute rule, but the case for including a feature that cannot be utilized by automatic learning had better be compelling.
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