Re: permissive vs. restrictive issue and solutions...

sdsat_private

On Mon, 4 Jun 2001, Casey Schaufler wrote:

> No. This is wrong thinking. Every commercial security effort
> has tried the "first do no harm" approach, and the results
> have been universally atrocious. Let's face it. If we as a
> group cannot push the LSM agenda past the cycle-counters and
> the code screw-up cowboys then we have no business in the
> Linux kernel. Somebody is going to whine about any change
> that goes in.

People are likely to whine more about changes that have no
perceived value, especially if they are pervasive
and significant.  I suspect that moving the base Linux 
access control logic out of the kernel has little or no 
perceived value to the Linux kernel developers.  They
may be happy to see the capabilities logic (i.e. the guts
of the capable function, the execve capability processing, and the 
processing in the capability system calls) move out of the base kernel, 
but I would be surprised if they are eager to see us replace
every capable() call and every piece of access control logic code
in the kernel. 

We can support a wide range of useful security modules 
(SELinux, DTE, RSBAC, SubDomain, ...) simply by adding a 
set of hooks that are orthogonal to the existing access control
logic.  We can allow the capabilities logic to exist
as a module simply by replacing the guts of capable() with
a hook and replacing the capability processing in execve
and the new system calls with calls to hooks.  

> And what does that gain? It doesn't help selinux, which proports
> to policy generality. It doesn't help a CAPP (formerly C2) effort,
> which would have to add hooks anyway for audit purposes. It doesn't
> help the "no policy" folks.

It helps SELinux.  As I've said before, the current SELinux system
is purely restrictive.  We would like permissive support someday,
but it isn't as critical and we can provide coarse-grained
permissive support simply using the hook called by capable(). 
The "no policy" folks are likely to be ok with the DAC+root
behavior.  Auditing could be supported via post- hooks, but
it isn't clear that LSM is trying to provide such support.

> This isn't a prototype. It's the real McCoy, and it's going
> to be hard. My CAPP module needs it. It will speed my work
> considerably if I can do it all in the module.

Do you really need all of the logic moved out of the kernel?
Or just post- hooks?  Where exactly do you need these post- hooks?
Why not propose such hooks to be added to LSM?

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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