On Mon, 2009-08-10 at 19:25 -0400, Neil Horman wrote:
quoted text
> On Mon, Aug 10, 2009 at 04:48:59PM -0400, Eric Paris wrote:
> > On Mon, 2009-08-10 at 16:23 -0400, Neil Horman wrote:
> > > On Mon, Aug 10, 2009 at 03:45:13PM -0400, Eric Paris wrote:
> > 
> > > > 1) remove CAP_SYS_MODULE from the networking code and instead check
> > > > CAP_NET_ADMIN.  Maybe CAP_NET_ADMIN is already being checked and I'll
> > > > just remove the capable call altogether but at least I can more
> > > > intelligently limit the powers of these processes and they will still be
> > > > root limited according to DAC permissions like they are today.
> > > > 
> > > Would this have any adverse effect on how user space sees this working.
> > > Intuitively I would think that if you wanted to load a module (directly or
> > > indirectly, via an iptables command or whatnot), you would need CAP_SYS_MODULE
> > > capabilities on the calling process, not just CAP_NET_ADMIN.  I honestly don't
> > > know the answer here, I'm just raising the question.
> > 
> > While that might make intuitive sense, it's actually proving to be a bad
> > idea to use the same capability for direct and indirect module loading
> > (especially considering we have 125 other places in the kernel where you
> > can do indirect module loading without any security check)  And believe
> > me, if someone suggests I move a CAP_SYS_MODULE check down into
> > __request_module I'll scream about what a horrible idea that is (and
> > then laugh at them behind their back).
> > 
> > While I think there should be some check in __request_module I don't
> > think it should be CAP_SYS_MODULE.
> > 
> Forgive my excessive density, but what exactly would be wrong with putting a
> CAP_SYS_MODULE check into __request_module?  Is there some sort of implicit
> behavioral change that will mess with user space in doing so?

Yes I believe it would almost certainly break all of the programs
outside of the 3 networking spots which trigger the kernel to try to
load a module.  Take a look at everything that call request_module().  I
believe this because currently there are no security checks on those 125
call sites and security policy does not grant CAP_SYS_MODULE to many
domains (for good reason, it's a @#$% dangerous permission to give
things.)

If the kernel does go that route it will force the security policy to be
loosened such that all of those programs will have permission to
directly load arbitrary data they can create.  As it stands today,
subverting any of those calling programs 'merely' allows the attacker to
make the kernel load a module using modprobe whose name is sometimes
attacker controlled and sometimes not.  I contend that triggering the
kernel to do an upcall is not the same security behavior as loading my
own data directly into the kernel.

That's the whole problem.  There are separate security concerns between
triggering the loading of a known module and directly loading arbitrary
data.  Pushing a CAP_SYS_MODULE check down into __request_module will
result in a less secure system policy in which the attack space on a
system grows since there would be a significantly increased number of
programs with permission to load data directly into the kernel.

If the community feels that CAP_SYS_MODULE in __request_module is the
right way to go that's fine (but I'm not going to send that patch which
i believe will break systems).  I'll just create new security hooks in
init_module, delete_module, and __request_module, which have no DAC
meaning but which LSMs can implement policy with.  Given those 2/3 new
hooks an LSMs can freely grant CAP_SYS_MODULE like candy, since in my
opinion, it becomes a lot less meaningful and we can still meet
meaningful security goals.

-Eric

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html