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

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

[Crispin Cowan]

Greg KH wrote:

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

For those who haven't heard, this topic is part of ongoing development of the
LSM (Linux Security Module) project.  The intent is to enhance the existing
LKM such that effective security modules can be written.  This was inspired by
comments from Linus during the SELinux presentation at the Linux 2.5 summit.

As Greg K-H said, the home page for LSM is here  http://lsm.immunix.org/   The
intent is to get a minimal set of common "hooks" into the mainline Linux 2.5
kernel such that many of the would-be security-enhancing packages for Linux
are happy.  Much of the effort involved in LSM involves working towards a
consensus of what we all (security) people can live with, such that the Linux
kernel community will accept it.

There was a "Kernel Security Extensions" BOF at USENIX last month, which
largely became a LSM BOF.  For a great summary of the current state of LSM,
check out this very nice write-up at LWN
http://lwn.net/2001/0704/security.php3  It pretty accurately captures the
state of consensus now, and the issues we're working to resolve before
LSM comes and bothers Linus with a patch.

In warming up for coming to bother y'all with a patch, we had a meeting with
Ted Ts'o at USENIX.  Ted indicated to us that, by and large, most of the
consensus represented in the LWN write-up is going in the right direction for
acceptance into the main Linux kernel.  If that is NOT true, we certainly want
to hear about it.

Please cc: linux-security-module@wirex.com on this topic.  The LSM list is
closed to non-subscribers, but I run the mailman moderation of the list, and I
will silently approve any post that is topical.

Thanks,
    Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

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

[Hans Reiser]

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

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

[Greg KH]

On Thu, Jul 12, 2001 at 09:35:20PM +0400, 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.

The details can be currently found in the most recent patch against
2.4.6 at:
	http://lsm.immunix.org/patches/lsm-2001_07_06-2.4.6.patch.gz

There's a bit more information available, including the latest version
of the patch at all times, available as a bitkeeper repository at:
	http://lsm.immunix.org/

thanks,

greg k-h

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

[Greg KH]

On Thu, Jul 12, 2001 at 07:37:36PM +0100, Anton Altaparmakov wrote:
> 
> 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.

The current model lets you do whatever you want in your kernel module.
It imposes no policy, that's up to you.

All the better to keep userspace callbacks for security out of my
kernels, for that way is ripe for problems (for specific examples why,
see the linux-security-module mailing list archives.)

thanks,

greg k-h

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

[LA Walsh]

Greg KH wrote:
> The current model lets you do whatever you want in your kernel module.
> It imposes no policy, that's up to you.
---
	That's not exactly true.  It imposes the standard Linux security
policy which someone wanting to remove it or change it might not want.
It only allows you to further restrict based on the current security 
system.  
> 
> All the better to keep userspace callbacks for security out of my
> kernels, for that way is ripe for problems (for specific examples why,
> see the linux-security-module mailing list archives.)
---
	I agree.  Though an individual module writer could theoretically
implement callbacks in their own module, no?

-l

--  -    _    -    _    -    _    -    _    -    _    -    _    -    _    -     
The above thoughts and            | I know I don't know the opinions
writings are my own.              | of every part of my company. :-)

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

[Anton Altaparmakov]

At 19:47 12/07/2001, Greg KH wrote:
>On Thu, Jul 12, 2001 at 07:37:36PM +0100, Anton Altaparmakov wrote:
> >
> > 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.
>
>The current model lets you do whatever you want in your kernel module.
>It imposes no policy, that's up to you.

Ok, that's fair enough. A wrapper module could always be written that then 
in turn invokes user space. That's good enough for me although it makes for 
additional overhead but I guess that is not too bad.

>All the better to keep userspace callbacks for security out of my
>kernels, for that way is ripe for problems (for specific examples why,
>see the linux-security-module mailing list archives.)

Oh, sure. There are problems. I don't deny that. But I am not too sure that 
those problems outweigh the problems created by putting in huge amounts of 
code into the kernel which could live outside it just as well. - IMHO the 
kernel should be as small as possible rather than contain everything under 
the sun just because it's easier to do that way...

Best regards,

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/