Re: Where Are We?

clundberat_private

On Wed, 6 Jun 2001, Stephen Smalley wrote:

>
> On Wed, 6 Jun 2001, Chris Lundberg wrote:
>
> > Chris (Other Chris): Move kernel logic into a default security module.
> > Chain (or in some VERY restricted cases replace) onto that default module
> > for everyone elses modules.
>
> Could you clarify what you mean by "kernel logic"?  (Same question to
> each person who is advocating moving the kernel logic into the modules).
> For example, does "kernel logic" include all >500 calls to capable(),
> including cases where capable() is called by itself rather than
> being in compound logic?  Or would you be satisfied simply to
> have the compound logic statements plus the guts of the capable
> function in the module, leaving many of the simple capable() calls
> unchanged?  Also, what part of permission() constitutes "kernel logic"?
> Is it just the vfs_permission logic?  What about when the file system
> implementation defines its own permission routine for its inodes?
> Does "kernel logic" just mean the call to inode->i_op->permission,
> or does it mean all of the permission routines in the various
> filesystem implementations?

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.  Thus, I believe that all
capability(), permission(), etc operations should be called by security
hooks.  I further believe that the logic (as it exists now) should be
transformed into a module or set of modules that are commonly
present/chained and are known to work together.  From there, our security
modules can chain off of that list to override those decisions.  My
reasons:

1) From what I understand, there are some folks out there that want LESS
security (not less restrictive, so much as flat out less checking) whereas
others (us, in general) want more security (again, not so much more
restrictive as more complex and robust).  It would be cool if we could
meet both groups' requests.  I believe that including all security
(including user permissions, uids, cap(), perm(), etc) as a module or set
of modules will allow both groups to achieve this goal.  Caveat: I do not,
at present, have a good plan for implementing these modules, only that I
would like them implemented.

2) It will make the kernel clean, in general.  There will be one call to a
series of chained functions.  It will be obvious what that call does.  It
eventually returns whether or not to execute the functionality, and if
not, why not.

3) It will make module development relatively clean.  All modules must
then use chaining, which is a minor nuisance, but by no means impossible
to enact.  The modules then must make their decision based on the error,
or lack of an error, passed by the previous module.

4) It wil make the modules robust.  Modules will be able to be permissive,
or restrictive, or both.  Another caveat: chaining has its own development
problems, which are unfortunate artifacts of not being able to compose
arbitrary functions.  Chain order will always be important.  We'll have to
deal with that if we use chaining.

5) It will make more sense.  All of the calls to any type of security
restriction or permission are in security, not scattered about the kernel.
There will be hooks scattered around, but that is far cleaner than the (as
you mentioned) 500+ calls to capable.  I'm all for compartmentalizing
things.  Put security in security where it belongs.

Of course, this plan of action is not an easy, quick fix, and will require
that a lot of convincing be done to ensure that we are eventually
accepted, but I believe it is the correct way.

Chris Lundberg
Harvey Mudd College

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