Re: [Apparmor-dev] Re: Re: [SC-L] Re: [Owasp-dotnet] RE: 4 Questions:Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code

[Tony Jones <tonyj () suse de>]

On Fri, Apr 07, 2006 at 11:56:36AM -0700, Seth Arnold wrote:
> More dangerous to grant would be CAP_SYS_ADMIN, CAP_SYS_MODULE,
> CAP_SYS_PTRACE, CAP_SYS_RAWIO. Of course you only have to grant
> these capabilities to processes that require the functionality these
> capabilities allow -- if you don't need the functionality, then you do
> not need to grant the capabilities.

Part of the issue is that some hooks that existed in the 2.4LSM patch which 
tended to be called immediately following capable() were dropped when LSM was 
accepted into 2.5.

CAP_SYS_MODULE is one example (security_module_create being the old hook).
Thru this hook we used to disallow any attempt by a confined task to load 
a module (as of course modifying the kernel could easily compramise AppArmor 
enforcement). Now all we can do is check whether the profile grants the task 
CAP_SYS_MODULE (remember of course that the task has to also have the 
capability in it's effective set, usually this means it's euid 0).

This isn't a particularly brilliant example as CAP_SYS_MODULE is a narrowly
used capability (I need to go look thru the code for better ones) but I believe
there were cases of hooks which were removed and replaced by more broadly used 
capabilities.

Clearly, the more granular the capabilities are, the better AppArmor can be
and the safer a user can sleep at night after granting a task access to one.

Tony

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/