Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

[Crispin Cowan]

Peter Dolding wrote:
> On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>   
>> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
>>>   
 Peter Dolding wrote:
 
>   Assign application to
> a cgroup that contains there filesystem access permissions.   Done
> right this could even be stacked.  Only give less access to
> application unless LSM particularly overrides
 This comes no where close to AppArmor's functionality:

 * Can't do learning mode
 * Can't do wildcards
 * Sucks up huge loads of memory to do that much FS mounting (imagine
   thousands of bind mounts)
 * I'm not sure, but I don't think you can do file granularity, only
   directorie
>>> Ok sorry to say so far almost percent wrong.  Please note netlabels
>>> falls into a control group.  All function of Apparmor is doable bar
>>> exactly learning mode.   For learning mode that would have to be a
>>> hook back to a LSM I would expect.
>>>
>>> Done right should suck up no more memory than current apparmor.  But
>>> it will required all LSM's doing file access to come to common
>>> agreement how to do it.  Not just hooks into the kernel system any
>>> more.
>>>   
>> The ability to provide alternative access control schemes is the
>> purpose of LSM. The fact that we insane security people can't come
>> to the agreement you require is why we have LSM. You can not have
>> what you are asking for. Please suggest an alternative design.
>> 
> Part of the building the alternative design requires aggreeing to
> build sections common.
>   
Ok.

I vehemently disagree with your design ideas. So do lots of other
people, and I have not seen one single person ever speak up in favor of
your ideas. So far, you have no agreement at all.

 Containers and access controls provide related but different functions.
 Stop trying to force containers to be an access control system, it does
 not fit well at all.

 Rather, we need to ensure that LSM and containers play well together.
 What you proposed in the past was to have an LSM module per container,
 but I find that absurdly complex: if you want that, then use a real VMM
 like Xen or something. Containers are mostly used for massive virtual
 domain hosting, and what you want there is as much sharing as possible
 while maintaining isolation. so why would you corrupt that with separate
 LSM modules per container?
 
>>> Please stop being foolish.  Xen and the like don't share memory.   You
>>> are basically saying blow out memory usage just because someone wants
>>> to use a different LSM.
>>>   
>> Yup. No one ever said security was cheap. Most real, serious security
>> solutions implemented today rely on separate physical machines for
>> isolation. Some progressive installations are using virtualization,
>> and the lunatic fringe uses the sort of systems well served by LSM.
>> Let's face it, people who really care are willing to pay a premium.
>> 
>
> Bigger problem Containers are processor neutral Xen and lot of the
> other solutions are not.  There are advantages for people who don't
> need full blown.  There needs to be two levels.  Ie VM for the heavy.
>  Containers for where the security is needed but no to the point of
> needing two different kernels.
Remarkable. I agree completely with this paragraph, but draw the
opposite conclusion that you do.

Having private LSMs per container means having a separate kernel per
container. That would seem to put that idea in the "heavy" category.
Which is why I suggested that people who want to do what you desire
should use full VMM instead of containers.

>   Now restricting what can be in a
> Container due to some poor reason that has not been attempted to be
> worked around is not a valid reason.
It is rejected for perfectly sound engineering reasons like complexity
bloat and memory bloat. Come back with a workable design or STFU.

>In theory using Containers you
> should be able to run every Linux distro on earth under one kernel as
> long as it supports that series kernel.  Ie 2.6 2.4...
In "theory" as long as this theory ignores the fact that all distros
patch their kernel. So yeah, you can run different "distros" as long as
you don't care about device support, and you ignore which LSM you want
to use.

Containers fundamentally share the kernel, and the LSM module(s) loaded
are part of the kernel, and therefore are fundamentally shared among the
Containers.

>>> Besides file access control is part of running containers isolated in
>>> the first place and need to be LSM neutral.
>>>   
>> File access control is within the scope of the LSM. If your feature
>> can't deal with that you need to fix your feature.
>> 
> This is the problem for containers File access controls need to be
> like netlabels common between LSM's.

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

[Peter Dolding]

On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
>
> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>
> > On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> > > Peter Dolding wrote:
> > > >>> What is left unspecified here is 'how' a child 'with its own profile'
> > is
> > > >>> confined here. Are it is confined to just its own profile, it may that
> > > >>> the "complicit process" communication may need to be wider specified 
> > > >>> to
> > > >>> include this.
> > > >>>
> > > > Sorry have to bring this up.  cgroups why not?
> > > Because I can't find any documentation for cgroups? :)
> > >
> > > >   Assign application to
> > > > a cgroup that contains there filesystem access permissions.   Done
> > > > right this could even be stacked.  Only give less access to
> > > > application unless LSM particularly overrides.
> > > >
> > > This comes no where close to AppArmor's functionality:
> > >
> > > * Can't do learning mode
> > > * Can't do wildcards
> > > * Sucks up huge loads of memory to do that much FS mounting (imagine
> > >   thousands of bind mounts)
> > > * I'm not sure, but I don't think you can do file granularity, only
> > >   directories
> > >
> > Ok sorry to say so far almost percent wrong.  Please note netlabels
> > falls into a control group.  All function of Apparmor is doable bar
> > exactly learning mode.   For learning mode that would have to be a
> > hook back to a LSM I would expect.
> >
> > Done right should suck up no more memory than current apparmor.  But
> > it will required all LSM's doing file access to come to common
> > agreement how to do it.  Not just hooks into the kernel system any
> > more.
>
> The ability to provide alternative access control schemes is the
> purpose of LSM. The fact that we insane security people can't come
> to the agreement you require is why we have LSM. You can not have
> what you are asking for. Please suggest an alternative design.

Part of the building the alternative design requires aggreeing to
build sections common.
Like the netlabels.  We need this for other parts like filesystems.
>
> > At the container entrance point there needs file granularity applied
> > for complete and correct container isolation to be done.
> > >
> > > > There are reasons why I keep on bring containers up it changes the
> > > > model.  Yes I know coming to a common agreement in these sections will
> > > > not be simple.   But at some point it has to be done.
> > > >
> > > Containers and access controls provide related but different functions.
> > > Stop trying to force containers to be an access control system, it does
> > > not fit well at all.
> > >
> > > Rather, we need to ensure that LSM and containers play well together.
> > > What you proposed in the past was to have an LSM module per container,
> > > but I find that absurdly complex: if you want that, then use a real VMM
> > > like Xen or something. Containers are mostly used for massive virtual
> > > domain hosting, and what you want there is as much sharing as possible
> > > while maintaining isolation. so why would you corrupt that with separate
> > > LSM modules per container?
> >
> > Please stop being foolish.  Xen and the like don't share memory.   You
> > are basically saying blow out memory usage just because someone wants
> > to use a different LSM.
>
> Yup. No one ever said security was cheap. Most real, serious security
> solutions implemented today rely on separate physical machines for
> isolation. Some progressive installations are using virtualization,
> and the lunatic fringe uses the sort of systems well served by LSM.
> Let's face it, people who really care are willing to pay a premium.

Bigger problem Containers are processor neutral Xen and lot of the
other solutions are not.  There are advantages for people who don't
need full blown.  There needs to be two levels.  Ie VM for the heavy.
 Containers for where the security is needed but no to the point of
needing two different kernels.  Now restricting what can be in a
Container due to some poor reason that has not been attempted to be
worked around is not a valid reason.   In theory using Containers you
should be able to run every Linux distro on earth under one kernel as
long as it supports that series kernel.  Ie 2.6 2.4...  Now that is
only the base level of Containers.  More advanced Zones like solaris
will see other platforms running in a container under the same kernel.
 Current designing around containers is not dealing with what I can
do.  It more how will we hack it to work.  Not make sure it will
support where Container design can go.
>
> > Besides file access control is part of running containers isolated in
> > the first place and need to be LSM neutral.
>
> File access control is within the scope of the LSM. If your feature
> can't deal with that you need to fix your feature.

This is the problem for containers File access controls need to be
like netlabels common between 

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

