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.
* A process that is not permitted to directly access a resource can
influence some other process that does have access to the resource
may do so, if the "influence" is a permitted action.
* A confined process may only access a file if it has at least one
of the files aliases specified in its profile. If a file alias is
not specified in the profile then it can not be accessed by that
path. The creation of aliases needs to be tightly controlled in
confined applications, hard links creation should be limited to
provide adequate security.
* 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.
* Process activities not currently mediated by AppArmor are
permitted, e.g. confined processes can perform any IPC that DAC
permits, other than signals as mediated by CAP_KILL.
* 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.
* 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. Another process could copy a program to a
different path name and then execute it without confinement, but
the other process would have to have permission to do so in the
first place. To prevent this, confine the other process and
additional applications until adequate security is achieved.
* Mount and namespace manipulations can be used to arbitrarily
change the pathnames that files appear at, and thus completely
bypass AppArmor policy. To prevent this, processes confined by
AppArmor are currently not permitted to call mount or manipulate
name spaces at all. A future development may provide more granular
controls on mount and namespace manipulations.
* AppArmor does not slice bread, cure cancer, or bring world peace.
This list may be expanded :-)
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
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
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
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=119464929300003&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
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([email protected]) wrote:
> <snip
>> * 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
* Crispin Cowan ([email protected]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([email protected]) wrote:
> > <snip
> >> * 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 |_______/
* Crispin Cowan ([email protected]) wrote:
<snip>
> * 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 |_______/
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
> 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.
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
* 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.
<snip>
> 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.
<snip>
> >> 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 |_______/
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?
> <snip>
>
>>>> 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
* [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 |_______/
> 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
> 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))
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
--- 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]
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=119464929300003&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.
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
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.
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.
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [email protected] wrote:
> On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
>
<snip>
>
> 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.
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
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.
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
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.
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
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
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
<http://oss.tresys.com/projects/policy-server/wiki/PolicyServerDesign>,
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.
[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
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.
--- 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
> <http://oss.tresys.com/projects/policy-server/wiki/PolicyServerDesign>,
> 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]