A basic question about the security_* hooks

[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?

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]

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]

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]

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]

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]

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]

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.

[Evgeniy Polyakov]

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.

[Samir Bellabes]

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]

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]

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 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
--
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]

Post by Michael Stone

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

Post by Michael Stone

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 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().

Post by Michael Stone
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
--
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]

Post by Serge E. Hallyn
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."

Post by Serge E. Hallyn
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.

Post by Serge E. Hallyn

Post by Michael Stone

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.

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

Post by Michael Stone
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
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
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
--
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]

Post by Serge E. Hallyn
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.
--
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

[V***@vt.edu]

Post by Tetsuo Handa
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.

[Serge E. Hallyn]

Post by V***@vt.edu

Post by Tetsuo Handa
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?

...

Post by V***@vt.edu
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

[Tetsuo Handa]

Thank you for your opinion.

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?

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

[V***@vt.edu]

Post by Tetsuo Handa
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?"

[V***@vt.edu]

On Mon, 28 Dec 2009 20:51:49 +0900, Tetsuo Handa said:

(Hit send too soon)

Post by Tetsuo Handa
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...

Post by Tetsuo Handa
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.

[Tetsuo Handa]

Post by V***@vt.edu

Post by Tetsuo Handa
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).

Post by V***@vt.edu

Post by Tetsuo Handa
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.

Post by V***@vt.edu
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.
--
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

[Pavel Machek]

Post by Tetsuo Handa
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

[Kyle Moffett]

Post by Michael Stone

Post by Serge E. Hallyn
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
--
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]

Post by Kyle Moffett

Post by Michael Stone

Post by Serge E. Hallyn
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.

Post by Kyle Moffett
The default SELinux policies are rather fantastically complicated,

Everyone, I didn't say that. He did.

Post by Kyle Moffett
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.

Post by Kyle Moffett
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.

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

[Kyle Moffett]

Post by Casey Schaufler

Post by Kyle Moffett

Post by Michael Stone
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.

Post by Kyle Moffett
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

[Casey Schaufler]

Post by Kyle Moffett

Post by Casey Schaufler

Post by Kyle Moffett

Post by Michael Stone
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.

Post by Kyle Moffett
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.

Post by Kyle Moffett
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?

Post by Kyle Moffett
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

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

[Mimi Zohar]

On Thu, 2009-12-24 at 23:50 -0600, Serge E. Hallyn wrote:

<snip>

Post by Serge E. Hallyn
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

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