Re: [RFC PATCH v6 08/13] SELinux: Add new peer permissions to the Flask definitions
On Sunday 11 November 2007 5:31:44 pm James Morris wrote: On Fri, 9 Nov 2007, Paul Moore wrote: Add additional Flask definitions to support the new peer object class. Should this be dependent on dynamic class/permission support? I think it's okay to _define_ the Flask definitions regardless of what the policy supports as older policies should simply ignore these definitions. Or, will these checks only be invoked if labled networking is configured? Bingo! Look at patch 7/13, specifically the 'selinux_policycap_netpeer' variable and then at patch 9/13 where the new access checks are made conditional on this variable. The whole mess needs more testing and verification, but in theory it shouldn't cause any breakage with older policies ... if someone does notice something broken please scream loudly. -- paul moore linux security @ hp - 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: [RFC PATCH v6 09/13] SELinux: Better integration between peer labeling subsystems
On Sunday 11 November 2007 5:34:27 pm James Morris wrote: On Fri, 9 Nov 2007, Paul Moore wrote: + /* Between selinux_compat_net and selinux_policycap_netpeer this is +* starting to get a bit messy - we need to setup a timetable for +* deprecating some of this old/obsolete functionality so we can +* reclaim some level of sanity in this function. */ I don't think we can do anything which could potentially break userspace now. Yeah, I've already had one very long day as a result of that, I'm not in any hurry to do that again :) On a serious note, I thought we could remove specific features after a certain period of time, i.e. Documentation/feature-removal-schedule.txt? My thought is that eventually we can at least remove compat_net, or is that too drastic? So, this one really needs to be right :-) Yeah, this is the one thing that still worries me and one of the main reasons I keep pushing RFC patches so often. Personally, I'm still a little frustrated at how ugly that function looks. I'm debating putting a check near the top to see if any of the compatibility flags are set, meaning an older policy, and if it is just handing off control to a compat function which handles all the ugliness. There might be some duplication of code but the sock_rcv_skb() function would be _much_ cleaner and faster in the current policy case. Actually, I think I just talked myself into it ... -- paul moore linux security @ hp - 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: [PATCH 2/2] Version 11 (2.6.24-rc2) Smack: Simplified Mandatory Access Control Kernel
On Thu, 08 Nov 2007 20:48:52 -0800 Casey Schaufler [EMAIL PROTECTED] wrote: Smack is the Simplified Mandatory Access Control Kernel. This ran afoul of http://userweb.kernel.org/~akpm/mmotm/broken-out/vfs-security-rework-inode_getsecurity-and-callers-to.patch Until that patch gets merged we'll need to run two smack patches: one against mainline and one which updates smack to incorporate that patch's API changes, please. - 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
