Re: Where Are We?

sdsat_private

On Wed, 6 Jun 2001, Chris Lundberg wrote:

> Oi!  That is a bunch of stuff to think about...  My basic stance, from a
> theoretical, nonimplementational point of view is that all of the logic in
> the kernel should be able to be overridden completely, and that the
> cleanest way to do it in the long run is have the kernel take care of the
> work, whereas the security modules should take care of _all_ of the
> questions as to whether or not it is allowed.  

This sounds fine if you are writing a new kernel.  It doesn't sound
so good if you are modifying an existing kernel that is being
actively developed by many different developers (with a variety
of forked variants) and actively used by many applications that 
depend on certain assumptions about the basic security model.

It sounds like you're taking the most extreme position.  Replace 
all calls to capable() and permission() and all DAC logic with
calls to security hooks.  Move the complete implementation of
permission() into the module, including filesystem implementations
of the inode permission routine.  One thing you may not have
thought of:  moving the attributes used by the base logic into
the opaque security blobs maintained by the modules, e.g.
real uid, effective uid, file system uid, saved uid, 
ditto for gids, group set.  Of course, that means moving
all code that uses those attributes into the modules,
which also affects things like accounting and quotas.

This doesn't seem reasonable to me as an approach for LSM.
I suppose there may be some middle ground, e.g. replace 
calls to capable() with calls to hooks when we want finer-grained
support, move vfs_permission into the module but leave the file system
inode permission routines in the file systems, and move the DAC 
logic into the hook functions when we can colocate the hook calls with
them.  But I'm uneasy about the resulting mixed model, and
I'm not sure it is preferable to my proposed model.

--
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