Discussion:
A basic question about the security_* hooks
Michael Stone
2009-12-24 02:29:02 UTC
Permalink
Dear kernel folks,

There are a variety of places where I'd like to be able to get the kernel to
return EPERM more often [1]. Many of these places already have security hooks.

Unfortunately, I don't feel that I can make effective use of these hooks
because they seem to be "occupied" by the large mandatory access control
frameworks.

I'm hoping that you can tell me why this state of affairs persists.

More specifically, now that LSMs are statically linked, why is it good for the
security hooks to call into a single monolithic "security_ops" struct instead
of cheaper and simpler alternatives?

In particular, what would be worse about a kernel in which each security hook
contained nothing but conditionally-compiled function calls to the appropriate
"real" implementation functions with early-exit jumps on non-zero return codes?

Thanks,

Michael

[1]: Two examples include my recent network-privileges patches and Eric
Biederman's suggestions on how to make unprivileged unshare(CLONE_NEWNET) safe.
I have little doubt that I'd think of more if I thought that the security hooks
were accessible to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Casey Schaufler
2009-12-24 04:50:12 UTC
Permalink
Post by Michael Stone
Dear kernel folks,
There are a variety of places where I'd like to be able to get the kernel to
return EPERM more often [1]. Many of these places already have
security hooks.
That should make it easy!
Post by Michael Stone
Unfortunately, I don't feel that I can make effective use of these hooks
because they seem to be "occupied" by the large mandatory access control
frameworks.
The only reason that your use might not be effective is if
you want to integrate with one or more of those frameworks.
Go ahead and use the LSM for your own nefarious purposes, that
is what it is there for. The whole point of the LSM is that
no two projects could agree on the right approach for moving
security forward. Heavens to Betsy, none of the existing
LSMs have demonstrated themselves as the Way and the Light.

The current set of hooks have grown as needed, primarily driven
by the needs of SELinux, the largest of the Mandatory Access
Control frameworks. Most recently growth has matched the needs
of TOMOYO.
Post by Michael Stone
I'm hoping that you can tell me why this state of affairs persists.
Serious security models, including Type Enforcement, Bell
and LaPadula, Biba, Clark/Willson, Simple Separation, and
Green Light Ice remain the interest of a very small fragment
of the lunatic fringe of computer system deployments. So
long as the mechanism that supports this small but vocal
community is adequate to the task and easy for the rest
of the Linux universe to ignore everyone is more or less
content.
Post by Michael Stone
More specifically, now that LSMs are statically linked, why is it good for the
security hooks to call into a single monolithic "security_ops" struct instead
of cheaper and simpler alternatives?
By all means, suggest an implementation ...
Post by Michael Stone
In particular, what would be worse about a kernel in which each security hook
contained nothing but conditionally-compiled function calls to the appropriate
"real" implementation functions with early-exit jumps on non-zero return codes?
The question is not would it be worse, the question has to be
whether it would be better. In particular, would it be better
for the people who want nothing whatever to do with an LSM,
which remains by far the larger set of people.
Post by Michael Stone
Thanks,
Michael
[1]: Two examples include my recent network-privileges patches and Eric
Biederman's suggestions on how to make unprivileged
unshare(CLONE_NEWNET) safe.
I have little doubt that I'd think of more if I thought that the security hooks
were accessible to me.
You're arguing for stacking a set of small security modules. This
is a direction that has gotten slammed pretty hard in the past but
that crops up every time someone like you comes along with a
module that serves a specific purpose. Mostly the objections have
come from people who will tell you that something else already
does what you're trying to do, and that all you have to do is take
on the entirety of their monolithic approach and you'll be happy.

I'm behind you 100%. Use the LSM. Your module is exactly why we have
the blessed thing. Once we get a collection of otherwise unrelated
LSMs the need for a stacker will be sufficiently evident that we'll
be able to get one done properly.


And just in case it matters, I understand that this is an unpopular
position. I am an advocate of progress, not necessarily my own
peculiar notions of computer security. I believe that we should keep
trying new things for the simple reason that in the twenty plus
years that I've been working on the problem no one has demonstrated
a solution that addresses more than a fraction of the whole. Lots of
great ideas have gotten discarded because they didn't fit into an
MLS system, SELinux, the Linux file system semantics, or the teeny
tiny little minds that control the IETF.