[Casey Schaufler]

--- Peter Dolding <[EMAIL PROTECTED]> wrote:

> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> > Peter Dolding wrote:
> > >>> What is left unspecified here is 'how' a child 'with its own profile'
> is
> > >>> confined here. Are it is confined to just its own profile, it may that
> > >>> the "complicit process" communication may need to be wider specified to
> > >>> include this.
> > >>>
> > > Sorry have to bring this up.  cgroups why not?
> > Because I can't find any documentation for cgroups? :)
> >
> > >   Assign application to
> > > a cgroup that contains there filesystem access permissions.   Done
> > > right this could even be stacked.  Only give less access to
> > > application unless LSM particularly overrides.
> > >
> > This comes no where close to AppArmor's functionality:
> >
> > * Can't do learning mode
> > * Can't do wildcards
> > * Sucks up huge loads of memory to do that much FS mounting (imagine
> >   thousands of bind mounts)
> > * I'm not sure, but I don't think you can do file granularity, only
> >   directories
> >
> Ok sorry to say so far almost percent wrong.  Please note netlabels
> falls into a control group.  All function of Apparmor is doable bar
> exactly learning mode.   For learning mode that would have to be a
> hook back to a LSM I would expect.
> 
> Done right should suck up no more memory than current apparmor.  But
> it will required all LSM's doing file access to come to common
> agreement how to do it.  Not just hooks into the kernel system any
> more.

The ability to provide alternative access control schemes is the
purpose of LSM. The fact that we insane security people can't come
to the agreement you require is why we have LSM. You can not have
what you are asking for. Please suggest an alternative design.

> At the container entrance point there needs file granularity applied
> for complete and correct container isolation to be done.
> >
> > > There are reasons why I keep on bring containers up it changes the
> > > model.  Yes I know coming to a common agreement in these sections will
> > > not be simple.   But at some point it has to be done.
> > >
> > Containers and access controls provide related but different functions.
> > Stop trying to force containers to be an access control system, it does
> > not fit well at all.
> >
> > Rather, we need to ensure that LSM and containers play well together.
> > What you proposed in the past was to have an LSM module per container,
> > but I find that absurdly complex: if you want that, then use a real VMM
> > like Xen or something. Containers are mostly used for massive virtual
> > domain hosting, and what you want there is as much sharing as possible
> > while maintaining isolation. so why would you corrupt that with separate
> > LSM modules per container?
> 
> Please stop being foolish.  Xen and the like don't share memory.   You
> are basically saying blow out memory usage just because someone wants
> to use a different LSM.

Yup. No one ever said security was cheap. Most real, serious security
solutions implemented today rely on separate physical machines for
isolation. Some progressive installations are using virtualization,
and the lunatic fringe uses the sort of systems well served by LSM.
Let's face it, people who really care are willing to pay a premium. 

> Besides file access control is part of running containers isolated in
> the first place and need to be LSM neutral.

File access control is within the scope of the LSM. If your feature
can't deal with that you need to fix your feature.

> This is the problem current model just will not work.  Some features
> are need in Linux kernel all the time and have to become LSM neutral
> due to the features of containers.

Sounds like a conflict in requirements.

> Next big after filesystem most likely will be the common security
> controls for devices.  These are just features need to complete
> containers.  Basically to do containers LSM have to be cut up.  Or
> containers function will be dependent on the current LSM to be use
> completely.

I would be perfectly happy without containers, just as I understand
you don't give a rat's pitute about LSMs. If you want my cooperation
and/or backing on containers, show me how they make my life better,
and how cutting up LSM is to my advantage. I am perfectly willing
to consider alternatives, but I confess that my natural reaction to
confrontation is to fight back.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

[Peter Dolding]

On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Peter Dolding wrote:
> >>> What is left unspecified here is 'how' a child 'with its own profile' is
> >>> confined here. Are it is confined to just its own profile, it may that
> >>> the "complicit process" communication may need to be wider specified to
> >>> include this.
> >>>
> > Sorry have to bring this up.  cgroups why not?
> Because I can't find any documentation for cgroups? :)
>
> >   Assign application to
> > a cgroup that contains there filesystem access permissions.   Done
> > right this could even be stacked.  Only give less access to
> > application unless LSM particularly overrides.
> >
> This comes no where close to AppArmor's functionality:
>
> * Can't do learning mode
> * Can't do wildcards
> * Sucks up huge loads of memory to do that much FS mounting (imagine
>   thousands of bind mounts)
> * I'm not sure, but I don't think you can do file granularity, only
>   directories
>
Ok sorry to say so far almost percent wrong.  Please note netlabels
falls into a control group.  All function of Apparmor is doable bar
exactly learning mode.   For learning mode that would have to be a
hook back to a LSM I would expect.

Done right should suck up no more memory than current apparmor.  But
it will required all LSM's doing file access to come to common
agreement how to do it.  Not just hooks into the kernel system any
more.

At the container entrance point there needs file granularity applied
for complete and correct container isolation to be done.
>
> > There are reasons why I keep on bring containers up it changes the
> > model.  Yes I know coming to a common agreement in these sections will
> > not be simple.   But at some point it has to be done.
> >
> Containers and access controls provide related but different functions.
> Stop trying to force containers to be an access control system, it does
> not fit well at all.
>
> Rather, we need to ensure that LSM and containers play well together.
> What you proposed in the past was to have an LSM module per container,
> but I find that absurdly complex: if you want that, then use a real VMM
> like Xen or something. Containers are mostly used for massive virtual
> domain hosting, and what you want there is as much sharing as possible
> while maintaining isolation. so why would you corrupt that with separate
> LSM modules per container?

Please stop being foolish.  Xen and the like don't share memory.   You
are basically saying blow out memory usage just because someone wants
to use a different LSM.

Besides file access control is part of running containers isolated in
the first place and need to be LSM neutral.

This is the problem current model just will not work.  Some features
are need in Linux kernel all the time and have to become LSM neutral
due to the features of containers.

Next big after filesystem most likely will be the common security
controls for devices.  These are just features need to complete
containers.  Basically to do containers LSM have to be cut up.  Or
containers function will be dependent on the current LSM to be use
completely.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

[Crispin Cowan]

Peter Dolding wrote:
>>> What is left unspecified here is 'how' a child 'with its own profile' is
>>> confined here. Are it is confined to just its own profile, it may that
>>> the "complicit process" communication may need to be wider specified to
>>> include this.
>>>   
> Sorry have to bring this up.  cgroups why not?
Because I can't find any documentation for cgroups? :)

>   Assign application to
> a cgroup that contains there filesystem access permissions.   Done
> right this could even be stacked.  Only give less access to
> application unless LSM particularly overrides.
>   
This comes no where close to AppArmor's functionality:

* Can't do learning mode
* Can't do wildcards
* Sucks up huge loads of memory to do that much FS mounting (imagine
  thousands of bind mounts)
* I'm not sure, but I don't think you can do file granularity, only
  directories


> There are reasons why I keep on bring containers up it changes the
> model.  Yes I know coming to a common agreement in these sections will
> not be simple.   But at some point it has to be done.
>   
Containers and access controls provide related but different functions.
Stop trying to force containers to be an access control system, it does
not fit well at all.

Rather, we need to ensure that LSM and containers play well together.
What you proposed in the past was to have an LSM module per container,
but I find that absurdly complex: if you want that, then use a real VMM
like Xen or something. Containers are mostly used for massive virtual
domain hosting, and what you want there is as much sharing as possible
while maintaining isolation. so why would you corrupt that with separate
LSM modules per container?

What makes sense to me is to ensure that it is easy for an LSM module to
have a policy per container. This is relatively easy to do, and maps
very well to the primary use of containers for hosting virtual domains.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Apparmor-dev] Re: AppArmor Security Goal

[Peter Dolding]

> > What is left unspecified here is 'how' a child 'with its own profile' is
> > confined here. Are it is confined to just its own profile, it may that
> > the "complicit process" communication may need to be wider specified to
> > include this.

