Re: [Apparmor-dev] Re: AppArmor Security Goal
What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. Sorry have to bring this up. cgroups why not? Assign application to a cgroup that contains there filesystem access permissions. Done right this could even be stacked. Only give less access to application unless LSM particularly overrides. Comtainers allow overriding / in chroot style. This needs file or label based protection no matter the security framework. So we don't have the chroot problems of applications breaking out. Apparmors file access control features along with selinux's as a combined into a cgroup would be good. Same is required for device control. There are reasons why I keep on bring containers up it changes the model. Yes I know coming to a common agreement in these sections will not be simple. But at some point it has to be done. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Apparmor-dev] Re: AppArmor Security Goal
Rob Meijer wrote: The system is defended in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access. The damage the atacker can do would be defined by the authority not the permissions the process has. As far as I can tall, the transitive closure of permissions is precisely authority. * AppArmor confines processes if they are children of a confined process, or if the name of the exec'd child matches the name of an AppArmor profile. What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. It is deliberately unspecified in this document, because it is a matter of policy. And this item that you've excerpted is just one of a list of specific disclaimers that were put here in response to criticisms and misunderstandings of AppArmor in the past. Remember, the purpose of *this* document is to define the security goals that AppArmor has to live up to. It is fine to use it as a jumping off point for design ideas that some system might employ some day, or even proposed enhancements to AppArmor itself, but don't over-burden the security goal document, it needs to be short comprehensible. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile. To block this attack, confine the process that passed the file descriptor. This should not count as an 'attack' given that the unconfined process would either be trusted, or be mallicious and fall inside the influence of the confined process anyway. It counts as a surprising result, and so is specifically disclaimed. I can tell it is surprising, because it surprised Andi Kleen :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Apparmor-dev] Re: AppArmor Security Goal
Re-sent with proper addressing ... Rob Meijer wrote: The system is defended in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access. The damage the atacker can do would be defined by the authority not the permissions the process has. As far as I can tall, the transitive closure of permissions is precisely authority. * AppArmor confines processes if they are children of a confined process, or if the name of the exec'd child matches the name of an AppArmor profile. What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. It is deliberately unspecified in this document, because it is a matter of policy. And this item that you've excerpted is just one of a list of specific disclaimers that were put here in response to criticisms and misunderstandings of AppArmor in the past. Remember, the purpose of *this* document is to define the security goals that AppArmor has to live up to. It is fine to use it as a jumping off point for design ideas that some system might employ some day, or even proposed enhancements to AppArmor itself, but don't over-burden the security goal document, it needs to be short comprehensible. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile. To block this attack, confine the process that passed the file descriptor. This should not count as an 'attack' given that the unconfined process would either be trusted, or be mallicious and fall inside the influence of the confined process anyway. It counts as a surprising result, and so is specifically disclaimed. I can tell it is surprising, because it surprised Andi Kleen :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
Rogelio M. Serrano Jr. [EMAIL PROTECTED] wrote: Dr. David Alan Gilbert wrote: Allowing a user to tweak (under constraints) their settings might allow them to do something like create two mozilla profiles which are isolated from each other, so that the profile they use for general web surfing is isolated from the one they use for online banking. Doesnt this allow the user to shoot their own foot? The exact thing mandatory access control are supposed to prevent? cat `which mozilla` ~/bin/mymozilla; chmod +x ~/bin/mozilla; mymozilla Unless you lock down the system to a state where it's barely usable, MAC isn't going to protect you from shooting your own feet. But having more restricted roles and a safe way of activating them (as in damn obvious if or if not this role is active), you can have e.g. one mozilla for banking and one for pr0n. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: I mostly don't see this as a serious limitation, because almost everyone has their own workstation, and thus has root on that workstation. There are 2 major exceptions: * Schools, where the workstations are thin client X terminals and everyone is logged into a giant shared machine. Sorry, AppArmor is not a good choice for that environment, but it is a pretty scarce environment. * Enterprises, where workers get their own workstation, but they don't get root. Well, the reason the worker doesn't get root is the enterprise doesn't trust them with it, and so not letting them edit security policy is probably a good idea. I don't actually see your distinction here between those two environments; why does it matter if there is one non-priveliged user or many? Because it is easier to solve if there is only one non-privileged user: you just give them privilege (fun with chmod and sudo) to edit the system policies, and you're done (assuming you are happy allowing the non-privileged user to edit policy at all). If there are lots of non-privileged users sharing a computer, then I submit that solutions are either insecure, intractable, or purely restrictive. Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. I think it might depend on how strict the users starting point is; you could say: 1 This document editor can read and write any part of the users home directory other than the . files. or you could say: 2 This document editor can read any files but only write to the 'Documents directory'. If the adminisrator set something up with (2) as the starting point it would seem reasonable for the user to be able to add the ability to edit documents in extra directories for their style of organising documents they work on; but they would be restricted in what they could add so that they couldn't add the ability to write to their settings files. Ok, I can see where that would be useful in theory. But solving it is VERY hard in practice, and AppArmor is not attempting to address this problem of user extensibility of mandatory access controls. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
Alan Cox wrote: but how can the system know if the directory the user wants to add is reasonable or not? what if the user says they want to store their documents in /etc? A more clear example is wanting to wrap a specific tool with temporary rules. Those rules would depend on the exact file being edited at this moment - something root cannot know in advance (although with apparmor I guess mv $my_file apparmour_magic.name ; foo; mv it back might work 8)) If you have unconfined root privilege on an AppArmor box, then setting up a temporary profile is trivial. As Alan suggests, you could just have a standard profile for /home/crispin/bin/foo and fun with mv would switch programs in and out of it. Or for more control, just draft a new policy and load it; it just takes a few seconds to cp the profile for something else and edit it a bit, and then load it. The big difference between the former and latter is that the former is inflexible (it either works or it doesn't) and the latter requires privilege. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
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. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
[EMAIL PROTECTED] wrote: a question for Crispin, is there a wildcard replacement for username? so that you could grant permission to /home/$user/.mozilla.. and grant each user access to only their own stuff? I realize that in this particular example the underlying DAC will handle it, but I can see other cases where people may want to have users more intermixed (say webserver files or directories for example) This is possible, but tricky. There is no internal kernel data structure for a UID's home dir. That is parsable at policy load time, so we could enhance the language so that a rule of ~/.plan expanded into a special token that corresponded to some table of user home directories at the time the policy was loaded. But that is racy, as it becomes invalid if anyone's home dir moves, or any users are added or removed. Another way to do it is what JJ posted: enhance the rule language so you can have one rule for files that you own, and a different rule for files owned by others. The AppArmor community (well, JJ and I :) are debating the cost/benefit of this: is the added flexibility worth the added complexity? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
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. pgpp8MVxpLSlZ.pgp Description: PGP signature
Re: AppArmor Security Goal
--- 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] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
The system is defended in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access. The damage the atacker can do would be defined by the authority not the permissions the process has. 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. * AppArmor confines processes if they are children of a confined process, or if the name of the exec'd child matches the name of an AppArmor profile. What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. * 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 can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile. To block this attack, confine the process that passed the file descriptor. This should not count as an 'attack' given that the unconfined process would either be trusted, or be mallicious and fall inside the influence of the confined process anyway. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
Crispin Cowan [EMAIL PROTECTED] writes: The document should be a good base for a merge. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile. To block this attack, confine the process that passed the file descriptor. That is the only thing that tripped me up a bit while reading the document. Can you expand a bit on the reasons why the fd is not rechecked in the context of the target process? Best do it in a new version of the document. -Andi - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
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=11946492933r=1w=2 Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
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 - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
* 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 |___/ - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
* 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 |___/ - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
Alan Cox wrote: Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. Because root doesn't trust users who in turn may not trust apps they run or wish to control things. I don't see a problem with that viewpoint in terms of forbidding things providing the user (or process tree) does not get to undo rules merely add more restrictions. Do you mean that the OS privilege of uid 0 does not trust non-privileged users? Or you mean that the human in charge of root on the box does not trust the human who owns the account alice on the box? In the case of the former, this is exactly why AppArmor does not let non-privileged users edit security policy. SELinux, SMACK, LIDS, etc. also all treat manipulating policy as privileged. In the case of the latter, my main claim is that such circumstances are rare, because most users have their own personal workstation. Of course there are exceptions where people are using a multi-user host, and I'm not saying that there is anything wrong with that, just that AppArmor is not particularly good at supporting that environment. I know that multi-user machines is the classic UNIX environment, but that model has slowly faded away and is little used any more, so AppArmor made a trade-off for simplicity at the expense of supporting this use case. User-extensible security policy is a hard problem, and AppArmor does not attempt to solve it. non-privileged user to further tighten the profile on a program. To me, that adds complexity with not much value, but if lots of users want it, then I'm wrong :) Assuming you have any value in the first place, which is another topic, I can see value for this in all the security models. There is value in most features, and the question is whether the feature pays its freight, does the value exceed the cost? AppArmor is particularly sensitive to cost/benefit ratios, because much of AppArmor's value is its simplicity, so there is a naturally high barrier to adding complicating features to AppArmor. All of this is valid discussion for how AppArmor might be improved, but is far, far removed from the dual question that Arjan posed: * Is the model valid? Not is it exactly what I want? but merely is it non-silly, such that clearly it provides value to some users? * Does the code live up to the model? I submit that the AppArmor model is valid, even if it totally failed all of David Gilbert's questions (I think AppArmor can actually provide about half of what he asked for). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
* 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 |___/ - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
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 - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
I submit that the AppArmor model is valid, even if it totally failed all of David Gilbert's questions (I think AppArmor can actually provide about half of what he asked for). The model looks valid. I have difficulty constructing many scenarios where its useful but it appears valid providing you can tightly control file renaming, which is very very questionable. There are also some very awkward path based issues around shared file objects (your controlling tty and TIOCSTI for one) that I need to look at the code for once the VFS stuff is sorted and its likely to get merged. Alan - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
but how can the system know if the directory the user wants to add is reasonable or not? what if the user says they want to store their documents in /etc? A more clear example is wanting to wrap a specific tool with temporary rules. Those rules would depend on the exact file being edited at this moment - something root cannot know in advance (although with apparmor I guess mv $my_file apparmour_magic.name ; foo; mv it back might work 8)) - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
--- Crispin Cowan [EMAIL PROTECTED] wrote: Dr. David Alan Gilbert wrote: ... Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. Note that John Johansen is also interested in allowing non-privileged users to manipulate AppArmor policy, but his view was to only allow a non-privileged user to further tighten the profile on a program. To me, that adds complexity with not much value, but if lots of users want it, then I'm wrong :) Now this is getting interesting. It looks to me as if you've implemented a mandatory access control scheme that some people would like to be able to use as a discretionary access control scheme. This is creepy after seeing the MCS implementation in SELinux, which is also a DAC scheme wacked out of a MAC scheme. Very interesting indeed. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor Security Goal
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=11946492933r=1w=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. pgp5KYCs7jY2D.pgp Description: PGP signature
Re: AppArmor Security Goal
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 pgp8uoR9iBIjM.pgp Description: PGP signature
Re: AppArmor Security Goal
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. pgpkGHDkcnnPg.pgp Description: PGP signature
Re: AppArmor Security Goal
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. pgpzbE3fuep6d.pgp Description: PGP signature
Re: AppArmor Security Goal
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.
pgpIl9rWDJpwq.pgp
Description: PGP signature
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: Allowing a user to tweak (under constraints) their settings might allow them to do something like create two mozilla profiles which are isolated from each other, so that the profile they use for general web surfing is isolated from the one they use for online banking. Doesnt this allow the user to shoot their own foot? The exact thing mandatory access control are supposed to prevent? Dave -- Democracy is about two wolves and a sheep deciding what to eat for dinner. begin:vcard fn:Rogelio M. Serrano Jr n:M. Serrano Jr;Rogelio org:SMSG Communications Philippines;Technical Department adr:;;Republic of the Philippines email;internet:[EMAIL PROTECTED] title:Programmer tel;work:+6327534145 tel;home:+6329527026 tel;cell:+639209202267 x-mozilla-html:FALSE version:2.1 end:vcard signature.asc Description: OpenPGP digital signature
