[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20060407201301.GA29137@suse.de>
Date: Fri Apr 7 21:49:33 2006
From: tonyj at suse.de (Tony Jones)
Subject: [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
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
Powered by blists - more mailing lists