Sorry have to bring this up.  cgroups why not?  Assign application to
a cgroup that contains there filesystem access permissions.   Done
right this could even be stacked.  Only give less access to
application unless LSM particularly overrides.

Comtainers allow overriding / in chroot style.  This needs file or
label based protection no matter the security framework.  So we don't
have the chroot problems of applications breaking out.

Apparmors file access control features along with selinux's as a
combined into a cgroup would be good.

Same is required for device control.

There are reasons why I keep on bring containers up it changes the
model.  Yes I know coming to a common agreement in these sections will
not be simple.   But at some point it has to be done.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Apparmor-dev] Re: AppArmor Security Goal

[Crispin Cowan]

Re-sent with proper addressing ...

Rob Meijer wrote:
>> The
>> system is "defended" in that the worst the attacker can do to corrupt
>> the system is limited to the transitive closure of what the confined
>> processes are allowed to access.
>> 
> The damage the atacker can do would be defined by the authority not the
> permissions the process has.
>   
As far as I can tall, the transitive closure of permissions is precisely
authority.

>> * AppArmor confines processes if they are children of a confined
>>   process, or if the name of the exec'd child matches the name of an
>>   AppArmor profile.
>> 
> What is left unspecified here is 'how' a child 'with its own profile' is
> confined here. Are it is confined to just its own profile, it may that
> the "complicit process" communication may need to be wider specified to
> include this.
>   
It is deliberately unspecified in this document, because it is a matter
of policy. And this item that you've excerpted is just one of a list of
specific disclaimers that were put here in response to criticisms and
misunderstandings of AppArmor in the past.

Remember, the purpose of *this* document is to define the security goals
that AppArmor has to live up to. It is fine to use it as a jumping off
point for design ideas that some system might employ some day, or even
proposed enhancements to AppArmor itself, but don't over-burden the
"security goal" document, it needs to be short & comprehensible.

>> * A confined process can operate on a file descriptor passed to it
>>   by an unconfined process, even if it manipulates a file not in the
>>   confined process's profile. To block this attack, confine the
>>   process that passed the file descriptor.
>> 
> This should not count as an 'attack' given that the unconfined process
> would either be trusted, or be mallicious and fall inside the "influence"
> of the confined process anyway.
>   
It counts as a surprising result, and so is specifically disclaimed. I
can tell it is surprising, because it surprised Andi Kleen :)

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Casey Schaufler]

--- Joshua Brindle <[EMAIL PROTECTED]> wrote:

> Casey Schaufler wrote:
> > --- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> >
> >   
> >> Dr. David Alan Gilbert wrote:
> >> ...
> >>
> >> Can you explain why you want a non-privileged user to be able to edit
> >> policy? I would like to better understand the problem here.
> >>
> >> Note that John Johansen is also interested in allowing non-privileged
> >> users to manipulate AppArmor policy, but his view was to only allow a
> >> non-privileged user to further tighten the profile on a program. To me,
> >> that adds complexity with not much value, but if lots of users want it,
> >> then I'm wrong :)
> >> 
> >
> > Now this is getting interesting. It looks to me as if you've implemented
> > a mandatory access control scheme that some people would like to be able
> > to use as a discretionary access control scheme. This is creepy after
> > seeing the MCS implementation in SELinux, which is also a DAC scheme
> > wacked out of a MAC scheme. Very interesting indeed.
> >   
> 
> This is the same sort of thing we are trying to do in SELinux with the 
> policy management server 
> , 
> ofcourse the policy management server enforces SELinux policy on what 
> can be changed and what can't. We devised a scheme to allow the policy 
> to become more restrictive without being able to change the policy 
> 'intent' using a type hierarchy.
> 
> In fact I was talking to a coworker today about how this could be done 
> with smack, using the same kind of hierarchy and allowing unprivileged 
> users (eg., those without MAC_OVERRIDE) to create new smack labels 
> 'under' their own which would be restricted. This is interesting because 
> of the ability to create new smack domains on the fly but since only 
> privileged users can do it it is of limited use. Imagine if a user could 
> create a new domain for their webbrowser or anything else they care to. 
> Since they can't add rules to the policy it would effectively just be a 
> user sandbox, an interesting use indeed.

It would be easy to add a label "owner" the same way that there's
an optional CIPSO mapping now. Writes to /smack/load would require
that the writer be the owner of the object label in the rule. I think
it would still require privilege to assign ownership, a non-parsed
write to /smack/labelowner should suffice for the mechanism. It seems
that you might need to support multiple labels for this to be really
effective, but I'm not sure why I think that. I'm also not sure that
once you draw a complete picture it won't be indistinguishable from
POSIX ACLs.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[John Johansen]

On Mon, Nov 12, 2007 at 03:50:59PM -0800, Crispin Cowan wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >   
> >> I mostly don't see this as a serious limitation, because almost everyone
> >> has their own workstation, and thus has root on that workstation. There
> >> are 2 major exceptions:
> >>
> >> * Schools, where the "workstations" are thin client X terminals and
> >>   everyone is logged into a giant shared machine. Sorry, AppArmor is
> >>   not a good choice for that environment, but it is a pretty scarce
> >>   environment.
> >> * Enterprises, where workers get their own workstation, but they
> >>   don't get root. Well, the reason the worker doesn't get root is
> >>   the enterprise doesn't trust them with it, and so not letting them
> >>   edit security policy is probably a good idea.
> >> 
> > I don't actually see your distinction here between those two environments;
> > why does it matter if there is one non-priveliged user or many?
> >   
> Because it is easier to solve if there is only one non-privileged user:
> you just give them privilege (fun with chmod and sudo) to edit the
> system policies, and you're done (assuming you are happy allowing the
> non-privileged user to edit policy at all).
> 
> If there are lots of non-privileged users sharing a computer, then I
> submit that solutions are either insecure, intractable, or purely
> restrictive.
> 
yep, it needs to be purely restrictive

> >> Can you explain why you want a non-privileged user to be able to edit
> >> policy? I would like to better understand the problem here.
> >> 
> > I think it might depend on how strict the users starting point is;
> > you could say:
> >1 This document editor can read and write any part of the users home
> >  directory other than the . files.
> >
> > or you could say:
> >2 This document editor can read any files but only write to the
> >  'Documents directory'.
> >
> > If the adminisrator set something up with (2) as the starting point it
> > would seem reasonable for the user to be able to add the ability to edit
> > documents in extra directories for their style of organising documents
> > they work on; but they would be restricted in what they could add
> > so that they couldn't add the ability to write to their settings
> > files.
> >   
> Ok, I can see where that would be useful in theory. But solving it is
> VERY hard in practice, and AppArmor is not attempting to address this
> problem of user extensibility of mandatory access controls.
> 
Well at least its not on Crispin's list.  It is something I have been
interested in for a long time.  I can't say when or it will happen
as I need to find some, ever elusive, spare time to work on it.


pgpV0zNn9KBxP.pgp
Description: PGP signature

Re: AppArmor Security Goal

[Crispin Cowan]

[EMAIL PROTECTED] wrote:
> a question for Crispin,
>   is there a wildcard replacement for username? so that you could
> grant permission to /home/$user/.mozilla.. and grant each user
> access to only their own stuff? I realize that in this particular
> example the underlying DAC will handle it, but I can see other cases
> where people may want to have users more intermixed (say webserver
> files or directories for example)
This is possible, but tricky. There is no internal kernel data structure
for a UID's home dir. That is parsable at policy load time, so we could
enhance the language so that a rule of "~/.plan" expanded into a special
token that corresponded to some table of user home directories at the
time the policy was loaded. But that is racy, as it becomes invalid if
anyone's home dir moves, or any users are added or removed.

Another way to do it is what JJ posted: enhance the rule language so you
can have one rule for files that you own, and a different rule for files
owned by others. The AppArmor community (well, JJ and I :) are debating
the cost/benefit of this: is the added flexibility worth the added
complexity?

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Joshua Brindle]

