Re: New LSM patch for consideration

pollardat_private

Stephen Smalley <sdsat_private>:
> 2) The new LSM patch doesn't address moving capabilities into
> a module.  However, I don't see that as a real obstacle - my plan is to
> address capabilities in the new LSM patch, but I first wanted to
> come to a consensus on the following questions:  a) Do we need
> to move the capability bits out of the task_struct and
> linux_binprm structures?  Both?  Either?  Neither?  b) Can
> we limit our changes to the core capability logic, i.e.
> the logic within capable, the logic within the capability system 
> calls, and the capability-specific computations in compute_creds, 
> ptrace, and set*id?  Can we leave all existing capable calls
> unchanged?  I also wanted to ensure that when we move the capbilities
> into a module, we keep a working base kernel with useful security
> behavior.

To answer (reformatted - and all answers are opinion only):

a) Do we need to move the capability bits out of the task_struct and
   linux_binprm structures? Both?  Either?

IMHO, yes, and both of them. I think it would simplify access to these
bits and provide a more centralized repository for the security information.
It might not be easy to move them because of the current implmentation, but
I think they will be moved at some time in the future anyway.

b) Can we limit our changes to the core capability logic, i.e.
   the logic within capable, the logic within the capability system 
   calls, and the capability-specific computations in compute_creds, 
   ptrace, and set*id?

Ptrace may be the most complex to avoid changing... followed by exec and
fork. It may not be possible to do so.

   Can we leave all existing capable calls unchanged?

If the capability bits are moved, I would expect SOME alteration of the
capability calls MAY be necessary. I've not looked at all of them, but
since the code is rather distributed I would expect some "unusual" coding
to have crept into the logic of the calls (similar to the DAC/capability
intertwining).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module