login
Search
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 ...
* 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
-
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. ...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 -
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 |_______/
-
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 -
* 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 |_______/ -
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 -
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 -
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 -
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 -
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--
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.
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 -
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.
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 -
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 -
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.
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