Casey Schaufler wrote:

--- Crispin Cowan <[EMAIL PROTECTED]> wrote:

  

Dr. David Alan Gilbert wrote:
...

Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.

Note that John Johansen is also interested in allowing non-privileged
users to manipulate AppArmor policy, but his view was to only allow a
non-privileged user to further tighten the profile on a program. To me,
that adds complexity with not much value, but if lots of users want it,
then I'm wrong :)



Now this is getting interesting. It looks to me as if you've implemented
a mandatory access control scheme that some people would like to be able
to use as a discretionary access control scheme. This is creepy after
seeing the MCS implementation in SELinux, which is also a DAC scheme
wacked out of a MAC scheme. Very interesting indeed.
  


This is the same sort of thing we are trying to do in SELinux with the 
policy management server 
, 
ofcourse the policy management server enforces SELinux policy on what 
can be changed and what can't. We devised a scheme to allow the policy 
to become more restrictive without being able to change the policy 
'intent' using a type hierarchy.


In fact I was talking to a coworker today about how this could be done 
with smack, using the same kind of hierarchy and allowing unprivileged 
users (eg., those without MAC_OVERRIDE) to create new smack labels 
'under' their own which would be restricted. This is interesting because 
of the ability to create new smack domains on the fly but since only 
privileged users can do it it is of limited use. Imagine if a user could 
create a new domain for their webbrowser or anything else they care to. 
Since they can't add rules to the policy it would effectively just be a 
user sandbox, an interesting use indeed.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Crispin Cowan]

Alan Cox wrote:
>> but how can the system know if the directory the user wants to add is 
>> reasonable or not? what if the user says they want to store their 
>> documents in /etc?
>> 
> A more clear example is wanting to wrap a specific tool with temporary
> rules. Those rules would depend on the exact file being edited at this
> moment - something root cannot know in advance
> (although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
> mv it back might work 8))
>   
If you have unconfined root privilege on an AppArmor box, then setting
up a temporary profile is trivial. As Alan suggests, you could just have
a standard profile for /home/crispin/bin/foo and fun with mv would
switch programs in and out of it. Or for more control, just draft a new
policy and load it; it just takes a few seconds to cp the profile for
something else and edit it a bit, and then load it.

The big difference between the former and latter is that the former is
inflexible (it either works or it doesn't) and the latter requires
privilege.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Crispin Cowan]

Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>   
>> I mostly don't see this as a serious limitation, because almost everyone
>> has their own workstation, and thus has root on that workstation. There
>> are 2 major exceptions:
>>
>> * Schools, where the "workstations" are thin client X terminals and
>>   everyone is logged into a giant shared machine. Sorry, AppArmor is
>>   not a good choice for that environment, but it is a pretty scarce
>>   environment.
>> * Enterprises, where workers get their own workstation, but they
>>   don't get root. Well, the reason the worker doesn't get root is
>>   the enterprise doesn't trust them with it, and so not letting them
>>   edit security policy is probably a good idea.
>> 
> I don't actually see your distinction here between those two environments;
> why does it matter if there is one non-priveliged user or many?
>   
Because it is easier to solve if there is only one non-privileged user:
you just give them privilege (fun with chmod and sudo) to edit the
system policies, and you're done (assuming you are happy allowing the
non-privileged user to edit policy at all).

If there are lots of non-privileged users sharing a computer, then I
submit that solutions are either insecure, intractable, or purely
restrictive.

>> Can you explain why you want a non-privileged user to be able to edit
>> policy? I would like to better understand the problem here.
>> 
> I think it might depend on how strict the users starting point is;
> you could say:
>1 This document editor can read and write any part of the users home
>  directory other than the . files.
>
> or you could say:
>2 This document editor can read any files but only write to the
>  'Documents directory'.
>
> If the adminisrator set something up with (2) as the starting point it
> would seem reasonable for the user to be able to add the ability to edit
> documents in extra directories for their style of organising documents
> they work on; but they would be restricted in what they could add
> so that they couldn't add the ability to write to their settings
> files.
>   
Ok, I can see where that would be useful in theory. But solving it is
VERY hard in practice, and AppArmor is not attempting to address this
problem of user extensibility of mandatory access controls.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Bodo Eggert]

Rogelio M. Serrano Jr. <[EMAIL PROTECTED]> wrote:
> Dr. David Alan Gilbert wrote:

>> Allowing a user to tweak (under constraints) their settings might allow
>> them to do something like create two mozilla profiles which are isolated
>> from each other, so that the profile they use for general web surfing
>> is isolated from the one they use for online banking.
>>
>>   
> Doesnt this allow the user to shoot their own foot? The exact thing
> mandatory access control are supposed to prevent?

cat `which mozilla` > ~/bin/mymozilla; chmod +x ~/bin/mozilla; mymozilla

Unless you lock down the system to a state where it's barely usable, MAC
isn't going to protect you from shooting your own feet. But having more
restricted roles and a safe way of activating them (as in "damn obvious
if or if not this role is active"), you can have e.g. one mozilla for
banking and one for pr0n.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Rob Meijer]

On Sat, November 10, 2007 22:04, Andi Kleen wrote:
> Crispin Cowan <[EMAIL PROTECTED]> writes:
>
> The document should be a good base for a merge.
>
>> * A confined process can operate on a file descriptor passed to it
>>   by an unconfined process, even if it manipulates a file not in the
>>   confined process's profile. To block this attack, confine the
>>   process that passed the file descriptor.
>
> That is the only thing that tripped me up a bit while reading the
> document.
> Can you expand a bit on the reasons why the fd is not rechecked in
> the context of the target process? Best do it in a new version of the
> document.

You must try to considder what could actualy be a valid reason for
re-checking here, and what it could accomplish.
If the unconfined process A is in 'full communication' with the unconfined
process B and wants B to have the 'authority' to do anything with file C
that it can do, there is no way of stopping A from doing so.
Stopping A from communicating its 'permission' to do so would thus be
useless for that purpose. The only way of stopping A from comminucating
its authority with A is stopping A from communicating with B period.

Ones you accept that trying to stop delegation of authority by stopping
delegation of permission is useless, you can see that ther are major
advantages with respect to allowing a process with least authority, if
you actualy 'accomodate' the delegation of authority.

This is the main reason why I actualy feel strongly that a more extended
set of delegation possibilities (both of ambient and object capabilities)
would be complementary to AppArmor, in that it would allow the convenience
of defining the lower bound of priviledges to a delegation based scheme,
while allowing at the same time a 'thin profile' for OC aware programs.

Rob J Meijer

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Rogelio M. Serrano Jr.]

Dr. David Alan Gilbert wrote:
>
>
> Allowing a user to tweak (under constraints) their settings might allow
> them to do something like create two mozilla profiles which are isolated
> from each other, so that the profile they use for general web surfing
> is isolated from the one they use for online banking.
>
>   
Doesnt this allow the user to shoot their own foot? The exact thing
mandatory access control are supposed to prevent?

> Dave
>   


-- 
Democracy is about two wolves and a sheep deciding what to eat for dinner.

begin:vcard
fn:Rogelio M. Serrano Jr
n:M. Serrano Jr;Rogelio
org:SMSG Communications Philippines;Technical Department
adr:;;Republic of the Philippines
email;internet:[EMAIL PROTECTED]
title:Programmer
tel;work:+6327534145
tel;home:+6329527026
tel;cell:+639209202267
x-mozilla-html:FALSE
version:2.1
end:vcard



signature.asc
Description: OpenPGP digital signature

Re: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, John Johansen wrote:


On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:

On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:



Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online banking.


the model of being able to add restrictions would still handle this. make
two shell scripts (one to start each browser profile) and set the AA policy
for these scripts to only have access to the appropriate directories.


yes you could do this, though I tend to want it just so I can control
which of my files firefox should be able to touch, without messing
up system policy.