--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric W. Biederman
2009-12-24 12:53:35 UTC
Permalink
Post by Casey Schaufler
I'm behind you 100%. Use the LSM. Your module is exactly why we have
the blessed thing. Once we get a collection of otherwise unrelated
LSMs the need for a stacker will be sufficiently evident that we'll
be able to get one done properly.
My immediate impression is that the big limitation today is the
sharing of the void * security data members of strucutres.

Otherwise multiple security modules could be as simple as.
list_for_each(mod)
if (mod->op(...) != 0)
return -EPERM.

It isn't hard to multiplex a single data field into several with a
nice little abstraction.

With my maintainer of a general purpose kernel hat on I would love to
be able to build in all of the security modules and select at boot
time which ones were enabled.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tetsuo Handa
2009-12-24 21:55:08 UTC
Permalink
Post by Eric W. Biederman
My immediate impression is that the big limitation today is the
sharing of the void * security data members of strucutres.
I think the time to change "void * security" is approaching.

What about allocating dedicated "void *" for each in-tree security modules and
let proposed security modules use "void * security" so that proposed security
modules can be evaluated without allocating dedicated "void *", something like

struct foo {
...
#ifdef CONFIG_SECURITY_SELINUX
void *selinux;
#endif
#ifdef CONFIG_SECURITY_SMACK
void *smack;
#endif
#ifdef CONFIG_SECURITY_PROPOSED
void *security
#endif
}

struct bar {
...
#ifdef CONFIG_SECURITY_SELINUX
void *selinux;
#endif
#ifdef CONFIG_SECURITY_PROPOSED
void *security
#endif
}

?

Regarding TOMOYO, "void * security" automatically added to many structure is
nothing but waste of memory because TOMOYO don't need "void * security" except
"struct task_struct".
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Serge E. Hallyn
2009-12-25 00:05:42 UTC
Permalink
Post by Eric W. Biederman
Post by Casey Schaufler
I'm behind you 100%. Use the LSM. Your module is exactly why we have
the blessed thing. Once we get a collection of otherwise unrelated
LSMs the need for a stacker will be sufficiently evident that we'll
be able to get one done properly.
My immediate impression is that the big limitation today is the
sharing of the void * security data members of strucutres.
Otherwise multiple security modules could be as simple as.
list_for_each(mod)
if (mod->op(...) != 0)
return -EPERM.
It isn't hard to multiplex a single data field into several with a
nice little abstraction.
With my maintainer of a general purpose kernel hat on I would love to
be able to build in all of the security modules and select at boot
time which ones were enabled.
You're supposed to be able to do that now - use the "security=smack"
or whatever boot option (see security/security.c:choose_lsm() ).

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David P. Quigley
2009-12-31 17:50:47 UTC
Permalink
Post by Serge E. Hallyn
Post by Eric W. Biederman
Post by Casey Schaufler
I'm behind you 100%. Use the LSM. Your module is exactly why we have
the blessed thing. Once we get a collection of otherwise unrelated
LSMs the need for a stacker will be sufficiently evident that we'll
be able to get one done properly.
My immediate impression is that the big limitation today is the
sharing of the void * security data members of strucutres.
Otherwise multiple security modules could be as simple as.
list_for_each(mod)
if (mod->op(...) != 0)
return -EPERM.
It isn't hard to multiplex a single data field into several with a
nice little abstraction.
With my maintainer of a general purpose kernel hat on I would love to
be able to build in all of the security modules and select at boot
time which ones were enabled.
You're supposed to be able to do that now - use the "security=smack"
or whatever boot option (see security/security.c:choose_lsm() ).
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ubuntu and SuSe currently do this and it is what allows them to ship a
kernel with both AppArmor and SELinux support built in.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Moore
2010-01-04 02:12:17 UTC
Permalink
Post by Eric W. Biederman
Post by Casey Schaufler
I'm behind you 100%. Use the LSM. Your module is exactly why we have
the blessed thing. Once we get a collection of otherwise unrelated
LSMs the need for a stacker will be sufficiently evident that we'll
be able to get one done properly.
My immediate impression is that the big limitation today is the
sharing of the void * security data members of strucutres.
Otherwise multiple security modules could be as simple as.
list_for_each(mod)
if (mod->op(...) != 0)
return -EPERM.
It isn't hard to multiplex a single data field into several with a
nice little abstraction.
Just another quick point that I didn't see covered yet in this thread ...
while many of the kernel entities have void pointers to track the security
blobs, there are several places where a single u32/int or character string is
used to represent the security label of an entity (look at the per-packet
labeling for an example). While it would be relatively easy to multiple
multiple security blobs on top of a void pointer, multiplexing multiple
security labels/tokens on top of a string/int is a little more difficult.
--
paul moore
linux @ hp
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov
2009-12-24 07:36:54 UTC
Permalink
Post by Michael Stone
There are a variety of places where I'd like to be able to get the kernel to
return EPERM more often [1]. Many of these places already have security hooks.
Unfortunately, I don't feel that I can make effective use of these hooks
because they seem to be "occupied" by the large mandatory access control
frameworks.
I believe you should convice selinux and friends to add support for your
extension, otherwise no distribution will be able to turn it on, since
no two security frameworks can be registered simultaneously.
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Samir Bellabes
2009-12-24 18:57:52 UTC
Permalink
Post by Evgeniy Polyakov
I believe you should convice selinux and friends to add support for your
extension, otherwise no distribution will be able to turn it on, since
no two security frameworks can be registered simultaneously.
I agree, as a LSM module, this purpose is a no sense, because it will
avoid using another security module.
On the other hand, adding this capacity directly to the syscalls seems
to be a little bit ugly (it reminds me security post_accept hook
strategy of returning or not a value).

