Re: Security hooks, "standard linux security" & embedded use

[Anton Altaparmakov]

Hello Linda, Hans,

This seems very good in view of implementing ACL support for NTFS, too. - 
We have all the NTFS layout knowledge to do it now. We just lack the 
kernel/user space infrastructure.

When designing this modular security infrastructure it would be useful if 
it is made generic enough to allow callbacks into user space for permission 
checking.

For example, if permissions are to be obtained from a remote server over 
some obscure (or not, could be tcp/ip for that matter) protocol you do not 
really want to be doing this in the kernel, IMHO. Or another example would 
be mapping Unix UIDs from/to Microsoft SIDs, again much better done in user 
space, IMHO. It would be a Good Thing if this could be passed onto a user 
space demon to do the work instead of having to write such potentially 
big/complex code in kernel space.

Just my 2p.

Best regards,

         Anton

At 18:35 12/07/2001, Hans Reiser wrote:
>Hi Linda,
>
>This seems very much in line with what Reiser4 is doing for DARPA, and 
>what SE Linux is doing for
>the NSA.  Or at least what Linus told the SE Linux folks he would like 
>them to write.:-)
>
>I am quite supportive of what you advocate generally, and I look forward 
>to cooperating with you in
>the details.
>
>May I suggest we contact the SE Linux folks, and each of our teams 
>establish a point-of-contact to
>work on
>developing the details of what needs to be done?
>
>We call your security hooks "security plugins" or "secplugs" in Reiser4, 
>mostly to identify that
>they are a component of the Reiser4 "plugin" approach to 
>extensibility.  Reiser4 is getting underway
>this month.  We are willing to adapt our terminology and coding to be be 
>consistent with yours.  We
>don't really have a need to be the leaders in this area.  We just need to 
>get the job done, and to
>ensure that nothing that is done crimps our ability to accomplish our 
>objectives.  Our project
>objectives are somewhat describable as "make it easy for folks like the 
>NSA and the DoD to add new
>security features to Reiser4 by building the infrastructure for them."  We 
>will ship one
>implementation on top of that infrastructure that will implement ACLs, but 
>we are more interested in
>enabling others than in doing ourselves.  If the NSA or SGI wants to lead 
>us a bit on this, that is
>fine with us.  Our main insistence is going to be that the hooks should be 
>very general, but I
>suspect you and the NSA also want that.  We also need to have coding 
>completed in ~8 months, so that
>it can all be debugged and stable and sent to Linus by Sep. 30th of next year.
>
>Do you have a list of all the hooks, etc., yet?  Do you have anything like 
>a general architecture
>for, given some vfs operation, and given some pluginid indicating object 
>type, and given some
>secplugid  (e.g. it might be the id of a secplug implementing an ACL), 
>have the plugin check that
>the operation is allowable by calling the secplug (security hook) 
>indicated by the secplugid?
>
>I think what is needed is an MxN matrix of security checks, where M is the 
>number of vfs operations,
>and N is the number of secplugs.  I am open to the idea that it should be 
>MxNxO, where O is the
>number of security policies, though I don't plan to personally implement 
>more than one security
>policy to ship with Reiser4 by default because I am pretty lazy.  It won't 
>surprise me if I end up
>shipping only one secplug with reiser4 initially (probably one 
>implementing something embodying NT
>ACLs and unix permissions), and leave it to others to add the rest of them).
>
>I am quite supportive of your notion that some users have no need at all 
>for security, and that they
>should be allowed a lightweight solution for their needs, though I will 
>leave it to them to write
>that on top of the infrastructure I/we give them.:-)  I envision the VFS 
>operation invoking the
>plugin which invokes the secplug whose implementation varies with the 
>choice of security policy
>compiled in.  I don't honestly see the real usage critical need for 
>dynamic loading of security
>policy modules, but I can yield on this if you see the need and code it 
>since it probably isn't
>complex to code.  I do like the idea of all of the code implementing a 
>given security policy being
>isolated into its own single file/directory.
>
>Do you have any ideas on how to export to user space the ability to query 
>what the permissions are,
>given that the permissions are being abstracted like this?
>
>I got your email, but I wasn't on the to: or cc: list.  This confused me, 
>so I invented a to: list
>that should reach all those likely to be interested in this.  I am 
>guessing this will be okay with
>you.
>
>Best,
>
>Hans
>
>LA Walsh wrote:
> >
> > Dear Linus et al.,
> >
> >         Sorry for the 'form' letter instead of individual names, but I
> > didn't want to have to send this out separately to every kernel developer
> > I know on LKML.
> >
> >         I am asking for your input on the concept of moving the standard
> > Linux security checks into a "Linux Security Module".
> >
> >         Discussion has come up on the Linux Security Module list
> > about whether or not the current linux security (file mode bits, uid
> > checking, etc.) should be modularized in the development of an LSM
> > framework implementation
> >
> >         This would entail moving all of the standard checks out of the
> > kernel into a "standard security" module that, by default, would be
> > the security policy selected and compiled in during kernel configuration
> > and build.
> >
> >         This seems to us (@sgi) to be the best solution to allow a
> > completely configurable security policy.  This option allows
> > a policy creator complete flexibility in how or whether or not
> > existing security is called.  For example, in POSIX 1e style Mandatory
> > Access Control, the information in the inode is also part of the
> > protected object.  So if a process doesn't have access under MAC, the
> > DAC checks wouldn't even be executed since it doesn't have
> > access to the permission bits, owner and group info in order to
> > perform a DAC check.  Some security policies may wish to be called
> > conditionally after the existing security is checked.
> >
> >         Most importantly, this implementation addresses the needs of
> > the embedded market by allow them to remove some or all of the existing
> > checks.  I believe Linus mentioned that some embedded developers didn't
> > even want the security that was already present.  They might have no need
> > for separate users or non-root users.  Just "1" user id that is
> > always running out of ROM in root mode (i.e. everything is permitted).
> > This proposed implementation allows them to save both the memory,
> > a critical resource for some embedded systems) as well as the
> > execution time spent doing the standard checks.
> >
> >         It has come up on the list that such an implementation would never
> > be accepted by the "Kernel developers" as being too invasive.  However
> > we believe 2.5 would be the perfect place to develop and implement
> > such a scheme.
> >
> >         So I am unofficially soliciting feedback from various kernel
> > developers to ascertain if the statement about the "kernel developers"
> > is widely held, or made by a select few purporting to represent the whole.
> > Others on the list would like apriori approval by the "Linux Kernel
> > developers" before embarking on such a bold implementation.
> >
> >         Your comments, opinion and, even, buy-in (if you want this)
> > would be invaluable.  If you wish to chime in directly the
> > list archives and subscription info is at:
> >
> > http://mail.wirex.com/mailman/listinfo/linux-security-module
> >
> > Thank-you.
> >
> > Sincerely,
> > Linda Walsh
> > --
> > L A Walsh, law at sgi.com         | Sr Eng, Trust Technology
> > 01-650-933-5338                   | Core Linux, SGI
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [e-mail]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/