right, I was showing how you could easily create two different firefox 
browsers being able to access different things, and how it could be done 
with user-based policies that tighten restrictions only (which are being 
considered)


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
>



>
> a question for Crispin,
>   is there a wildcard replacement for username? so that you could grant 
> permission to /home/$user/.mozilla.. and grant each user access to only 
> their own stuff? I realize that in this particular example the underlying 
> DAC will handle it, but I can see other cases where people may want to have 
> users more intermixed (say webserver files or directories for example)
>
A variable no.  But the current iteration does allow specifying permissions
for files that are owned by the user.  The method to do so has been
changed from the current posting and may change again as their is some
debate as to how best express this.

So system policy can express something similar by doing

owner rw @{HOME}/.mozilla,

where @{HOME} is a user side variable that gets expanded into the
locations of the systems home directories.

>> Allowing a user to tweak (under constraints) their settings might allow
>> them to do something like create two mozilla profiles which are isolated
>> from each other, so that the profile they use for general web surfing
>> is isolated from the one they use for online banking.
>
> the model of being able to add restrictions would still handle this. make 
> two shell scripts (one to start each browser profile) and set the AA policy 
> for these scripts to only have access to the appropriate directories.
>
yes you could do this, though I tend to want it just so I can control
which of my files firefox should be able to touch, without messing
up system policy.


pgpkawNwaiQ3a.pgp
Description: PGP signature

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 05:27:51PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
>
>>> but how can the system know if the directory the user wants to add is
>>> reasonable or not? what if the user says they want to store their
>>> documents in /etc?
>>
>> A more clear example is wanting to wrap a specific tool with temporary
>> rules. Those rules would depend on the exact file being edited at this
>> moment - something root cannot know in advance
>> (although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
>> mv it back might work 8))
>
> the mechanism being desired was that the system administrator would setup a 
> restrictive policy and a user who wanted a more permissive policy would 
> have the ability to make it more permissive.
>
> this sort of thing is a disaster waiting to happen.
>
yep

> however, if App Armor sets things up so that there can be a system policy 
> that users cannot touch, but users can have a secondary policy that layers 
> over the system one to restrict things further it could be safe.
>
> if a sysadmin wants to have 'soft' and 'hard' limits of what a user can do, 
> they could put the 'hard' limits in the system policy (and the users 
> _cannot_ violate these limits), and then set the 'soft' limits in the users 
> default setup (similar to how .profile is set by default). if a user wants 
> to make things less restrictive they could edit or remove the per-user 
> policy, but would still not be able to violate the system policy.
>
> however, while this seems attractive, I'm not sure that madness isn't down 
> the road a little bit. since the users policy would only apply to 
> themselves, you have the situation that (DAC permissions permitting) the 
> files are available to other confined processes becouse they are running as 
> other users. this sort of thing will surprise people if the explinations 
> aren't done very carefully.
>
yes, the devil is in the details.


pgpUZ46iTW7DR.pgp
Description: PGP signature

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 06:17:30PM -0800, Casey Schaufler wrote:
> 
> --- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> 
> > Dr. David Alan Gilbert wrote:
> > ...
> >
> > Can you explain why you want a non-privileged user to be able to edit
> > policy? I would like to better understand the problem here.
> > 
> > Note that John Johansen is also interested in allowing non-privileged
> > users to manipulate AppArmor policy, but his view was to only allow a
> > non-privileged user to further tighten the profile on a program. To me,
> > that adds complexity with not much value, but if lots of users want it,
> > then I'm wrong :)
> 
> Now this is getting interesting. It looks to me as if you've implemented
> a mandatory access control scheme that some people would like to be able
> to use as a discretionary access control scheme. This is creepy after
> seeing the MCS implementation in SELinux, which is also a DAC scheme
> wacked out of a MAC scheme. Very interesting indeed.
> 
hehe perhaps.  There are lots of issues involved with doing something
like this and there are more important issues to address first.
I also don't see it so much of a DAC scheme as a user defining a MAC
for their own processes they don't trust.  An application so confined
would not have the ability to change its confinement.


pgpa6YsxZ8sSj.pgp
Description: PGP signature

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 01:28:25PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Andi Kleen wrote:
>
>> Crispin Cowan <[EMAIL PROTECTED]> writes:
>>
>> The document should be a good base for a merge.
>>
>>> * A confined process can operate on a file descriptor passed to it
>>>   by an unconfined process, even if it manipulates a file not in the
>>>   confined process's profile. To block this attack, confine the
>>>   process that passed the file descriptor.
>>
>> That is the only thing that tripped me up a bit while reading the 
>> document.
>> Can you expand a bit on the reasons why the fd is not rechecked in
>> the context of the target process? Best do it in a new version of the
>> document.
>
> from prior discussions I understand that the problem is that it's not easy 
> (or nessasarily possible) to figure out the path to the fd, so what do you 
> check?
>
> if the file has been removed there _is_ no path to the fd.
>
> with hard links there could be many paths to the fd, the only way to find 
> them would be to search the entire filesystem.
>
> as a result App Armor has decided not to try and address this, but is 
> documenting it as a limitation.
>
Actually no.  The unconfined fd being passed in is explicitly different
than and fd being passed between two confined processes.  In the
unconfined parent passing an fd into a confined child the fd isn't
reevaluated.  In the case of confined parent to confined child the
the struct file is reevaluated.

As to the implementation issue of revalidation.  The path name to file can
be found as struct file stores both the vfsmnt and dentry.  With that said
there are a couple cases where the pathname can't be found.
- the file has been deleted
- the path has become disconnected.

In short under file revalidation deleted file are given a pass and
disconnected files fail.

For a more in depth explanation look at
http://forgeftp.novell.com//apparmor/LKML_Submission-Oct-07/techdoc.pdf

regards
john



pgpGhNMsSWIF9.pgp
Description: PGP signature

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 01:24:46PM -0800, Crispin Cowan wrote:
> Andi Kleen wrote:
> > Crispin Cowan <[EMAIL PROTECTED]> writes:
> >
> > The document should be a good base for a merge.
> >
> >   
> >> * A confined process can operate on a file descriptor passed to it
> >>   by an unconfined process, even if it manipulates a file not in the
> >>   confined process's profile. To block this attack, confine the
> >>   process that passed the file descriptor.
> >> 
> >
> > That is the only thing that tripped me up a bit while reading the document.
> > Can you expand a bit on the reasons why the fd is not rechecked in
> > the context of the target process? Best do it in a new version of the
> > document.
> >   
> The reason is a disgusting implementation problem, so instead of going
> into lots of detail, I just disclaimed it.
> 
Well perhaps a little disgusting but it isn't the reason.  We discussed
this on the rewrite with the vfsmnt passed through the vfs.  We could
have changed the implementation but in the end decided to to leave it
in place for the time being.

> The excuse :) is that UNIX/Linux already has an object-capability
> orientation with respect to passing file descriptors around; you can
> pass an FD to a process that doesn't have access to the file, and DAC
> (user ownership & such) won't check it either.
> 
yep, the discussion really did come down to object capability and
unconfined processes.

> This aspect of the semantics is not my favorite, but it is at least
> consistent with the AppArmor view that unconfined processes can do
> absolutely anything and AppArmor won't try to stop them.
> 
and the the other major point surfaces

> The actual reason: FDs that are passed from some other *confined*
> process actually are checked, because the FD has data structures on it
> that we can use to hook for checking. The problem is that an FD from a
> completely unconfined process has no such data structures. To fix this,
> we would have to check access on every single read and write, and that
> would make performance suck.
> 
Not so, we can add that, and I have prototyped code to do so.  The issue
really is about how unconfined processes should interact with confined
processes.

> If there is a clean way to close this issue, I would be interested.
> 
What is considered a clean way to change this has been an on and
off again discussion, its been about 9 months since we last discussed
it so I am not surprised Crispin has paged it out.

The issue really does come down to how to express the interaction of
confined and unconfined tasks in policy.  The discussion always comes
back to object capabilities, unconfined's behavior, and how to
best express it.