But the way to go is to add this directly to existing security models,
if it make sens for them.

sam
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Serge E. Hallyn
2009-12-25 00:14:22 UTC
Permalink
Post by Michael Stone
Dear kernel folks,
There are a variety of places where I'd like to be able to get the kernel to
return EPERM more often [1]. Many of these places already have security hooks.
Unfortunately, I don't feel that I can make effective use of these hooks
because they seem to be "occupied" by the large mandatory access control
frameworks.
I'm hoping that you can tell me why this state of affairs persists.
More specifically, now that LSMs are statically linked, why is it good for the
security hooks to call into a single monolithic "security_ops" struct instead
of cheaper and simpler alternatives?
In particular, what would be worse about a kernel in which each security hook
contained nothing but conditionally-compiled function calls to the appropriate
"real" implementation functions with early-exit jumps on non-zero return codes?
The problem is that composing any two security policies can quickly have
subtle, unforeseen, but dangerous effects. That's why so far we have
stuck with the status quo where only one LSM is 'active', but that LSM
can manually call hooks from other LSMs.

So with your module, I'd recommend following the route of the capabilities
LSM. You can provide an optional stand-alone LSM which only hooks your
functions. Then smack, for instance, can call the functions in your LSM
from within its own hooks, or it can simply explicitly assign its hooks to
your functions in smack_ops. Selinux can do the same thing, although I
suspect they would more likely implement their own functions for your newly
hooked sites.

A distro can then compile a kernel with all LSMs compiled in, and switch
behavior by using "security=selinux" vs. "security=prctl_network_lsm"

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael Stone
2009-12-25 01:11:29 UTC
Permalink
Post by Serge E. Hallyn
Post by Michael Stone
In particular, what would be worse about a kernel in which each security hook
contained nothing but conditionally-compiled function calls to the appropriate
"real" implementation functions with early-exit jumps on non-zero return codes?
The problem is that composing any two security policies can quickly have
subtle, unforeseen, but dangerous effects.
First, thanks very much for your helpful explanations and pragmatic advice.

Second, two thoughts and a question:

1. I think you're probably correct when we're discussing security policies
chosen uniformly at random from the space of all possible such policies.
However, I believe that the cost-benefit ratio favors composition quite
strongly when we're discussing real security policies which where designed
with composition in mind, as is the case with my work.

2. The problem you cite is an inherent property of software assurance which
is indepedent of software assurance of information-security-specific
properties. Thus, while you are correct that composition sometimes makes
it harder to assure a system due to the increased number of "moving
parts" that have to fit together perfectly, it also frequently makes the
assurance problem more tractable by reducing the cost to assure the
individual pieces which are being composed.

3. Have you any specific examples of problems that have been clearly averted
by the current arrangement?
Post by Serge E. Hallyn
So with your module, I'd recommend following the route of the capabilities
LSM. You can provide an optional stand-alone LSM which only hooks your
functions. Then smack, for instance, can call the functions in your LSM
from within its own hooks, or it can simply explicitly assign its hooks to
your functions in smack_ops. Selinux can do the same thing, although I
suspect they would more likely implement their own functions for your newly
hooked sites.
Doesn't it seem a bit strange to you to be recommending that everyone else
using the five security hooks I want to use modify their code *in detail* to
support my functionality given that my functionality is explicitly intended not
to requir