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 d