> On the other hand, there is a fairly passionate community of Object
> Capability fans who really want access rights to be delegable, and the
> other way to go is to remove all checking on passed FDs.
> 
> There are advantages to going both ways, and I don't believe that
> AppArmor is locked in stone, so either one could be chosen in the
> future. See this interesting thread on LSM
> http://marc.info/?t=11946492933&r=1&w=2
> 
No it isn't, the behavior was intended to be revisited when we
had IPC, and or a prototype for expressing which file objects can be
passed.


pgpCgVzBvhSmi.pgp
Description: PGP signature

Re: AppArmor Security Goal

[Casey Schaufler]

--- Crispin Cowan <[EMAIL PROTECTED]> wrote:

> Dr. David Alan Gilbert wrote:
> ...
>
> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.
> 
> Note that John Johansen is also interested in allowing non-privileged
> users to manipulate AppArmor policy, but his view was to only allow a
> non-privileged user to further tighten the profile on a program. To me,
> that adds complexity with not much value, but if lots of users want it,
> then I'm wrong :)

Now this is getting interesting. It looks to me as if you've implemented
a mandatory access control scheme that some people would like to be able
to use as a discretionary access control scheme. This is creepy after
seeing the MCS implementation in SELinux, which is also a DAC scheme
wacked out of a MAC scheme. Very interesting indeed.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, Alan Cox wrote:


but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?


A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the exact file being edited at this
moment - something root cannot know in advance
(although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
mv it back might work 8))


the mechanism being desired was that the system administrator would setup 
a restrictive policy and a user who wanted a more permissive policy would 
have the ability to make it more permissive.


this sort of thing is a disaster waiting to happen.

however, if App Armor sets things up so that there can be a system policy 
that users cannot touch, but users can have a secondary policy that layers 
over the system one to restrict things further it could be safe.


if a sysadmin wants to have 'soft' and 'hard' limits of what a user can 
do, they could put the 'hard' limits in the system policy (and the users 
_cannot_ violate these limits), and then set the 'soft' limits in the 
users default setup (similar to how .profile is set by default). if a user 
wants to make things less restrictive they could edit or remove the 
per-user policy, but would still not be able to violate the system policy.


however, while this seems attractive, I'm not sure that madness isn't down 
the road a little bit. since the users policy would only apply to 
themselves, you have the situation that (DAC permissions permitting) the 
files are available to other confined processes becouse they are running 
as other users. this sort of thing will surprise people if the 
explinations aren't done very carefully.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Alan Cox]

> but how can the system know if the directory the user wants to add is 
> reasonable or not? what if the user says they want to store their 
> documents in /etc?

A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the exact file being edited at this
moment - something root cannot know in advance
(although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
mv it back might work 8))

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Alan Cox]

> I submit that the AppArmor model is valid, even if it totally failed all
> of David Gilbert's questions (I think AppArmor can actually provide
> about half of what he asked for).

The model looks valid. I have difficulty constructing many scenarios
where its useful but it appears valid providing you can tightly control
file renaming, which is very very questionable.

There are also some very awkward path based issues around shared file
objects (your controlling tty and TIOCSTI for one) that I need to look at
the code for once the VFS stuff is sorted and its likely to get merged.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Dr. David Alan Gilbert]

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
 That I wrote:
> >If the adminisrator set something up with (2) as the starting point it
> >would seem reasonable for the user to be able to add the ability to edit
> >documents in extra directories for their style of organising documents
> >they work on; but they would be restricted in what they could add
> >so that they couldn't add the ability to write to their settings
> >files.
> 
> but how can the system know if the directory the user wants to add is 
> reasonable or not? what if the user says they want to store their 
> documents in /etc?

I was assuming that in a system where the user can add stuff to
the profile the administrator would be able to either grant or exclude
paths that the user was able to add.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:


Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.


I think it might depend on how strict the users starting point is;
you could say:
  1 This document editor can read and write any part of the users home
directory other than the . files.

or you could say:
  2 This document editor can read any files but only write to the
'Documents directory'.

If the adminisrator set something up with (2) as the starting point it
would seem reasonable for the user to be able to add the ability to edit
documents in extra directories for their style of organising documents
they work on; but they would be restricted in what they could add
so that they couldn't add the ability to write to their settings
files.


but how can the system know if the directory the user wants to add is 
reasonable or not? what if the user says they want to store their 
documents in /etc?






AppArmor will let you do that; most of the work is in splitting the
application. If you can get e.g. Firefox to use a separate process that
it exec's for editing your preferences, then AppArmor can confine that
helper app with a different policy than Firefox itself, including
granting the helper write permission to the config directory.


Yes, and designing the app so that it's filenames are predictable;
firefox has a fun habit of using randomly named profile directories.


You just glob that directory, so the rule would look like:

/home/*/.mozilla/default/*/prefs.js rw,

if you wanted it to be a generic policy for all users. If you want a
tighter policy for your workstation, then it might look like

/home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,

hard-coding both your username and the random directory name that
Mozilla chose.


a question for Crispin,
  is there a wildcard replacement for username? so that you could grant 
permission to /home/$user/.mozilla.. and grant each user access to 
only their own stuff? I realize that in this particular example the 
underlying DAC will handle it, but I can see other cases where people may 
want to have users more intermixed (say webserver files or directories for 
example)



Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online banking.


the model of being able to add restrictions would still handle this. make 
two shell scripts (one to start each browser profile) and set the AA 
policy for these scripts to only have access to the appropriate 
directories.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Dr. David Alan Gilbert]

* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >   
> >> I don't get the problem: if you want your web browser to be able to
> >> access where you commonly store your documents, then give it that
> >> permission. The above rule says that your web browser doesn't get to go
> >> change AppArmor policy on its own.
> >> 
> > But can I as a non-privileged user say which directories I want it to
> > be able to access?
> >   
> No, you have to be privileged (root) to edit security policy and to
> reload policy.

OK, that's what I thought you were saying.

> I mostly don't see this as a serious limitation, because almost everyone
> has their own workstation, and thus has root on that workstation. There
> are 2 major exceptions:
> 
> * Schools, where the "workstations" are thin client X terminals and
>   everyone is logged into a giant shared machine. Sorry, AppArmor is
>   not a good choice for that environment, but it is a pretty scarce
>   environment.
> * Enterprises, where workers get their own workstation, but they
>   don't get root. Well, the reason the worker doesn't get root is
>   the enterprise doesn't trust them with it, and so not letting them
>   edit security policy is probably a good idea.

I don't actually see your distinction here between those two environments;
why does it matter if there is one non-priveliged user or many?

> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.

I think it might depend on how strict the users starting point is;
you could say:
   1 This document editor can read and write any part of the users home
 directory other than the . files.

or you could say:
   2 This document editor can read any files but only write to the
 'Documents directory'.

If the adminisrator set something up with (2) as the starting point it
would seem reasonable for the user to be able to add the ability to edit
documents in extra directories for their style of organising documents
they work on; but they would be restricted in what they could add
so that they couldn't add the ability to write to their settings
files.

> Note that John Johansen is also interested in allowing non-privileged
> users to manipulate AppArmor policy, but his view was to only allow a
> non-privileged user to further tighten the profile on a program. To me,
> that adds complexity with not much value, but if lots of users want it,
> then I'm wrong :)

Well that would correspond to case (1) above; where the global settings
by an administrator were fairly open and then it was up to the user to
restrict programs more if they knew they always stored their documents
in one place; I was working on the basis of allowing applications
access to very little until you said it was alright - since most users
wouldn't actually bother up setting up more restrictive access.


> How to usefully confine an office suite like OpenOffice is current work
> at Mercenary Linux. We think we have a solution that is just AppArmor
> policy, without having to do any feature enhancements.

That solution might answer my questions anyway.



