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 poten...
[ message continues ]

Crispin Cowan <crispin@crispincowan.com> writes:
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

-

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

-

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

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
-

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

yep, the discussion really did come down to object capability and

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

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

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.

* Crispin Cowan (crispin@crispincowan.com) wrote:
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   |_______/

-

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

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
-

But can I as a non-privileged user say which directories I want it to
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
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   |_______/

-

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,

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

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
-

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

casey@schaufler-ca.com

-

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

casey@schaufler-ca.com

-

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.

I don't actually see your distinction here between those two environments;
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
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.
That solution might answer my questions anyway.
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   |_______/

-

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

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
-

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.

This is a multi-part message in MIME format.

--------------030808090109080108080209

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: quoted-printable
Doesnt this allow the user to shoot their own foot? The exact thing
--=20

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

=2E
--------------030808090109080108080209

Content-Type: text/x-vcard; charset=utf-8;

 name="rogelio.vcf"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

 filename="rogelio.vcf"
YmVnaW46dmNhcmQNCmZuOlJvZ2VsaW8gTS4gU2VycmFubyBKcg0KbjpNLiBTZXJyYW5vIEpy

O1JvZ2VsaW8NCm9yZzpTTVNHIENvbW11bmljYXRpb25zIFBoaWxpcHBpbmVzO1RlY2huaWNh

bCBEZXBhcnRtZW50DQphZHI6Ozs7Ozs7UmVwdWJsaWMgb2YgdGhlIFBoaWxpcHBpbmVzDQpl

bWFpbDtpbnRlcm5ldDpyb2dlbGlvQHNtc2dsb2JhbC5uZXQNCnRpdGxlOlByb2dyYW1tZXIN

CnRlbDt3b3JrOis2MzI3NTM0MTQ1DQp0ZWw7aG9tZTorNjMyOTUyNzAyNg0KdGVsO2NlbGw6

KzYzOTIwOTIwMjI2Nw0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnZlcnNpb246Mi4xDQplbmQ6

dmNhcmQNCg0K

--------------030808090109080108080209--

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

-

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
-

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

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

-

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
-

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

-

yes, the devil is in the details.

* david@lang.hm (david@lang.hm) wrote:
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   |_______/

-

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
Assuming you have any value in the first place, which is another topic, I

can see value for this in all the security models.
-

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

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. GP...
[ message continues ]

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

-