|Main Archive Page > Month Archives > linux-security-module archives|
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.
> 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
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:
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 firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html