> >> AppArmor will let you do that; most of the work is in splitting the
> >> application. If you can get e.g. Firefox to use a separate process that
> >> it exec's for editing your preferences, then AppArmor can confine that
> >> helper app with a different policy than Firefox itself, including
> >> granting the helper write permission to the config directory.
> >> 
> > Yes, and designing the app so that it's filenames are predictable;
> > firefox has a fun habit of using randomly named profile directories.
> >   
> You just glob that directory, so the rule would look like:
> 
> /home/*/.mozilla/default/*/prefs.js rw,
> 
> if you wanted it to be a generic policy for all users. If you want a
> tighter policy for your workstation, then it might look like
> 
> /home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,
> 
> hard-coding both your username and the random directory name that
> Mozilla chose.

Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online banking.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Crispin Cowan]

Alan Cox wrote:
>> Can you explain why you want a non-privileged user to be able to edit
>> policy? I would like to better understand the problem here.
>> 
> Because root doesn't trust users who in turn may not trust apps they run
> or wish to control things. I don't see a problem with that viewpoint in
> terms of forbidding things providing the user (or process tree) does not
> get to undo rules merely add more restrictions.
>   
Do you mean that the OS privilege of "uid 0" does not trust
non-privileged users? Or you mean that the human in charge of root on
the box does not trust the human who owns the account "alice" on the box?

In the case of the former, this is exactly why AppArmor does not let
non-privileged users edit security policy. SELinux, SMACK, LIDS, etc.
also all treat manipulating policy as privileged.

In the case of the latter, my main claim is that such circumstances are
rare, because most users have their own personal workstation. Of course
there are exceptions where people are using a multi-user host, and I'm
not saying that there is anything wrong with that, just that AppArmor is
not particularly good at supporting that environment.

I know that multi-user machines is the classic UNIX environment, but
that model has slowly faded away and is little used any more, so
AppArmor made a trade-off for simplicity at the expense of supporting
this use case.

User-extensible security policy is a hard problem, and AppArmor does not
attempt to solve it.

>> non-privileged user to further tighten the profile on a program. To me,
>> that adds complexity with not much value, but if lots of users want it,
>> then I'm wrong :)
>> 
> Assuming you have any value in the first place, which is another topic, I
> can see value for this in all the security models.
>   
There is value in most features, and the question is whether the feature
pays its freight, does the value exceed the cost? AppArmor is
particularly sensitive to cost/benefit ratios, because much of
AppArmor's value is its simplicity, so there is a naturally high barrier
to adding complicating features to AppArmor.

All of this is valid discussion for how AppArmor might be improved, but
is far, far removed from the dual question that Arjan posed:

* Is the model valid? Not "is it exactly what I want?" but merely
  "is it non-silly, such that clearly it provides value to some users?"
* Does the code live up to the model?

I submit that the AppArmor model is valid, even if it totally failed all
of David Gilbert's questions (I think AppArmor can actually provide
about half of what he asked for).

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Alan Cox]

> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.

Because root doesn't trust users who in turn may not trust apps they run
or wish to control things. I don't see a problem with that viewpoint in
terms of forbidding things providing the user (or process tree) does not
get to undo rules merely add more restrictions.

> non-privileged user to further tighten the profile on a program. To me,
> that adds complexity with not much value, but if lots of users want it,
> then I'm wrong :)

Assuming you have any value in the first place, which is another topic, I
can see value for this in all the security models.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Crispin Cowan]

Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>   
>> I don't get the problem: if you want your web browser to be able to
>> access where you commonly store your documents, then give it that
>> permission. The above rule says that your web browser doesn't get to go
>> change AppArmor policy on its own.
>> 
> But can I as a non-privileged user say which directories I want it to
> be able to access?
>   
No, you have to be privileged (root) to edit security policy and to
reload policy.

I mostly don't see this as a serious limitation, because almost everyone
has their own workstation, and thus has root on that workstation. There
are 2 major exceptions:

* Schools, where the "workstations" are thin client X terminals and
  everyone is logged into a giant shared machine. Sorry, AppArmor is
  not a good choice for that environment, but it is a pretty scarce
  environment.
* Enterprises, where workers get their own workstation, but they
  don't get root. Well, the reason the worker doesn't get root is
  the enterprise doesn't trust them with it, and so not letting them
  edit security policy is probably a good idea.

Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.

Note that John Johansen is also interested in allowing non-privileged
users to manipulate AppArmor policy, but his view was to only allow a
non-privileged user to further tighten the profile on a program. To me,
that adds complexity with not much value, but if lots of users want it,
then I'm wrong :)

>> I have serious doubts about the utility of restricting a text editor.
>> You nominally want to be able to edit any file on the system, so
>> confining it would be fairly meaningless.
>> 
> Text editor probably true; but I'm thinking here more of OpenOffice
> and the like; there have been plenty of document carried malware in the
> past.
>   
How to usefully confine an office suite like OpenOffice is current work
at Mercenary Linux. We think we have a solution that is just AppArmor
policy, without having to do any feature enhancements.

>>> Similarly I'd like to be able to split applications so that
>>> the 'preferences' editing facilities are done by separate
>>> envrionments so that there is no way that a fault in parsing
>>> external data could edit the config (e.g. change home page or
>>> proxy in a browser or default document in an editor).  
>>>   
>> AppArmor will let you do that; most of the work is in splitting the
>> application. If you can get e.g. Firefox to use a separate process that
>> it exec's for editing your preferences, then AppArmor can confine that
>> helper app with a different policy than Firefox itself, including
>> granting the helper write permission to the config directory.
>> 
> Yes, and designing the app so that it's filenames are predictable;
> firefox has a fun habit of using randomly named profile directories.
>   
You just glob that directory, so the rule would look like:

/home/*/.mozilla/default/*/prefs.js rw,

if you wanted it to be a generic policy for all users. If you want a
tighter policy for your workstation, then it might look like

/home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,

hard-coding both your username and the random directory name that
Mozilla chose.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Dr. David Alan Gilbert]

* Crispin Cowan ([EMAIL PROTECTED]) wrote:



> * Manipulating AppArmor policy requires being both root privileged
>   and not being confined by AppArmor, thus there is explicitly no
>   capability for non-privileged users to change AppArmor policy.

It's a pity that there is no way to do this; it would be nice to restrict
web browsers, document editors etc but allow them
to access the places you commonly store documents etc.

Similarly I'd like to be able to split applications so that
the 'preferences' editing facilities are done by separate
envrionments so that there is no way that a fault in parsing
external data could edit the config (e.g. change home page or
proxy in a browser or default document in an editor).

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Dr. David Alan Gilbert]

* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >  >> * Manipulating AppArmor policy requires being both root privileged
> >>   and not being confined by AppArmor, thus there is explicitly no
> >>   capability for non-privileged users to change AppArmor policy.
> >> 
> > It's a pity that there is no way to do this; it would be nice to restrict
> > web browsers, document editors etc but allow them
> > to access the places you commonly store documents etc.
> >   
> I don't get the problem: if you want your web browser to be able to
> access where you commonly store your documents, then give it that
> permission. The above rule says that your web browser doesn't get to go
> change AppArmor policy on its own.

But can I as a non-privileged user say which directories I want it to
be able to access?

> I have serious doubts about the utility of restricting a text editor.
> You nominally want to be able to edit any file on the system, so
> confining it would be fairly meaningless.

Text editor probably true; but I'm thinking here more of OpenOffice
and the like; there have been plenty of document carried malware in the
past.

> > Similarly I'd like to be able to split applications so that
> > the 'preferences' editing facilities are done by separate
> > envrionments so that there is no way that a fault in parsing
> > external data could edit the config (e.g. change home page or
> > proxy in a browser or default document in an editor).
> >   
> AppArmor will let you do that; most of the work is in splitting the
> application. If you can get e.g. Firefox to use a separate process that
> it exec's for editing your preferences, then AppArmor can confine that
> helper app with a different policy than Firefox itself, including
> granting the helper write permission to the config directory.

Yes, and designing the app so that it's filenames are predictable;
firefox has a fun habit of using randomly named profile directories.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Crispin Cowan]

Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> > * Manipulating AppArmor policy requires being both root privileged
>>   and not being confined by AppArmor, thus there is explicitly no
>>   capability for non-privileged users to change AppArmor policy.
>> 
> It's a pity that there is no way to do this; it would be nice to restrict
> web browsers, document editors etc but allow them
> to access the places you commonly store documents etc.
>   
I don't get the problem: if you want your web browser to be able to
access where you commonly store your documents, then give it that
permission. The above rule says that your web browser doesn't get to go
change AppArmor policy on its own.

I have serious doubts about the utility of restricting a text editor.
You nominally want to be able to edit any file on the system, so
confining it would be fairly meaningless.

> Similarly I'd like to be able to split applications so that
> the 'preferences' editing facilities are done by separate
> envrionments so that there is no way that a fault in parsing
> external data could edit the config (e.g. change home page or
> proxy in a browser or default document in an editor).
>   
AppArmor will let you do that; most of the work is in splitting the
application. If you can get e.g. Firefox to use a separate process that
it exec's for editing your preferences, then AppArmor can confine that
helper app with a different policy than Firefox itself, including
granting the helper write permission to the config directory.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Crispin Cowan]

Andi Kleen wrote:
> Crispin Cowan <[EMAIL PROTECTED]> writes:
>
> The document should be a good base for a merge.
>
>   
>> * A confined process can operate on a file descriptor passed to it
>>   by an unconfined process, even if it manipulates a file not in the
>>   confined process's profile. To block this attack, confine the
>>   process that passed the file descriptor.
>> 
>
> That is the only thing that tripped me up a bit while reading the document.
> Can you expand a bit on the reasons why the fd is not rechecked in
> the context of the target process? Best do it in a new version of the
> document.
>   
The reason is a disgusting implementation problem, so instead of going
into lots of detail, I just disclaimed it.

The excuse :) is that UNIX/Linux already has an object-capability
orientation with respect to passing file descriptors around; you can
pass an FD to a process that doesn't have access to the file, and DAC
(user ownership & such) won't check it either.

This aspect of the semantics is not my favorite, but it is at least
consistent with the AppArmor view that unconfined processes can do
absolutely anything and AppArmor won't try to stop them.

The actual reason: FDs that are passed from some other *confined*
process actually are checked, because the FD has data structures on it
that we can use to hook for checking. The problem is that an FD from a
completely unconfined process has no such data structures. To fix this,
we would have to check access on every single read and write, and that
would make performance suck.

If there is a clean way to close this issue, I would be interested.

On the other hand, there is a fairly passionate community of Object
Capability fans who really want access rights to be delegable, and the
other way to go is to remove all checking on passed FDs.

There are advantages to going both ways, and I don't believe that
AppArmor is locked in stone, so either one could be chosen in the
future. See this interesting thread on LSM
http://marc.info/?t=11946492933&r=1&w=2

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, Andi Kleen wrote:


Crispin Cowan <[EMAIL PROTECTED]> writes:

The document should be a good base for a merge.


* A confined process can operate on a file descriptor passed to it
  by an unconfined process, even if it manipulates a file not in the
  confined process's profile. To block this attack, confine the
  process that passed the file descriptor.


That is the only thing that tripped me up a bit while reading the document.
Can you expand a bit on the reasons why the fd is not rechecked in
the context of the target process? Best do it in a new version of the
document.


from prior discussions I understand that the problem is that it's not easy 
(or nessasarily possible) to figure out the path to the fd, so what do you 
check?


if the file has been removed there _is_ no path to the fd.

with hard links there could be many paths to the fd, the only way to find 
them would be to search the entire filesystem.


as a result App Armor has decided not to try and address this, but is 
documenting it as a limitation.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Andi Kleen]

Crispin Cowan <[EMAIL PROTECTED]> writes:

The document should be a good base for a merge.

> * A confined process can operate on a file descriptor passed to it
>   by an unconfined process, even if it manipulates a file not in the
>   confined process's profile. To block this attack, confine the
>   process that passed the file descriptor.

That is the only thing that tripped me up a bit while reading the document.
Can you expand a bit on the reasons why the fd is not rechecked in
the context of the target process? Best do it in a new version of the
document.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

AppArmor Security Goal

[Crispin Cowan]

re-sent due to a typo in addressing.

AppArmor Security Goal
Crispin Cowan, PhD
MercenaryLinux.com

This document is intended to specify the security goal that AppArmor is
intended to achieve, so that users can evaluate whether AppArmor will
meet their needs, and kernel developers can evaluate whether AppArmor is
living up to its claims. This document is *not* a general purpose
explanation of how AppArmor works, nor is it an explanation for why one
might want to use AppArmor rather than some other system.

AppArmor is intended to protect systems from attackers exploiting
vulnerabilities in applications that the system hosts. The threat is
that an attacker can cause a vulnerable application to do something
unexpected and undesirable. AppArmor addresses this threat by confining
the application to access only the resources it needs to access to
execute properly, effectively imposing "least privilege" execution on
the application.

Applications have access to a number of resources including files,
interprocess communication, networking, capabilities, and execution of
other applications. The purpose of least privilege is to bound the
damage that a malicious user or code can do by removing access to all
resources that the application does not need for its intended function.
For instance, a policy for a web server might grant read only access to
most web documents, preventing an attacker who can corrupt the web
server from defacing the web pages.

An "application" is one or more related processes performing a function,
e.g. the gang of processes that constitute an Apache web server, or a
Postfix mail server. AppArmor *only* confines processes that the
AppArmor policy says it should confine, and other processes are
permitted to do anything that DAC permits. This is sometimes known as a
targeted security policy.

AppArmor does not provide a "default" policy that applies to all
processes. So to defend an entire host, you have to piece-wise confine
each process that is exposed to potential attack. For instance, to
defend a system against network attack, place AppArmor profiles around
every application that accesses the network. This limits the damage a
network attacker can do to the file system to only those files granted
by the profiles for the network-available applications. Similarly, to
defend a system against attack from the console, place AppArmor profiles
around every application that accessed the keyboard and mouse. The
system is "defended" in that the worst the attacker can do to corrupt
the system is limited to the transitive closure of what the confined
processes are allowed to access.

AppArmor currently mediates access to files, ability to use POSIX.1e
Capabilities, and coarse-grained control on network access. This is
sufficient to prevent a confined process from *directly* corrupting the
file system. It is not sufficient to prevent a confined process from
*indirectly* corrupting the system by influencing some other process to
do the dirty deed. But to do so requires a complicit process that can be
manipulated through another channel such as IPC. A "complicit" process
is either a malicious process the attacker somehow got control of, or is
a process that is actively listening to IPC of some kind and can be
corrupted via IPC.

The only IPC that AppArmor mediates is access to named sockets, FIFOs,
etc. that appear in the file system name space, a side effect of
AppArmor's file access mediation. Future versions of AppArmor will
mediate more resources, including finer grained network access controls,
and controls on various forms of IPC.

AppArmor specifies the programs to be confined and the resources they
can access in a syntax similar to how users are accustomed to accessing
those resources. So file access controls are specified using absolute
paths with respect to the name space the process is in. POSIX.1e
capabilities are specified by name. Network access controls currently
are specified by simply naming the protocol that can be used e.g. tcp,
udp, and in the future will be more general, resembling firewall rules.

Thus the AppArmor security goal should be considered piecewise from the
point of view of a single confined process: that process should only be
able to access the resources specified in its profile:

* can only access files that are reachable in its name space by path
  names matching its profile, and only with the permitted modes:
  read, append, write, memory map, execute, and link
* can only use the POSIX.1e capabilities listed in the profile
* can only perform the network operations listed in the profile

Security issues that AppArmor explicitly does *not* address:

* Processes that are not confined by AppArmor are not restricted in
  any way by AppArmor. If an unconfined process is considered an
  unacceptable threat, then confine additional applications until
  adequate security is achieved.