Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > >What you do with AppArmor, instead of addressing the problem, is just > >redefine the environment along the lines of "set your house into a rock > >wall so there is only one path to it". > > Harrumph. Those analogies sound good but aren't a very good guide. > > Let's take a concrete example. Consider the following fragment of a > policy for Mozilla: > allow ~/.mozilla > deny ~ > Ignore the syntax; the goal is to allow Mozilla to access files under > ~/.mozilla but nothing else under my home directory. This is a perfectly > reasonable policy fragment to want to enforce. And enforcing it in > the obvious way using pathname-based access control is not a ridiculous > thing to do. Unfortunately, mozilla needs temporary files IIRC. And when you add allow /tmp to your config files, you get system where your fellow users can ln HOME/.ssh/identity /tmp/to-steal (or ln HOME/.profile /tmp/put-evil-code-here) and AA protection is not effective any more. Would _you_ do this mistake? Would our users do this mistake? Is it right to provide them with auto-learning tools to make this mistake really easy? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! One more... > 2. This is argument #1 in a different guise and I find it about as weak. > Pathname-based access control has strengths and weaknesses. I think > users and Linux distributions are in a better position to evaluate those > tradeoffs than L-K. Competition is good. It took you quite a lot of time to realize AA does not do IPC (and all the implications of that). I do not think Linux _users_ can do informed decision here. Novell marketing did too good job here. Heck, even I am not sure if I understand the implications of not doing IPC confinement. Is shared memory commonly used in a way that allows exploiting? I know it is a problem, and you probably could kill init from hacked apache. but what would you do to break out of jail? Pavel (please cc me) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > I've heard four arguments against merging AA. > > Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA. > Or: SELinux can do everything that AA can.) > > Argument 2. Object labeling (or: information flow control) is more secure > than pathname-based access control. > > Argument 3. AA isn't complete until it mediates network and IPC. > > Argument 4. AA doesn't have buy-in from VFS maintainers. ... > 1. I think this is a bogus argument for rejecting AA. As I remember it, ... > 3. This one I agree with. If you want to sandbox network daemons that > 4. Way over my head. I'm not qualified to comment on this aspect. > I suspect this is the argument that ought to be getting the most serious > and thorough discussion, not the irrelevant SELinux-vs-AA faceoff. I believe situation is 'vfs maintainers seriously dislike AA', but if they were given good enough reasons -- like 'selinux is broken crap that does not really work', we probably could twist their arms or something. So question is not 'is AA better then SELinux' but 'is AA so much better than SELinux that we want to overrule vfs maintainers'. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! One more... 2. This is argument #1 in a different guise and I find it about as weak. Pathname-based access control has strengths and weaknesses. I think users and Linux distributions are in a better position to evaluate those tradeoffs than L-K. Competition is good. It took you quite a lot of time to realize AA does not do IPC (and all the implications of that). I do not think Linux _users_ can do informed decision here. Novell marketing did too good job here. Heck, even I am not sure if I understand the implications of not doing IPC confinement. Is shared memory commonly used in a way that allows exploiting? I know it is a problem, and you probably could kill init from hacked apache. but what would you do to break out of jail? Pavel (please cc me) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! I've heard four arguments against merging AA. Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA. Or: SELinux can do everything that AA can.) Argument 2. Object labeling (or: information flow control) is more secure than pathname-based access control. Argument 3. AA isn't complete until it mediates network and IPC. Argument 4. AA doesn't have buy-in from VFS maintainers. ... 1. I think this is a bogus argument for rejecting AA. As I remember it, ... 3. This one I agree with. If you want to sandbox network daemons that 4. Way over my head. I'm not qualified to comment on this aspect. I suspect this is the argument that ought to be getting the most serious and thorough discussion, not the irrelevant SELinux-vs-AA faceoff. I believe situation is 'vfs maintainers seriously dislike AA', but if they were given good enough reasons -- like 'selinux is broken crap that does not really work', we probably could twist their arms or something. So question is not 'is AA better then SELinux' but 'is AA so much better than SELinux that we want to overrule vfs maintainers'. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of set your house into a rock wall so there is only one path to it. Harrumph. Those analogies sound good but aren't a very good guide. Let's take a concrete example. Consider the following fragment of a policy for Mozilla: allow ~/.mozilla deny ~ Ignore the syntax; the goal is to allow Mozilla to access files under ~/.mozilla but nothing else under my home directory. This is a perfectly reasonable policy fragment to want to enforce. And enforcing it in the obvious way using pathname-based access control is not a ridiculous thing to do. Unfortunately, mozilla needs temporary files IIRC. And when you add allow /tmp to your config files, you get system where your fellow users can ln HOME/.ssh/identity /tmp/to-steal (or ln HOME/.profile /tmp/put-evil-code-here) and AA protection is not effective any more. Would _you_ do this mistake? Would our users do this mistake? Is it right to provide them with auto-learning tools to make this mistake really easy? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Chris Wright wrote: > * Chris Mason ([EMAIL PROTECTED]) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. >> > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). To do pathname-based access control in any way, the LSM must be able to obtain the pathname of an accessed object. The discussion should be about the best way for an LSM to obtain the pathname of an object being accessed. To find the pathname of the object, LSM needs the VFS mount point data. The VFS owns this information, so the question is the best way to convey it from VFS to relevant LSM hooks. We are agnostic about how to get that mount point data, but AFAICT saying that LSM can't see the mount point data at all is equivalent to rejecting pathname based access control entirely. > Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > The reverse path construction has been criticized for being both broken and counter-intuitive. Our secure d_path patch fixes the "broken" part, it now securely reconstructs the path. The counter-intuitive is because forward construction of the pathname has unexpected costs, making the retroactive construction more attractive. > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). John Johansen posted a patch (written by Andreas Gruenbacher) that introduced a nameidata2 data structure to try to solve the conditional null passing problem, but it received no comment. A proper fix to this problem is clearly desirable, but it also is clearly a defect in NFS and fixing it is a lot of work; why does AA have to stay outside the kernel until NFS is fixed, when it can easily adapt to the problem until it is fixed properly? > You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. I think it is a little more fundamental than that. If you are going to do pathname based access control at all, you need access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-25T17:14:11, Pavel Machek <[EMAIL PROTECTED]> wrote: > Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ > allows any user to make AA ineffective on large part of systems -- in > internal discussion. (It is not actually a _bug_, but it is certainly > unexpected). Pavel, no, you did not. You _did_ surprise me by misquoting me so badly, though. I agreed that actions by not mediated processes can interfere with mediated processes. That is a given. So you do not give them free access to a world writable directory. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-25T17:14:11, Pavel Machek [EMAIL PROTECTED] wrote: Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected). Pavel, no, you did not. You _did_ surprise me by misquoting me so badly, though. I agreed that actions by not mediated processes can interfere with mediated processes. That is a given. So you do not give them free access to a world writable directory. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Chris Wright wrote: * Chris Mason ([EMAIL PROTECTED]) wrote: I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). To do pathname-based access control in any way, the LSM must be able to obtain the pathname of an accessed object. The discussion should be about the best way for an LSM to obtain the pathname of an object being accessed. To find the pathname of the object, LSM needs the VFS mount point data. The VFS owns this information, so the question is the best way to convey it from VFS to relevant LSM hooks. We are agnostic about how to get that mount point data, but AFAICT saying that LSM can't see the mount point data at all is equivalent to rejecting pathname based access control entirely. Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). The reverse path construction has been criticized for being both broken and counter-intuitive. Our secure d_path patch fixes the broken part, it now securely reconstructs the path. The counter-intuitive is because forward construction of the pathname has unexpected costs, making the retroactive construction more attractive. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). John Johansen posted a patch (written by Andreas Gruenbacher) that introduced a nameidata2 data structure to try to solve the conditional null passing problem, but it received no comment. A proper fix to this problem is clearly desirable, but it also is clearly a defect in NFS and fixing it is a lot of work; why does AA have to stay outside the kernel until NFS is fixed, when it can easily adapt to the problem until it is fixed properly? You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. I think it is a little more fundamental than that. If you are going to do pathname based access control at all, you need access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Mon, 25 Jun 2007, Pavel Machek wrote: Hi! We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected). (Does it surprise you, too? I'm pretty sure it would surprise many users). no, it doesn't surprise me in the least. AA is controlling access to the thing called /etc/shadow, if you grant access to it in other ways you bypass the restrictions. if you follow the ln /etc/shadow /tmp/ with chmod 777 /tmp/shadow the system is completely insecure. this is standard stuff that normal sysadmins expect. it's only people who have focused on the label approach who would expect it to be any different. James summarized it nicely: # The design of the AppArmor is based on _appearing simple_, but at the # expense of completeness and thus correctness. If even Lars can be surprised by AAs behaviour, I do not think we can say "AA is different". I'm afraid that AA is trap for users. It appears simple, and mostly does what it is told, but does not do _what user wants_. I thought it had been made very clear that hard links like this were a potential way around the restrictions, which is why controlled tasks are not allowed to do arbatrary hard links. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > We've been over the "AA is different" discussion in threads about a > billion times, and at the last kernel summit. I think Lars and others > have done a pretty good job of describing the problems they are trying > to solve, can we please move on to discussing technical issues around > that? Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected). (Does it surprise you, too? I'm pretty sure it would surprise many users). James summarized it nicely: # The design of the AppArmor is based on _appearing simple_, but at the # expense of completeness and thus correctness. If even Lars can be surprised by AAs behaviour, I do not think we can say "AA is different". I'm afraid that AA is trap for users. It appears simple, and mostly does what it is told, but does not do _what user wants_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! We've been over the AA is different discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected). (Does it surprise you, too? I'm pretty sure it would surprise many users). James summarized it nicely: # The design of the AppArmor is based on _appearing simple_, but at the # expense of completeness and thus correctness. If even Lars can be surprised by AAs behaviour, I do not think we can say AA is different. I'm afraid that AA is trap for users. It appears simple, and mostly does what it is told, but does not do _what user wants_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Mon, 25 Jun 2007, Pavel Machek wrote: Hi! We've been over the AA is different discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected). (Does it surprise you, too? I'm pretty sure it would surprise many users). no, it doesn't surprise me in the least. AA is controlling access to the thing called /etc/shadow, if you grant access to it in other ways you bypass the restrictions. if you follow the ln /etc/shadow /tmp/ with chmod 777 /tmp/shadow the system is completely insecure. this is standard stuff that normal sysadmins expect. it's only people who have focused on the label approach who would expect it to be any different. James summarized it nicely: # The design of the AppArmor is based on _appearing simple_, but at the # expense of completeness and thus correctness. If even Lars can be surprised by AAs behaviour, I do not think we can say AA is different. I'm afraid that AA is trap for users. It appears simple, and mostly does what it is told, but does not do _what user wants_. I thought it had been made very clear that hard links like this were a potential way around the restrictions, which is why controlled tasks are not allowed to do arbatrary hard links. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Sun, 24 Jun 2007, David Wagner wrote: Argument 3. AA isn't complete until it mediates network and IPC. Let me comment on these one-by-one. 3. This one I agree with. If you want to sandbox network daemons that you're concerned might get hacked, then you really want your sandbox to mediate everything. Right now the security provided by AA (if that's what you are using it for) will be limited by its incomplete mediation, since a knowledgeable motivated attacker who hacks your daemon may be able to use network or IPC to break out of the sandbox, depending upon the network and host configuration. Filesystem mediation alone might be better than nothing, I suppose, if you're worried about script kiddies, but it's certainly not a basis for strong security claims. The state of the art in sandboxing obviously requires complete mediation, and we've known that for a decade. the issue I see is that AA may not have to implement any new in-kernel infrastructure to do this. as recently as yesterday there have been discussions on the netfilter list about how to implement filter rules based on the application name (see the thread titled 'filter by application name') if this gets implemented independantly of AA then AA could provide a policy implementation layer over netfilter if desired (or sysadmins could just use their current favorite tool to control the network and AA to control the filesystem) so holding up AA becouse this isn't implemented yet seems to be counter productive. people are working on this, and it is going to go in at some point independantly of AA, so why tie AA to it? IPC is a very imprecise term. it includes lots of different ways for processes to communicate with each other. some forms of IPC are covered by AA today (unix sockets), others aren't. but each of the different methods is going to involve some difference in how it's controlled. if you want to talk IPC be specific about what IPC methods you are talking bout limiting. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: >A. Pathname labeling - applying access control to pathnames to objects, >rather than labeling the objects themselves. > >Think of this as, say, securing your house by putting a gate in the street >in front of the house, regardless of how many other possible paths there >are to the house via other streets, adjoining properties etc. > >Pathname labeling and mediation is simply mediating a well-known path to >the object. In this analogy, object labeling would instead ensure that >all of the accessible doors, windows and other entrances of the house were >locked, so that someone trying to break in from the rear alley would >not get in simply by bypassing the front gate and opening any door. > >What you do with AppArmor, instead of addressing the problem, is just >redefine the environment along the lines of "set your house into a rock >wall so there is only one path to it". Harrumph. Those analogies sound good but aren't a very good guide. Let's take a concrete example. Consider the following fragment of a policy for Mozilla: allow ~/.mozilla deny ~ Ignore the syntax; the goal is to allow Mozilla to access files under ~/.mozilla but nothing else under my home directory. This is a perfectly reasonable policy fragment to want to enforce. And enforcing it in the obvious way using pathname-based access control is not a ridiculous thing to do. Yes, in theory, there could always be crazy symlinks or hardlinks from somewhere under ~/.mozilla to elsewhere in my home directory that would cause this policy to behave in ways different from how I desired. In theory. But in practice this is "pretty good": good enough to be useful in the real world. In the real world I don't have any symlinks like that under my ~/.mozilla directory, and I'm not really worried about unconfined processes accidentally creating a symlink under there against my wishes. It'd be good enough for me. Yes, pathname-based models have limitations and weaknesses, but don't overplay them. For some purposes they are a very simple way of specifying a desired policy and they work well enough to be useful -- a darn site better than what we've got today. If your goal is "ease of use" and "better than what many users are using today", it's not an unreasonable approach. Time will tell whether it's the best solution, but it's not obviously wrong. And I think that's the criteria: If you want to argue that the very idea of pathname-based access control so bogus that no approach to pathname-based security should be merged, then you should have to argue that it is obviously wrong and obviously not useful to users. I don't think that burden has been met. >B. Pathname access control as a general abstraction for OS security. This strikes me as a strawman. Pathname-based access control is an abstraction for mediating the *filesystem*. Who says it has to be the way you mediate the network or IPC? >To quote from: > >http://www.novell.com/linux/security/apparmor/ > > "AppArmor gives you network application security via mandatory access > control for programs, protecting against the exploitation of software > flaws and compromised systems. AppArmor includes everything you need to > provide effective containment for programs (including those that run as > root) to thwart attempted exploits and even zero-day attacks." > >This is not accurate in any sense of the term containment of mandatory >access control that I've previously encountered. You bet. The claim you quote is totally bogus. Bad marketers, no biscuit for you. >The fact that it doesn't work as expected does not arise simply from >missing features or being "different". It arises from the design of the >system, which uses a pathname abstraction, where, even if we agree to >ignore issue (1) above, still does not work, because only filesystem >interactions are mediated. Disagree. >The "simple" policy that users can so effortlessly manipulate is simple >because it is wrong, and deliberately so. > >The design of the AppArmor is based on _appearing simple_, but at the >expense of completeness and thus correctness. Based on my experience with Janus, my expectation is the policy isn't going to get that much more complicated when they add mediation of network and IPC access. I suspect it will stay almost as simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: >The point is that the pathname model does not generalize, and that >AppArmor's inability to provide adequate coverage of the system is a >design issue arising from this. I don't see it. I don't see why you call this a design issue. Isn't this just a case where they haven't gotten around to implementing network and IPC mediation yet? How is that a design issue arising from a pathname-based model? For instance, one system I built (Janus) provided complete mediation, including mediation of network and IPC, yet it too used a pathname model for its policy file when describing the policy for the filesystem. That seems to contradict your statement. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
I've heard four arguments against merging AA. Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA. Or: SELinux can do everything that AA can.) Argument 2. Object labeling (or: information flow control) is more secure than pathname-based access control. Argument 3. AA isn't complete until it mediates network and IPC. Argument 4. AA doesn't have buy-in from VFS maintainers. Let me comment on these one-by-one. 1. I think this is a bogus argument for rejecting AA. As I remember it, the whole point of LSM was to allow merging multiple solutions and let them compete for users on their merit, not to force the Linux maintainers to figure out which is the best solution. Let a million flowers bloom. 2. This is argument #1 in a different guise and I find it about as weak. Pathname-based access control has strengths and weaknesses. I think users and Linux distributions are in a better position to evaluate those tradeoffs than L-K. Competition is good. 3. This one I agree with. If you want to sandbox network daemons that you're concerned might get hacked, then you really want your sandbox to mediate everything. Right now the security provided by AA (if that's what you are using it for) will be limited by its incomplete mediation, since a knowledgeable motivated attacker who hacks your daemon may be able to use network or IPC to break out of the sandbox, depending upon the network and host configuration. Filesystem mediation alone might be better than nothing, I suppose, if you're worried about script kiddies, but it's certainly not a basis for strong security claims. The state of the art in sandboxing obviously requires complete mediation, and we've known that for a decade. That said, I see filesystem mediation as the hard part. It's the hardest part to implement and get right. It's the hardest part to configure and the hardest part when it comes to designing usable policy languages. And I suspect it's the hardest part to get merged into the Linux kernel. And it often makes sense to start with the hard part. If AA's approach to mediating the filesystem is acceptable, I think AA is 2/3rds of the way to a tool that could be very useful for providing strong security claims. There's a policy decision here: Do maintainers refuse to merge AA until it provides complete mediation? That's a policy matter that's up to the maintainers. I have no opinion on it. However if that is the reason for rejecting AA it seems like it might be appropriate to come to some decision now about whether AA's approach to filesystem mediation is acceptable to Linux developers. I don't think it would be reasonable to tell AA developers to go spend a few months developing network and IPC mediation and then after they do that, to reject the whole thing on the basis that the approach to filesystem mediation is unacceptable. That won't encourage development of new and innovative approaches to security, which doesn't seem like a good thing to me. 4. Way over my head. I'm not qualified to comment on this aspect. I suspect this is the argument that ought to be getting the most serious and thorough discussion, not the irrelevant SELinux-vs-AA faceoff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: >On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: >> No the "incomplete" mediation does not flow from the design. We have >> deliberately focused on doing the necessary modifications for pathname >> based mediation. The IPC and network mediation are a wip. > >The fact that you have to go back to the drawing board for them is that >you didn't get the abstraction right in the first place. Calling this "going back to the drawing board" board strikes me as an unfair criticism, when the real situation is that in the future the AA folks will need to extend their code to mediate network and IPC (not throw all the current code away and start over from scratch, and not replace big swaths of the current code). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: >That would certainly help, although one might quibble with the use of >the word "confinement" at all wrt AppArmor (it has a long-established >technical meaning that implies information flow control, and that goes >beyond even complete mediation - it requires global and persistent >protection of the data based on its properties, which requires stable >and unambiguous identifiers). 1. Yes, that's the usage that has the greatest historical claim, but "confinement" has also been used in the security community to refer to limiting the overt side effects a process can have rather than controlling information flow. The term "confinement" is arguably ambiguous, but I think there is a semi-established meaning that doesn't imply information flow control. 2. This is a can of worms we probably don't want to open. Keep in mind that SELinux doesn't meet definition of confinement in Lampson's original paper, either, because it only restricts overt information flows. SELinux doesn't prevent covert channels, even though Lampson's original paper included them as part of the confinement problem. Yet I don't think it would be reasonable to criticize someone for describing SELinux as a tool for "confinement". I don't know of any practical solution that solves the confinement problem as Lampson envisioned it. I'd recommend making decisions on the basis of whether the mechanisms are useful, rather than whether they solve Lampson's notion of the "confinement" problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > But as someone who doesn't use either SElinux or AA, I really hope > we can get past the part of the debate where: > > while(1) > AA) we think we're making users happy with pathname security > SELINUX) pathname security sucks (Hopefully I'll not be fired for this. :-) Yes, we _are_ making users happy with AA. Questions is if we are making them secure. :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: >On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: >> And now, yes, I know AA doesn't mediate IPC or networking (yet), but >> that's a missing feature, not broken by design. > >The incomplete mediation flows from the design, since the pathname-based >mediation doesn't generalize to cover all objects unlike label- or >attribute-based mediation. I don't see anything in the AA design that would prevent an extending it to mediate network and IPC while remaining consistent with its design so far. Do you? It seems to me the AA design is to mediate filesystem access using pathname-based access control, and that says nothing about how they mediate network access. I have built sandboxing tools before, and my experience is that the filesystem mediation is the hardest, gronkiest part. In comparison, mediating networking and IPC is considerably easier. The policy language for mediating access to the network can be pretty simple. The same for IPC. Obviously you shouldn't expect the policy language for networking to use filenames, any more than you should expect the policy languages for filesystems to use TCP/IP port numbers; that wouldn't make any sense. >And the "use the natural abstraction for >each object type" approach likewise doesn't yield any general model or >anything that you can analyze systematically for data flow. I don't see this as relevant to whether AA should be merged. Fight that one in the marketplace for users, not L-K. >> If I restrict my Mozilla to not access my on-disk mail folder, it can't >> get there. (Barring bugs in programs which Mozilla is allowed to run >> unconfined, sure.) > >Um, no. It might not be able to directly open files via that path, but >showing that it can never read or write your mail is a rather different >matter. "Showing that it can never read or write your mail" is not part of AA's goals. People whose goals differ from AA's can use a different tool. No one is forcing you to use AA if it isn't useful to you. I don't see this criticism as relevant to a merger decision. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. I don't see anything in the AA design that would prevent an extending it to mediate network and IPC while remaining consistent with its design so far. Do you? It seems to me the AA design is to mediate filesystem access using pathname-based access control, and that says nothing about how they mediate network access. I have built sandboxing tools before, and my experience is that the filesystem mediation is the hardest, gronkiest part. In comparison, mediating networking and IPC is considerably easier. The policy language for mediating access to the network can be pretty simple. The same for IPC. Obviously you shouldn't expect the policy language for networking to use filenames, any more than you should expect the policy languages for filesystems to use TCP/IP port numbers; that wouldn't make any sense. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. I don't see this as relevant to whether AA should be merged. Fight that one in the marketplace for users, not L-K. If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.) Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Showing that it can never read or write your mail is not part of AA's goals. People whose goals differ from AA's can use a different tool. No one is forcing you to use AA if it isn't useful to you. I don't see this criticism as relevant to a merger decision. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks (Hopefully I'll not be fired for this. :-) Yes, we _are_ making users happy with AA. Questions is if we are making them secure. :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: That would certainly help, although one might quibble with the use of the word confinement at all wrt AppArmor (it has a long-established technical meaning that implies information flow control, and that goes beyond even complete mediation - it requires global and persistent protection of the data based on its properties, which requires stable and unambiguous identifiers). 1. Yes, that's the usage that has the greatest historical claim, but confinement has also been used in the security community to refer to limiting the overt side effects a process can have rather than controlling information flow. The term confinement is arguably ambiguous, but I think there is a semi-established meaning that doesn't imply information flow control. 2. This is a can of worms we probably don't want to open. Keep in mind that SELinux doesn't meet definition of confinement in Lampson's original paper, either, because it only restricts overt information flows. SELinux doesn't prevent covert channels, even though Lampson's original paper included them as part of the confinement problem. Yet I don't think it would be reasonable to criticize someone for describing SELinux as a tool for confinement. I don't know of any practical solution that solves the confinement problem as Lampson envisioned it. I'd recommend making decisions on the basis of whether the mechanisms are useful, rather than whether they solve Lampson's notion of the confinement problem. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: No the incomplete mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. Calling this going back to the drawing board board strikes me as an unfair criticism, when the real situation is that in the future the AA folks will need to extend their code to mediate network and IPC (not throw all the current code away and start over from scratch, and not replace big swaths of the current code). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
I've heard four arguments against merging AA. Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA. Or: SELinux can do everything that AA can.) Argument 2. Object labeling (or: information flow control) is more secure than pathname-based access control. Argument 3. AA isn't complete until it mediates network and IPC. Argument 4. AA doesn't have buy-in from VFS maintainers. Let me comment on these one-by-one. 1. I think this is a bogus argument for rejecting AA. As I remember it, the whole point of LSM was to allow merging multiple solutions and let them compete for users on their merit, not to force the Linux maintainers to figure out which is the best solution. Let a million flowers bloom. 2. This is argument #1 in a different guise and I find it about as weak. Pathname-based access control has strengths and weaknesses. I think users and Linux distributions are in a better position to evaluate those tradeoffs than L-K. Competition is good. 3. This one I agree with. If you want to sandbox network daemons that you're concerned might get hacked, then you really want your sandbox to mediate everything. Right now the security provided by AA (if that's what you are using it for) will be limited by its incomplete mediation, since a knowledgeable motivated attacker who hacks your daemon may be able to use network or IPC to break out of the sandbox, depending upon the network and host configuration. Filesystem mediation alone might be better than nothing, I suppose, if you're worried about script kiddies, but it's certainly not a basis for strong security claims. The state of the art in sandboxing obviously requires complete mediation, and we've known that for a decade. That said, I see filesystem mediation as the hard part. It's the hardest part to implement and get right. It's the hardest part to configure and the hardest part when it comes to designing usable policy languages. And I suspect it's the hardest part to get merged into the Linux kernel. And it often makes sense to start with the hard part. If AA's approach to mediating the filesystem is acceptable, I think AA is 2/3rds of the way to a tool that could be very useful for providing strong security claims. There's a policy decision here: Do maintainers refuse to merge AA until it provides complete mediation? That's a policy matter that's up to the maintainers. I have no opinion on it. However if that is the reason for rejecting AA it seems like it might be appropriate to come to some decision now about whether AA's approach to filesystem mediation is acceptable to Linux developers. I don't think it would be reasonable to tell AA developers to go spend a few months developing network and IPC mediation and then after they do that, to reject the whole thing on the basis that the approach to filesystem mediation is unacceptable. That won't encourage development of new and innovative approaches to security, which doesn't seem like a good thing to me. 4. Way over my head. I'm not qualified to comment on this aspect. I suspect this is the argument that ought to be getting the most serious and thorough discussion, not the irrelevant SELinux-vs-AA faceoff. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. I don't see it. I don't see why you call this a design issue. Isn't this just a case where they haven't gotten around to implementing network and IPC mediation yet? How is that a design issue arising from a pathname-based model? For instance, one system I built (Janus) provided complete mediation, including mediation of network and IPC, yet it too used a pathname model for its policy file when describing the policy for the filesystem. That seems to contradict your statement. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves. Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc. Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door. What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of set your house into a rock wall so there is only one path to it. Harrumph. Those analogies sound good but aren't a very good guide. Let's take a concrete example. Consider the following fragment of a policy for Mozilla: allow ~/.mozilla deny ~ Ignore the syntax; the goal is to allow Mozilla to access files under ~/.mozilla but nothing else under my home directory. This is a perfectly reasonable policy fragment to want to enforce. And enforcing it in the obvious way using pathname-based access control is not a ridiculous thing to do. Yes, in theory, there could always be crazy symlinks or hardlinks from somewhere under ~/.mozilla to elsewhere in my home directory that would cause this policy to behave in ways different from how I desired. In theory. But in practice this is pretty good: good enough to be useful in the real world. In the real world I don't have any symlinks like that under my ~/.mozilla directory, and I'm not really worried about unconfined processes accidentally creating a symlink under there against my wishes. It'd be good enough for me. Yes, pathname-based models have limitations and weaknesses, but don't overplay them. For some purposes they are a very simple way of specifying a desired policy and they work well enough to be useful -- a darn site better than what we've got today. If your goal is ease of use and better than what many users are using today, it's not an unreasonable approach. Time will tell whether it's the best solution, but it's not obviously wrong. And I think that's the criteria: If you want to argue that the very idea of pathname-based access control so bogus that no approach to pathname-based security should be merged, then you should have to argue that it is obviously wrong and obviously not useful to users. I don't think that burden has been met. B. Pathname access control as a general abstraction for OS security. This strikes me as a strawman. Pathname-based access control is an abstraction for mediating the *filesystem*. Who says it has to be the way you mediate the network or IPC? To quote from: http://www.novell.com/linux/security/apparmor/ AppArmor gives you network application security via mandatory access control for programs, protecting against the exploitation of software flaws and compromised systems. AppArmor includes everything you need to provide effective containment for programs (including those that run as root) to thwart attempted exploits and even zero-day attacks. This is not accurate in any sense of the term containment of mandatory access control that I've previously encountered. You bet. The claim you quote is totally bogus. Bad marketers, no biscuit for you. The fact that it doesn't work as expected does not arise simply from missing features or being different. It arises from the design of the system, which uses a pathname abstraction, where, even if we agree to ignore issue (1) above, still does not work, because only filesystem interactions are mediated. Disagree. The simple policy that users can so effortlessly manipulate is simple because it is wrong, and deliberately so. The design of the AppArmor is based on _appearing simple_, but at the expense of completeness and thus correctness. Based on my experience with Janus, my expectation is the policy isn't going to get that much more complicated when they add mediation of network and IPC access. I suspect it will stay almost as simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Sun, 24 Jun 2007, David Wagner wrote: Argument 3. AA isn't complete until it mediates network and IPC. Let me comment on these one-by-one. 3. This one I agree with. If you want to sandbox network daemons that you're concerned might get hacked, then you really want your sandbox to mediate everything. Right now the security provided by AA (if that's what you are using it for) will be limited by its incomplete mediation, since a knowledgeable motivated attacker who hacks your daemon may be able to use network or IPC to break out of the sandbox, depending upon the network and host configuration. Filesystem mediation alone might be better than nothing, I suppose, if you're worried about script kiddies, but it's certainly not a basis for strong security claims. The state of the art in sandboxing obviously requires complete mediation, and we've known that for a decade. the issue I see is that AA may not have to implement any new in-kernel infrastructure to do this. as recently as yesterday there have been discussions on the netfilter list about how to implement filter rules based on the application name (see the thread titled 'filter by application name') if this gets implemented independantly of AA then AA could provide a policy implementation layer over netfilter if desired (or sysadmins could just use their current favorite tool to control the network and AA to control the filesystem) so holding up AA becouse this isn't implemented yet seems to be counter productive. people are working on this, and it is going to go in at some point independantly of AA, so why tie AA to it? IPC is a very imprecise term. it includes lots of different ways for processes to communicate with each other. some forms of IPC are covered by AA today (unix sockets), others aren't. but each of the different methods is going to involve some difference in how it's controlled. if you want to talk IPC be specific about what IPC methods you are talking bout limiting. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. I just wanted to help discussion. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Thank you, Toshiharu Harada Chris Wright wrote: > * Chris Mason ([EMAIL PROTECTED]) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. > > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > >> But as someone who doesn't use either SElinux or AA, I really hope >> we can get past the part of the debate where: >> >> while(1) >> AA) we think we're making users happy with pathname security >> SELINUX) pathname security sucks > > Yes. Please. Both parties are miserably failing the sanity test. > Doing the same thing over and over and expecting different results. > > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. > > SELinux folks: do something useful rather than quibbling over the TCSEC > definition of MAC and AA's poor taste in marketing literature. Here's > some suggestions: > > 1) Make SELinux usable (it's *still* the number one complaint). While > this is a bit of a cheap shot, it really is one of the core reasons AA > advocates exist. > 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. > 3) Write an effective exploit against AA that demonstrates the fundamental > weakness of the model (better make sure it's not also an issue for > targetted policy). -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, waste of time is taking place here, but it's not for pathname-based MAC but for wrongly posted messages, I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is let's make progress and help each other to make Linux better. Thank you, Toshiharu Harada Chris Wright wrote: * Chris Mason ([EMAIL PROTECTED]) wrote: I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions: 1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist. 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. 3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy). -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, waste of time is taking place here, but it's not for pathname-based MAC but for wrongly posted messages, I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. I just wanted to help discussion. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is let's make progress and help each other to make Linux better. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
* Chris Mason ([EMAIL PROTECTED]) wrote: > I'm sure people there will have a different versions of events. The > one part that was discussed was if pathname based security was > useful, and a number of the people in the room (outside of > novell) said it was. Now, it could be that nobody wanted to argue > anymore, since most opinions had come out on one list or another by > then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). > But as someone who doesn't use either SElinux or AA, I really hope > we can get past the part of the debate where: > > while(1) > AA) we think we're making users happy with pathname security > SELINUX) pathname security sucks Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions: 1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist. 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. 3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, Stephen Smalley wrote: On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote: And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. or it just means that the tool to regulat the network is different from the tool to regulate the filesystem. oh, by the way. that's how the rest of the *nix world works. firewall rules apply to networking, filesystem permissions and ACLs apply to the filesystem. this is like climing that the latest improvement to ipsec shouldn't go in becouse it down't allow you to handle things the same way that you handle temp files or a serial port. We have never claimed to be using pathname-based mediation IPC or networking. The "natural abstraction" approach does generize well enough and will be analyzable. I think we must have different understandings of the words "generalize" and "analyzable". Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), then I need to be able to have a common reference point for my policy. When my policy is based on different abstractions (pathnames, IP addresses, window ids, whatever) for different objects, then I can no longer identify how data can flow throughout the system in a system-wide way. if you are doing a system-wide analysis then you are correct. the AA approach is to start with the exposed items and limit the damage that can be done to you. sysadmins already think in terms of paths and what can access that path (directory permissions), AA extends this in a very natural way and doesn't require any special tools or extra steps for normal administration. As a result sysadmins are far more likely to use this then they are to touch anything that requires that they do a full system analysis before they start. another advantage is that since the policies are independant of each other it becomes very easy for software to include sample policies with the source. Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible. No, it isn't possible when using ambiguous and unstable identifiers for the subjects and objects, nor when mediation is incomplete. it is possible to say that without assistance from an outside process the process cannot access the files containing your mail. if there is some other method of accessing the content no filesystem-level thing can know about it (for example, if another process is a pop server that requires no password). but I don't beleive that SELinux policies as distributed by any vendor would prevent this (yes, it would be possible for a tailored policy to prevent it, but if the policy is so complex that only distro staff should touch it that doesn't matter in real life) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, James Morris wrote: On Fri, 22 Jun 2007, Chris Mason wrote: But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one. Until people understand these issues, they certainly need to be addressed in the context of upstream merge. there are always going to be people who misunderstand things. by this logic nothing can ever be merged that can be misused. at least some of the intended audience (including me) do understand the limits and still consider the result useful. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, Jun 22, 2007 at 10:23:03AM -0400, James Morris wrote: > On Fri, 22 Jun 2007, Chris Mason wrote: > > > But, this is a completely different discussion than if AA is > > solving problems in the wild for its intended audience, or if the code > > is somehow flawed and breaking other parts of the kernel. > > Is its intended audience aware of its limitiations? Lars has just > acknowledged that it does not implement mandatory access control, for one. > > Until people understand these issues, they certainly need to be addressed > in the context of upstream merge. It is definitely useful to clearly understand the intended AA use cases during the merge. > > > We've been over the "AA is different" discussion in threads about a > > billion times, and at the last kernel summit. > > I don't believe that people at the summit were adequately informed on the > issue, and from several accounts I've heard, Stephen Smalley was > effectively cut off before he could even get to his second slide. I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks So, yes Greg got it started and Lars is a well known trouble maker, and I completely understand if you want to say no thank you to an selinux based AA ;) The models are different and it shouldn't be a requirement that they try to use the same underlying mechanisms. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
--- Stephen Smalley <[EMAIL PROTECTED]> wrote: > Mandatory access control as historically understood has always meant > system-wide. Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control "The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control." Chapter and verse: TCSEC 3.2.1.4 Mandatory Access Control "The TCB shall enforce a mandatory access control policy over all resources that are directly or indirectly accessible by subjects external to the TCB." The first reference is in the definition of a B1 system, while the second is for a B2 system. It was made clear to those of us doing TCSEC evaluations that there is a very real distintion between these two requirements. In the history that I've been through, starting in 1987, the B1 requirement has been read to allow for things that are not storage objects to be uncontrolled while the B2 requirement does not. If everything is a storage object, which is the approach everybody took, yes, you're looking at system wide. If, on the other hand, you were to take a different model approach and say that networking does not use storage objects you would not have to account for them under the B1 rules, while you would still have to for B2. Historically, no one succeeded with B2, and the mindset of B1 prevailed. So, historically, the understanding was that it was easier to declare everything a storage object and code up some MAC for it than it was to provide a security model that explained networking as it really works. I suggest that if AA wants to declare that as far as they are concerned sockets, ports, and packets are none of them storage objects but are instead pregnant weasels that is their peragotive as system designers and that a B1 evaluation team would have accepted that, provided sufficient evidence and explaination of the relevence of pregnant weasels was provided. It would not have worked at B2, but historically everyone understood that B2 was out of reach. Stephen is correct in that historically everyone implemented system that put everything under MAC, but is not in that it was well understood that if you could define something as not being a storage object you didn't have to submit it to MAC. Then as now it was easier to get people to code MAC than to get them to write papers about the security properties of pregnant weasels. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote: > On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote: > > On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > Sorry, do you mean the "server" as in the "server system" or as in the > > > "server daemon"? For the former, I'd agree - we would want SELinux > > > policy applied on the server as well as the client to ensure that the > > > data is being protected consistently throughout and that the server is > > > not misrepresenting the security guarantees expected by the clients. > > > Providing an illusion of confinement on each client without any > > > corresponding protection on the server system would be very prone to > > > bypass. For the latter, the kernel can only truly confine application > > > code, not in-kernel threads, although we can subject the in-kernel nfsd > > > to permission checking as a robustness check. We've always noted that > > > SELinux does depend on the correctness of the kernel. > > > > Oh, you're saying that this threat is out-of-scope? ;-) > > Kernel flaws aren't something we can address (reliably and in general) > via a kernel mechanism. Versus a threat that can be addressed by kernel > mechanism, like providing complete mediation and unambiguous access > control. There is a difference. And we aren't ignoring the kernel > correctness problem - there is separate work in that space, but it > requires separate mechanism outside of SELinux itself. > > > Note that here we've already strayed from the focus of the discussion; > > we're no longer arguing "the implementation is ugly/broken", but you're > > claiming "doesn't do what I need" - which I'm not disagreeing with. It > > doesn't do what you want. Which is why you have SELinux, and it's going > > to stay. Fine. > > > > If we assume that the users who run it do have a need / use case for it > > which they can't solve differently, we should really get back to the > > discussion of how those needs can be met or provided by Linux in a > > feasible way. > > Part of the discussion has been whether those users' needs could be > solved better via SELinux, whether via improved userspace tools (ala > seedit possibly with an enhanced restorecond) or via extended kernel > mechanism (ala named type transitions and some kind of inheritance > model). It does however seem like there is a fundamental conflict there > on renaming behavior; I do not believe that file protections should > automatically change in the kernel upon rename and should require > explicit userspace action. The question though is whether that renaming > behavior in AA is truly a user requirement or a manufactured (i.e. > made-up) one, and whether it is truly a runtime requirement or just a > policy creation time one (the latter being adequately addressed by > userspace relabeling). I suppose there is also a question of whether that kind of model wouldn't be better implemented as an ACL model with implicit inheritance, e.g. if you specify an ACL on a directory, then all files accessed via that directory are controlled in accordance with that ACL unless they have their own more specific ACL, and if you move one of those files to a different directory, then they automatically pick up the protection of the new parent. Doesn't require the kernel to be matching pathname strings, just walking up the tree to determine the closest ancestor with an explicit ACL on it. > > If that behavior is truly needed (a point I wouldn't concede), then the > discussion does reduce down to the right implementation method. There > it appears that the primary objection is to regenerating full pathname > strings and matching them versus some kind of incremental matching > either during lookup itself or via a reverse match as suggested. That > discussion is principally one in which the vfs folks should be engaged, > not me. > > > > > Your use case mandates complete system-wide mediation, because you want > > > > full data flow analysis. Mine doesn't. > > > Then yours isn't mandatory access control, nor is it confinement. > > > > I apologize for not using the word "confinement" in the way you expect > > it to be used. I certainly don't want to imply it does do things it > > doesn't. Keep in mind I'm not a native speaker, so nuances do get lost > > sometimes; nor do I have long years of experience in the security > > field. Thanks for clearing this up. > > > > So agreed, it is not confinement nor MAC. > > > > Would it be more appropriate if I used the word "restricts" or > > "constrains"? > > Yes. Or simply "controls file accesses and capability usage". > -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, Chris Mason wrote: > But, this is a completely different discussion than if AA is > solving problems in the wild for its intended audience, or if the code > is somehow flawed and breaking other parts of the kernel. Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one. Until people understand these issues, they certainly need to be addressed in the context of upstream merge. > We've been over the "AA is different" discussion in threads about a > billion times, and at the last kernel summit. I don't believe that people at the summit were adequately informed on the issue, and from several accounts I've heard, Stephen Smalley was effectively cut off before he could even get to his second slide. > I think Lars and others have done a pretty good job of describing the > problems they are trying to solve, can we please move on to discussing > technical issues around that? Keep in mind that this current thread arose from Greg KH asking about whether AppArmor could effectively be implemented via SELinux and userspace labeling. Some of us took the time to perform analysis and then provide feedback on this, in good faith. The underlying issues only came up again in response to an inflammatory post by Lars. If you want to avoid discussions of AppArmor's design, then I suggest taking it up with those who initiate them. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote: > On Fri, 22 Jun 2007, Chris Mason wrote: > > > > The validity or otherwise of pathname access control is not being > > > discussed here. > > > > > > The point is that the pathname model does not generalize, and that > > > AppArmor's inability to provide adequate coverage of the system is a > > > design issue arising from this. > > > > I'm sorry, but I don't see where in the paragraphs above you aren't > > making a general argument against the pathname model. > > There are two distinct concepts here. > > A. Pathname labeling - applying access control to pathnames to objects, > rather than labeling the objects themselves. > > Think of this as, say, securing your house by putting a gate in the street > in front of the house, regardless of how many other possible paths there > are to the house via other streets, adjoining properties etc. > > Pathname labeling and mediation is simply mediating a well-known path to > the object. In this analogy, object labeling would instead ensure that > all of the accessible doors, windows and other entrances of the house were > locked, so that someone trying to break in from the rear alley would > not get in simply by bypassing the front gate and opening any door. > > What you do with AppArmor, instead of addressing the problem, is just > redefine the environment along the lines of "set your house into a rock > wall so there is only one path to it". > > > B. Pathname access control as a general abstraction for OS security. > > Which is what was being discussed above, in response to a question from > Lars about technical issues, and that this _model_ doesn't generalize to > the rest of the OS, regardless of whether you think the mechanism of > pathname labeling itself is appropriate or not. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. I'm not trying to get into that discussion (I'm smart enough to know I'm far too stupid to hold my own there). I do understand that AA is different from selinux, and that you have valid points about the level and type of protection that AA offers. But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, Chris Mason wrote: > > The validity or otherwise of pathname access control is not being > > discussed here. > > > > The point is that the pathname model does not generalize, and that > > AppArmor's inability to provide adequate coverage of the system is a > > design issue arising from this. > > I'm sorry, but I don't see where in the paragraphs above you aren't > making a general argument against the pathname model. There are two distinct concepts here. A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves. Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc. Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door. What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of "set your house into a rock wall so there is only one path to it". B. Pathname access control as a general abstraction for OS security. Which is what was being discussed above, in response to a question from Lars about technical issues, and that this _model_ doesn't generalize to the rest of the OS, regardless of whether you think the mechanism of pathname labeling itself is appropriate or not. In any case, clarifying such a distinction should not obscure the central issue, which is: AppArmor's design is broken. General users, many kernel developers, and even security researchers who have not yet looked under the covers [1], are probably unaware that the confinement claims being made about AppArmor's confinement capabilities are simply not possible with either its model or implementation. To quote from: http://www.novell.com/linux/security/apparmor/ "AppArmor gives you network application security via mandatory access control for programs, protecting against the exploitation of software flaws and compromised systems. AppArmor includes everything you need to provide effective containment for programs (including those that run as root) to thwart attempted exploits and even zero-day attacks." This is not accurate in any sense of the term containment of mandatory access control that I've previously encountered. The fact that it doesn't work as expected does not arise simply from missing features or being "different". It arises from the design of the system, which uses a pathname abstraction, where, even if we agree to ignore issue (1) above, still does not work, because only filesystem interactions are mediated. AppArmor policy does not reflect the behavior of the system. The "simple" policy that users can so effortlessly manipulate is simple because it is wrong, and deliberately so. The design of the AppArmor is based on _appearing simple_, but at the expense of completeness and thus correctness. [1] http://lkml.org/lkml/2007/4/19/357 "My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained?" - David Wagner, http://www.cs.berkeley.edu/~daw/ Indeed. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote: > On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > Sorry, do you mean the "server" as in the "server system" or as in the > > "server daemon"? For the former, I'd agree - we would want SELinux > > policy applied on the server as well as the client to ensure that the > > data is being protected consistently throughout and that the server is > > not misrepresenting the security guarantees expected by the clients. > > Providing an illusion of confinement on each client without any > > corresponding protection on the server system would be very prone to > > bypass. For the latter, the kernel can only truly confine application > > code, not in-kernel threads, although we can subject the in-kernel nfsd > > to permission checking as a robustness check. We've always noted that > > SELinux does depend on the correctness of the kernel. > > Oh, you're saying that this threat is out-of-scope? ;-) Kernel flaws aren't something we can address (reliably and in general) via a kernel mechanism. Versus a threat that can be addressed by kernel mechanism, like providing complete mediation and unambiguous access control. There is a difference. And we aren't ignoring the kernel correctness problem - there is separate work in that space, but it requires separate mechanism outside of SELinux itself. > Note that here we've already strayed from the focus of the discussion; > we're no longer arguing "the implementation is ugly/broken", but you're > claiming "doesn't do what I need" - which I'm not disagreeing with. It > doesn't do what you want. Which is why you have SELinux, and it's going > to stay. Fine. > > If we assume that the users who run it do have a need / use case for it > which they can't solve differently, we should really get back to the > discussion of how those needs can be met or provided by Linux in a > feasible way. Part of the discussion has been whether those users' needs could be solved better via SELinux, whether via improved userspace tools (ala seedit possibly with an enhanced restorecond) or via extended kernel mechanism (ala named type transitions and some kind of inheritance model). It does however seem like there is a fundamental conflict there on renaming behavior; I do not believe that file protections should automatically change in the kernel upon rename and should require explicit userspace action. The question though is whether that renaming behavior in AA is truly a user requirement or a manufactured (i.e. made-up) one, and whether it is truly a runtime requirement or just a policy creation time one (the latter being adequately addressed by userspace relabeling). If that behavior is truly needed (a point I wouldn't concede), then the discussion does reduce down to the right implementation method. There it appears that the primary objection is to regenerating full pathname strings and matching them versus some kind of incremental matching either during lookup itself or via a reverse match as suggested. That discussion is principally one in which the vfs folks should be engaged, not me. > > > Your use case mandates complete system-wide mediation, because you want > > > full data flow analysis. Mine doesn't. > > Then yours isn't mandatory access control, nor is it confinement. > > I apologize for not using the word "confinement" in the way you expect > it to be used. I certainly don't want to imply it does do things it > doesn't. Keep in mind I'm not a native speaker, so nuances do get lost > sometimes; nor do I have long years of experience in the security > field. Thanks for clearing this up. > > So agreed, it is not confinement nor MAC. > > Would it be more appropriate if I used the word "restricts" or > "constrains"? Yes. Or simply "controls file accesses and capability usage". -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote: > The issue arises even for a collection of collaborating confined > processes with different profiles, and the collaboration may be > intentional or unintentional (in the latter case, one of the confined > processes may be taking advantage of known behavior of another process > and shared access by both to some resource in order to induce a > particular behavior in that process). Point taken; the point remains is that you need at least several (intentionally or not) cooperating processes. The chances of this are significantly lower than a single process exploit. > And remember that confinement isn't just about limiting untrusted > processes but also about protecting trusted processes; limiting the > inputs and outputs of a trusted process can be just as important to > preventing exploitation. True. It'd appear that if you want that, you'd specify the AA profile so that it doesn't include directories/files writable by untrusted processes. > Sorry, do you mean the "server" as in the "server system" or as in the > "server daemon"? For the former, I'd agree - we would want SELinux > policy applied on the server as well as the client to ensure that the > data is being protected consistently throughout and that the server is > not misrepresenting the security guarantees expected by the clients. > Providing an illusion of confinement on each client without any > corresponding protection on the server system would be very prone to > bypass. For the latter, the kernel can only truly confine application > code, not in-kernel threads, although we can subject the in-kernel nfsd > to permission checking as a robustness check. We've always noted that > SELinux does depend on the correctness of the kernel. Oh, you're saying that this threat is out-of-scope? ;-) > Every time we've noted an issue with AA, the answer has been that it is > out of scope. Yet the public documentation for AA misrepresents the > situation and its comparisons with SELinux conveniently ignore its > limitations. I'm sorry. Again, I'm not responsible for marketing comparisons made by anyone else, nor do I think they should apply to this discussion where we're discussing the merits of what AA actually _does_; not what someone's marketing claims it does - otherwise I'll go dig out marketing claims about SELinux too ;-) And, coming at it from that direction, I feel it does something useful. Note that here we've already strayed from the focus of the discussion; we're no longer arguing "the implementation is ugly/broken", but you're claiming "doesn't do what I need" - which I'm not disagreeing with. It doesn't do what you want. Which is why you have SELinux, and it's going to stay. Fine. If we assume that the users who run it do have a need / use case for it which they can't solve differently, we should really get back to the discussion of how those needs can be met or provided by Linux in a feasible way. > > Your use case mandates complete system-wide mediation, because you want > > full data flow analysis. Mine doesn't. > Then yours isn't mandatory access control, nor is it confinement. I apologize for not using the word "confinement" in the way you expect it to be used. I certainly don't want to imply it does do things it doesn't. Keep in mind I'm not a native speaker, so nuances do get lost sometimes; nor do I have long years of experience in the security field. Thanks for clearing this up. So agreed, it is not confinement nor MAC. Would it be more appropriate if I used the word "restricts" or "constrains"? Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote: > On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > > No the "incomplete" mediation does not flow from the design. We have > > > deliberately focused on doing the necessary modifications for pathname > > > based mediation. The IPC and network mediation are a wip. > > The fact that you have to go back to the drawing board for them is that > > you didn't get the abstraction right in the first place. > > That's an interesting claim, however I don't think it holds. AA was > designed to mediate file access in a form which is intuitive to admins. > > It's to be expected that it doesn't directly apply to mediating other > forms of access. > > > I think we must have different understandings of the words "generalize" > > and "analyzable". Look, if I want to be able to state properties about > > data flow in the system for confidentiality or integrity goals (my > > secret data can never leak to unauthorized entities, my critical data > > can never be corrupted/tainted by unauthorized entities - directly or > > indirectly), > > I seem to think that this is not what AA is trying to do, so evaluating > it in that context doesn't seem useful. It's like saying a screw driver > isn't a hammer, so it is useless because you have a nail. Again, in that case, please remove all uses of the terms "mandatory access control", "confinement" and "integrity protection" from AA documentation and code. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote: > On 2007-06-22T07:19:39, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > > > Or can access the data under a different path to which their profile > > > > does give them access, whether in its final destination or in some > > > > temporary file processed along the way. > > > Well, yes. That is intentional. > > > > > > Your point is? > > > > It may very well be unintentional access, especially when taking into > > account wildcards in profiles and user-writable directories. > > Again, you're saying that AA is not confining unconfined processes. > That's a given. If unconfined processes assist confined processes in > breeching their confinement, yes, that is not mediated. The issue arises even for a collection of collaborating confined processes with different profiles, and the collaboration may be intentional or unintentional (in the latter case, one of the confined processes may be taking advantage of known behavior of another process and shared access by both to some resource in order to induce a particular behavior in that process). And remember that confinement isn't just about limiting untrusted processes but also about protecting trusted processes; limiting the inputs and outputs of a trusted process can be just as important to preventing exploitation. > You're basically saying that anything but system-wide mandatory access > control is pointless. Mandatory access control as historically understood has always meant system-wide. As well as always being based on the security properties of the data (so that global and persistent protection of the data is possible). You can't actually use the terms 'mandatory access control' or 'confinement' for AppArmor unless you redefine them. > If you want to go down that route, what is your reply to me saying that > SELinux cannot mediate NFS mounts - if the server is not confined using > SELinux as well? The argument is really, really moot and pointless. Yes, > unconfined actions can affect confined processes. Sorry, do you mean the "server" as in the "server system" or as in the "server daemon"? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel. > > > That is an interesting argument, but not what we're discussing here. > > > We're arguing filesystem access mediation. > > IOW, anything that AA cannot protect against is "out of scope". An easy > > escape from any criticism. > > I'm quite sure that this reply is not AA specific as you try to make it > appear. Every time we've noted an issue with AA, the answer has been that it is out of scope. Yet the public documentation for AA misrepresents the situation and its comparisons with SELinux conveniently ignore its limitations. > > > Yes. Your use case is different than mine. > > My use case is being able to protect data reliably. Yours? > > I want to restrict certain possibly untrusted applications and > network-facing services from accessing certain file patterns, because as > a user and admin, that's the mindset I'm used to. I might be interested > in mediating other channels too, but the files are what I really care > about. I'm inclined to trust the other processes. > > Your use case mandates complete system-wide mediation, because you want > full data flow analysis. Mine doesn't. Then yours isn't mandatory access control, nor is it confinement. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > No the "incomplete" mediation does not flow from the design. We have > > deliberately focused on doing the necessary modifications for pathname > > based mediation. The IPC and network mediation are a wip. > The fact that you have to go back to the drawing board for them is that > you didn't get the abstraction right in the first place. That's an interesting claim, however I don't think it holds. AA was designed to mediate file access in a form which is intuitive to admins. It's to be expected that it doesn't directly apply to mediating other forms of access. > I think we must have different understandings of the words "generalize" > and "analyzable". Look, if I want to be able to state properties about > data flow in the system for confidentiality or integrity goals (my > secret data can never leak to unauthorized entities, my critical data > can never be corrupted/tainted by unauthorized entities - directly or > indirectly), I seem to think that this is not what AA is trying to do, so evaluating it in that context doesn't seem useful. It's like saying a screw driver isn't a hammer, so it is useless because you have a nail. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote: > On Thu, 21 Jun 2007, Chris Mason wrote: > > > > The incomplete mediation flows from the design, since the pathname-based > > > mediation doesn't generalize to cover all objects unlike label- or > > > attribute-based mediation. And the "use the natural abstraction for > > > each object type" approach likewise doesn't yield any general model or > > > anything that you can analyze systematically for data flow. > > > > This feels quite a lot like a repeat of the discussion at the kernel > > summit. There are valid uses for path based security, and if they don't > > fit your needs, please don't use them. But, path based semantics alone > > are not a valid reason to shut out AA. > > The validity or otherwise of pathname access control is not being > discussed here. > > The point is that the pathname model does not generalize, and that > AppArmor's inability to provide adequate coverage of the system is a > design issue arising from this. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 2007-06-21 at 22:17 -0600, Crispin Cowan wrote: > James Morris wrote: > > On Thu, 21 Jun 2007, Chris Mason wrote: > >>> The incomplete mediation flows from the design, since the pathname-based > >>> mediation doesn't generalize to cover all objects unlike label- or > >>> attribute-based mediation. And the "use the natural abstraction for > >>> each object type" approach likewise doesn't yield any general model or > >>> anything that you can analyze systematically for data flow. > >>> > >> This feels quite a lot like a repeat of the discussion at the kernel > >> summit. There are valid uses for path based security, and if they don't > >> fit your needs, please don't use them. But, path based semantics alone > >> are not a valid reason to shut out AA. > >> > > The validity or otherwise of pathname access control is not being > > discussed here. > > > > The point is that the pathname model does not generalize, and that > > AppArmor's inability to provide adequate coverage of the system is a > > design issue arising from this. > > > The above two paragraphs appear to contradict each other. > > > Recall that the question asked by Lars was whether there were any > > outstanding technical issues relating to AppArmor. > > > > AppArmor does not and can not provide the level of confinement claimed by > > the documentation, and its policy does not reflect its actual confinement > > properties. That's kind of a technical issue, right? > > > So if the document said "confinement with respect to direct file access > and POSIX.1e capabilities" and that list got extended as AA got new > confinement features, would that address your issue? That would certainly help, although one might quibble with the use of the word "confinement" at all wrt AppArmor (it has a long-established technical meaning that implies information flow control, and that goes beyond even complete mediation - it requires global and persistent protection of the data based on its properties, which requires stable and unambiguous identifiers). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: > On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: > > On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: > > > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote: > > > > > > > > And now, yes, I know AA doesn't mediate IPC or networking (yet), but > > > that's a missing feature, not broken by design. > > > > The incomplete mediation flows from the design, since the pathname-based > > mediation doesn't generalize to cover all objects unlike label- or > > attribute-based mediation. And the "use the natural abstraction for > > each object type" approach likewise doesn't yield any general model or > > anything that you can analyze systematically for data flow. > > > No the "incomplete" mediation does not flow from the design. We have > deliberately focused on doing the necessary modifications for pathname > based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. > We have never claimed to be using pathname-based mediation IPC or networking. > The "natural abstraction" approach does generize well enough and will > be analyzable. I think we must have different understandings of the words "generalize" and "analyzable". Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), then I need to be able to have a common reference point for my policy. When my policy is based on different abstractions (pathnames, IP addresses, window ids, whatever) for different objects, then I can no longer identify how data can flow throughout the system in a system-wide way. > > Um, no. It might not be able to directly open files via that path, but > > showing that it can never read or write your mail is a rather different > > matter. > > > Actually it can be analyzed and shown. It is ugly to do and we > currently don't have a tool capable of doing it, but it is possible. No, it isn't possible when using ambiguous and unstable identifiers for the subjects and objects, nor when mediation is incomplete. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 21:34 +1000, Neil Brown wrote: > On Friday June 22, [EMAIL PROTECTED] wrote: > > > > > > Yes. Your use case is different than mine. > > > > My use case is being able to protect data reliably. Yours? > > Saying "protect data" is nearly meaningless without a threat model. > I bet you don't try to protect data from a direct nuclear hit, or a > court order. > > > AA has a fairly clear threat model. It involves a flaw in a > program being used by an external agent to cause it to use > privileges it would not normally exercise to subvert privacy or > integrity. > I think this model matches a lot of real threats that real sysadmins > have real concerns about. I believe that the design of AA addresses > this model quite well. > > > What is your threat model? Maybe it is just different. The threat "model" you describe above is a subset of what SELinux addresses. And our argument is that AA does not meet that model well, because it relies upon ambiguous and unstable identifiers for subjects and objects (a violation of the fundamental requirements for access control) and because it provides very incomplete mediation. >From http://www.nsa.gov/selinux/info/faq.cfm: The Security-enhanced Linux's new features are designed to enforce the separation of information based on confidentiality and integrity requirements. They are designed for preventing processes from reading data and programs, tampering with data and programs, bypassing application security mechanisms, executing untrustworthy programs, or interfering with other processes in violation of the system security policy. They also help to confine the potential damage that can be caused by malicious or flawed programs. They should also be useful for enabling a single system to be used by users with differing security authorizations to access multiple kinds of information with differing security requirements without compromising those security requirements. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-22T07:19:39, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > Or can access the data under a different path to which their profile > > > does give them access, whether in its final destination or in some > > > temporary file processed along the way. > > Well, yes. That is intentional. > > > > Your point is? > > It may very well be unintentional access, especially when taking into > account wildcards in profiles and user-writable directories. Again, you're saying that AA is not confining unconfined processes. That's a given. If unconfined processes assist confined processes in breeching their confinement, yes, that is not mediated. You're basically saying that anything but system-wide mandatory access control is pointless. If you want to go down that route, what is your reply to me saying that SELinux cannot mediate NFS mounts - if the server is not confined using SELinux as well? The argument is really, really moot and pointless. Yes, unconfined actions can affect confined processes. That's generally true for _any_ security system. > > That is an interesting argument, but not what we're discussing here. > > We're arguing filesystem access mediation. > IOW, anything that AA cannot protect against is "out of scope". An easy > escape from any criticism. I'm quite sure that this reply is not AA specific as you try to make it appear. > > Yes. Your use case is different than mine. > My use case is being able to protect data reliably. Yours? I want to restrict certain possibly untrusted applications and network-facing services from accessing certain file patterns, because as a user and admin, that's the mindset I'm used to. I might be interested in mediating other channels too, but the files are what I really care about. I'm inclined to trust the other processes. Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Friday June 22, [EMAIL PROTECTED] wrote: > > > > Yes. Your use case is different than mine. > > My use case is being able to protect data reliably. Yours? Saying "protect data" is nearly meaningless without a threat model. I bet you don't try to protect data from a direct nuclear hit, or a court order. AA has a fairly clear threat model. It involves a flaw in a program being used by an external agent to cause it to use privileges it would not normally exercise to subvert privacy or integrity. I think this model matches a lot of real threats that real sysadmins have real concerns about. I believe that the design of AA addresses this model quite well. What is your threat model? Maybe it is just different. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote: > On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > Or can access the data under a different path to which their profile > > does give them access, whether in its final destination or in some > > temporary file processed along the way. > > Well, yes. That is intentional. > > Your point is? It may very well be unintentional access, especially when taking into account wildcards in profiles and user-writable directories. > > The emphasis on never modifying applications for security in AA likewise > > has an adverse impact here, as you will ultimately have to deal with > > application mediation of access to their own objects and operations not > > directly visible to the kernel (as we have already done in SELinux for > > D-BUS and others and are doing for X). Otherwise, your "protection" of > > desktop applications is easily subverted. > > That is an interesting argument, but not what we're discussing here. > We're arguing filesystem access mediation. IOW, anything that AA cannot protect against is "out of scope". An easy escape from any criticism. > > Um, no. It might not be able to directly open files via that path, but > > showing that it can never read or write your mail is a rather different > > matter. > > Yes. Your use case is different than mine. My use case is being able to protect data reliably. Yours? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-21T23:45:36, Joshua Brindle <[EMAIL PROTECTED]> wrote: > >remember, the policies define a white-list > > Except for unconfined processes. The argument that AA doesn't mediate what it is not configured to mediate is correct, yes, but I don't think that's a valid _design_ issue with AA. > Or through IPC or the network, that is the point, filesystem only > coverage doesn't cut it; there is no way to say the browser can't access > the users mail in AA, and there never will be. We have a variety of filtering mechanisms which are specific to a domain. iptables filters networking only; file permissions filter file access only. This argument is not really strong. If you're now arguing the "spirit of Unix", I can turn your argument around too: the Unix spirit is to have smallish dedicated tools. If AA is dedicated to mediating file access, isn't that nice! AA _could_ be extended to mediate network access and IPC (and this is WIP). If we had tcpfs and ipcfs - you know, everything is a filesystem, the Linux spirit! ;-) - AA could mediate them as well. However, we're discussing the way it mediates file accesses here, for which it appears useful and capable of functionality which SELinux's approach cannot provide. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Saturday 16 June 2007 02:20, Pavel Machek wrote: > Ok, so mv gets slower for big trees... and open() gets faster for deep > trees. Previously, open in current directory was one atomic read of > directory entry, now it has to read directory, and its parent, and its > parent parent, and its... > > (Or am I wrong and getting full path does not need to bring anything > in, not even in cache-cold case?) You are wrong, indeed. The dentries in the dcache are connected to the dcache through their parent dentry pointers, which means that the parent dentries are always in memory, too. No I/O is involved for walking up dentry trees. (Caveat: nfsd does allow disconnected dentries. It does not make sense to try confining an in-kernel daemon though, an no user process can ever access a dentry before it gets connected (lookup does that), so this difference is irrelevant here.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: > On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: > > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote: > > > > > And now, yes, I know AA doesn't mediate IPC or networking (yet), but > > that's a missing feature, not broken by design. > > The incomplete mediation flows from the design, since the pathname-based > mediation doesn't generalize to cover all objects unlike label- or > attribute-based mediation. And the "use the natural abstraction for > each object type" approach likewise doesn't yield any general model or > anything that you can analyze systematically for data flow. > No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. We have never claimed to be using pathname-based mediation IPC or networking. The "natural abstraction" approach does generize well enough and will be analyzable. > The emphasis on never modifying applications for security in AA likewise > has an adverse impact here, as you will ultimately have to deal with > application mediation of access to their own objects and operations not > directly visible to the kernel (as we have already done in SELinux for > D-BUS and others and are doing for X). Otherwise, your "protection" of > desktop applications is easily subverted. > yes of course, we realize that dbus and X must be trusted applications, this to will happen. But it will happen piece meal, something about releasing early and often comes to mind. > > > You might define this as a non-technical issue, but the fact that > > > AppArmor > > > simply does not and can not work is a fairly significant consideration, I > > > would imagine. > > > > If I restrict my Mozilla to not access my on-disk mail folder, it can't > > get there. (Barring bugs in programs which Mozilla is allowed to run > > unconfined, sure.) > > Um, no. It might not be able to directly open files via that path, but > showing that it can never read or write your mail is a rather different > matter. > Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible. pgpEzVUkLX82R.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote: > On Thu, 21 Jun 2007, Chris Mason wrote: > > > > The incomplete mediation flows from the design, since the pathname-based > > > mediation doesn't generalize to cover all objects unlike label- or > > > attribute-based mediation. And the "use the natural abstraction for > > > each object type" approach likewise doesn't yield any general model or > > > anything that you can analyze systematically for data flow. > > > > This feels quite a lot like a repeat of the discussion at the kernel > > summit. There are valid uses for path based security, and if they don't > > fit your needs, please don't use them. But, path based semantics alone > > are not a valid reason to shut out AA. > > The validity or otherwise of pathname access control is not being > discussed here. > > The point is that the pathname model does not generalize, and that > AppArmor's inability to provide adequate coverage of the system is a > design issue arising from this. > As we have previously stated we are not using pathnames for IPC. The use of pathnames for file access mediation is not a design issue that in anyway prevents us from extending AppArmor to mediate IPC or networking. The current focus is making the revision necessary for AppArmor's file mediation at which point we can focus on finishing of the network and IPC support. > Recall that the question asked by Lars was whether there were any > outstanding technical issues relating to AppArmor. > > AppArmor does not and can not provide the level of confinement claimed by > the documentation, and its policy does not reflect its actual confinement > properties. That's kind of a technical issue, right? > AppArmor currently controls file and capabilities, which was explicitly stated in the documentation submitted with the patches. And it has been posted before that network and IPC mediation are a wip. pgpbhVE7Qk5ek.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote: On Thu, 21 Jun 2007, Chris Mason wrote: The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. As we have previously stated we are not using pathnames for IPC. The use of pathnames for file access mediation is not a design issue that in anyway prevents us from extending AppArmor to mediate IPC or networking. The current focus is making the revision necessary for AppArmor's file mediation at which point we can focus on finishing of the network and IPC support. Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor. AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right? AppArmor currently controls file and capabilities, which was explicitly stated in the documentation submitted with the patches. And it has been posted before that network and IPC mediation are a wip. pgpbhVE7Qk5ek.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-21T15:42:28, James Morris [EMAIL PROTECTED] wrote: And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. No the incomplete mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. We have never claimed to be using pathname-based mediation IPC or networking. The natural abstraction approach does generize well enough and will be analyzable. The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your protection of desktop applications is easily subverted. yes of course, we realize that dbus and X must be trusted applications, this to will happen. But it will happen piece meal, something about releasing early and often comes to mind. You might define this as a non-technical issue, but the fact that AppArmor simply does not and can not work is a fairly significant consideration, I would imagine. If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.) Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible. pgpEzVUkLX82R.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Saturday 16 June 2007 02:20, Pavel Machek wrote: Ok, so mv gets slower for big trees... and open() gets faster for deep trees. Previously, open in current directory was one atomic read of directory entry, now it has to read directory, and its parent, and its parent parent, and its... (Or am I wrong and getting full path does not need to bring anything in, not even in cache-cold case?) You are wrong, indeed. The dentries in the dcache are connected to the dcache through their parent dentry pointers, which means that the parent dentries are always in memory, too. No I/O is involved for walking up dentry trees. (Caveat: nfsd does allow disconnected dentries. It does not make sense to try confining an in-kernel daemon though, an no user process can ever access a dentry before it gets connected (lookup does that), so this difference is irrelevant here.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-21T23:45:36, Joshua Brindle [EMAIL PROTECTED] wrote: remember, the policies define a white-list Except for unconfined processes. The argument that AA doesn't mediate what it is not configured to mediate is correct, yes, but I don't think that's a valid _design_ issue with AA. Or through IPC or the network, that is the point, filesystem only coverage doesn't cut it; there is no way to say the browser can't access the users mail in AA, and there never will be. We have a variety of filtering mechanisms which are specific to a domain. iptables filters networking only; file permissions filter file access only. This argument is not really strong. tangent If you're now arguing the spirit of Unix, I can turn your argument around too: the Unix spirit is to have smallish dedicated tools. If AA is dedicated to mediating file access, isn't that nice! AA _could_ be extended to mediate network access and IPC (and this is WIP). If we had tcpfs and ipcfs - you know, everything is a filesystem, the Linux spirit! ;-) - AA could mediate them as well. /tangent However, we're discussing the way it mediates file accesses here, for which it appears useful and capable of functionality which SELinux's approach cannot provide. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote: On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote: Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way. Well, yes. That is intentional. Your point is? It may very well be unintentional access, especially when taking into account wildcards in profiles and user-writable directories. The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your protection of desktop applications is easily subverted. That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation. IOW, anything that AA cannot protect against is out of scope. An easy escape from any criticism. Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Yes. Your use case is different than mine. My use case is being able to protect data reliably. Yours? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-22T07:19:39, Stephen Smalley [EMAIL PROTECTED] wrote: Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way. Well, yes. That is intentional. Your point is? It may very well be unintentional access, especially when taking into account wildcards in profiles and user-writable directories. Again, you're saying that AA is not confining unconfined processes. That's a given. If unconfined processes assist confined processes in breeching their confinement, yes, that is not mediated. You're basically saying that anything but system-wide mandatory access control is pointless. If you want to go down that route, what is your reply to me saying that SELinux cannot mediate NFS mounts - if the server is not confined using SELinux as well? The argument is really, really moot and pointless. Yes, unconfined actions can affect confined processes. That's generally true for _any_ security system. That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation. IOW, anything that AA cannot protect against is out of scope. An easy escape from any criticism. I'm quite sure that this reply is not AA specific as you try to make it appear. Yes. Your use case is different than mine. My use case is being able to protect data reliably. Yours? I want to restrict certain possibly untrusted applications and network-facing services from accessing certain file patterns, because as a user and admin, that's the mindset I'm used to. I might be interested in mediating other channels too, but the files are what I really care about. I'm inclined to trust the other processes. Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 21:34 +1000, Neil Brown wrote: On Friday June 22, [EMAIL PROTECTED] wrote: Yes. Your use case is different than mine. My use case is being able to protect data reliably. Yours? Saying protect data is nearly meaningless without a threat model. I bet you don't try to protect data from a direct nuclear hit, or a court order. AA has a fairly clear threat model. It involves a flaw in a program being used by an external agent to cause it to use privileges it would not normally exercise to subvert privacy or integrity. I think this model matches a lot of real threats that real sysadmins have real concerns about. I believe that the design of AA addresses this model quite well. What is your threat model? Maybe it is just different. The threat model you describe above is a subset of what SELinux addresses. And our argument is that AA does not meet that model well, because it relies upon ambiguous and unstable identifiers for subjects and objects (a violation of the fundamental requirements for access control) and because it provides very incomplete mediation. From http://www.nsa.gov/selinux/info/faq.cfm: The Security-enhanced Linux's new features are designed to enforce the separation of information based on confidentiality and integrity requirements. They are designed for preventing processes from reading data and programs, tampering with data and programs, bypassing application security mechanisms, executing untrustworthy programs, or interfering with other processes in violation of the system security policy. They also help to confine the potential damage that can be caused by malicious or flawed programs. They should also be useful for enabling a single system to be used by users with differing security authorizations to access multiple kinds of information with differing security requirements without compromising those security requirements. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-21T15:42:28, James Morris [EMAIL PROTECTED] wrote: And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. No the incomplete mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. We have never claimed to be using pathname-based mediation IPC or networking. The natural abstraction approach does generize well enough and will be analyzable. I think we must have different understandings of the words generalize and analyzable. Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), then I need to be able to have a common reference point for my policy. When my policy is based on different abstractions (pathnames, IP addresses, window ids, whatever) for different objects, then I can no longer identify how data can flow throughout the system in a system-wide way. Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible. No, it isn't possible when using ambiguous and unstable identifiers for the subjects and objects, nor when mediation is incomplete. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Friday June 22, [EMAIL PROTECTED] wrote: Yes. Your use case is different than mine. My use case is being able to protect data reliably. Yours? Saying protect data is nearly meaningless without a threat model. I bet you don't try to protect data from a direct nuclear hit, or a court order. AA has a fairly clear threat model. It involves a flaw in a program being used by an external agent to cause it to use privileges it would not normally exercise to subvert privacy or integrity. I think this model matches a lot of real threats that real sysadmins have real concerns about. I believe that the design of AA addresses this model quite well. What is your threat model? Maybe it is just different. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote: On Thu, 21 Jun 2007, Chris Mason wrote: The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 2007-06-21 at 22:17 -0600, Crispin Cowan wrote: James Morris wrote: On Thu, 21 Jun 2007, Chris Mason wrote: The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. The above two paragraphs appear to contradict each other. Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor. AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right? So if the document said confinement with respect to direct file access and POSIX.1e capabilities and that list got extended as AA got new confinement features, would that address your issue? That would certainly help, although one might quibble with the use of the word confinement at all wrt AppArmor (it has a long-established technical meaning that implies information flow control, and that goes beyond even complete mediation - it requires global and persistent protection of the data based on its properties, which requires stable and unambiguous identifiers). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-22T07:53:47, Stephen Smalley [EMAIL PROTECTED] wrote: No the incomplete mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. That's an interesting claim, however I don't think it holds. AA was designed to mediate file access in a form which is intuitive to admins. It's to be expected that it doesn't directly apply to mediating other forms of access. I think we must have different understandings of the words generalize and analyzable. Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), I seem to think that this is not what AA is trying to do, so evaluating it in that context doesn't seem useful. It's like saying a screw driver isn't a hammer, so it is useless because you have a nail. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote: On 2007-06-22T07:53:47, Stephen Smalley [EMAIL PROTECTED] wrote: No the incomplete mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. That's an interesting claim, however I don't think it holds. AA was designed to mediate file access in a form which is intuitive to admins. It's to be expected that it doesn't directly apply to mediating other forms of access. I think we must have different understandings of the words generalize and analyzable. Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), I seem to think that this is not what AA is trying to do, so evaluating it in that context doesn't seem useful. It's like saying a screw driver isn't a hammer, so it is useless because you have a nail. Again, in that case, please remove all uses of the terms mandatory access control, confinement and integrity protection from AA documentation and code. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote: On 2007-06-22T07:19:39, Stephen Smalley [EMAIL PROTECTED] wrote: Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way. Well, yes. That is intentional. Your point is? It may very well be unintentional access, especially when taking into account wildcards in profiles and user-writable directories. Again, you're saying that AA is not confining unconfined processes. That's a given. If unconfined processes assist confined processes in breeching their confinement, yes, that is not mediated. The issue arises even for a collection of collaborating confined processes with different profiles, and the collaboration may be intentional or unintentional (in the latter case, one of the confined processes may be taking advantage of known behavior of another process and shared access by both to some resource in order to induce a particular behavior in that process). And remember that confinement isn't just about limiting untrusted processes but also about protecting trusted processes; limiting the inputs and outputs of a trusted process can be just as important to preventing exploitation. You're basically saying that anything but system-wide mandatory access control is pointless. Mandatory access control as historically understood has always meant system-wide. As well as always being based on the security properties of the data (so that global and persistent protection of the data is possible). You can't actually use the terms 'mandatory access control' or 'confinement' for AppArmor unless you redefine them. If you want to go down that route, what is your reply to me saying that SELinux cannot mediate NFS mounts - if the server is not confined using SELinux as well? The argument is really, really moot and pointless. Yes, unconfined actions can affect confined processes. Sorry, do you mean the server as in the server system or as in the server daemon? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel. That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation. IOW, anything that AA cannot protect against is out of scope. An easy escape from any criticism. I'm quite sure that this reply is not AA specific as you try to make it appear. Every time we've noted an issue with AA, the answer has been that it is out of scope. Yet the public documentation for AA misrepresents the situation and its comparisons with SELinux conveniently ignore its limitations. Yes. Your use case is different than mine. My use case is being able to protect data reliably. Yours? I want to restrict certain possibly untrusted applications and network-facing services from accessing certain file patterns, because as a user and admin, that's the mindset I'm used to. I might be interested in mediating other channels too, but the files are what I really care about. I'm inclined to trust the other processes. Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't. Then yours isn't mandatory access control, nor is it confinement. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-22T08:41:51, Stephen Smalley [EMAIL PROTECTED] wrote: The issue arises even for a collection of collaborating confined processes with different profiles, and the collaboration may be intentional or unintentional (in the latter case, one of the confined processes may be taking advantage of known behavior of another process and shared access by both to some resource in order to induce a particular behavior in that process). Point taken; the point remains is that you need at least several (intentionally or not) cooperating processes. The chances of this are significantly lower than a single process exploit. And remember that confinement isn't just about limiting untrusted processes but also about protecting trusted processes; limiting the inputs and outputs of a trusted process can be just as important to preventing exploitation. True. It'd appear that if you want that, you'd specify the AA profile so that it doesn't include directories/files writable by untrusted processes. Sorry, do you mean the server as in the server system or as in the server daemon? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel. Oh, you're saying that this threat is out-of-scope? ;-) Every time we've noted an issue with AA, the answer has been that it is out of scope. Yet the public documentation for AA misrepresents the situation and its comparisons with SELinux conveniently ignore its limitations. I'm sorry. Again, I'm not responsible for marketing comparisons made by anyone else, nor do I think they should apply to this discussion where we're discussing the merits of what AA actually _does_; not what someone's marketing claims it does - otherwise I'll go dig out marketing claims about SELinux too ;-) And, coming at it from that direction, I feel it does something useful. Note that here we've already strayed from the focus of the discussion; we're no longer arguing the implementation is ugly/broken, but you're claiming doesn't do what I need - which I'm not disagreeing with. It doesn't do what you want. Which is why you have SELinux, and it's going to stay. Fine. If we assume that the users who run it do have a need / use case for it which they can't solve differently, we should really get back to the discussion of how those needs can be met or provided by Linux in a feasible way. Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't. Then yours isn't mandatory access control, nor is it confinement. I apologize for not using the word confinement in the way you expect it to be used. I certainly don't want to imply it does do things it doesn't. Keep in mind I'm not a native speaker, so nuances do get lost sometimes; nor do I have long years of experience in the security field. Thanks for clearing this up. So agreed, it is not confinement nor MAC. Would it be more appropriate if I used the word restricts or constrains? Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, Chris Mason wrote: The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. There are two distinct concepts here. A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves. Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc. Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door. What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of set your house into a rock wall so there is only one path to it. B. Pathname access control as a general abstraction for OS security. Which is what was being discussed above, in response to a question from Lars about technical issues, and that this _model_ doesn't generalize to the rest of the OS, regardless of whether you think the mechanism of pathname labeling itself is appropriate or not. In any case, clarifying such a distinction should not obscure the central issue, which is: AppArmor's design is broken. General users, many kernel developers, and even security researchers who have not yet looked under the covers [1], are probably unaware that the confinement claims being made about AppArmor's confinement capabilities are simply not possible with either its model or implementation. To quote from: http://www.novell.com/linux/security/apparmor/ AppArmor gives you network application security via mandatory access control for programs, protecting against the exploitation of software flaws and compromised systems. AppArmor includes everything you need to provide effective containment for programs (including those that run as root) to thwart attempted exploits and even zero-day attacks. This is not accurate in any sense of the term containment of mandatory access control that I've previously encountered. The fact that it doesn't work as expected does not arise simply from missing features or being different. It arises from the design of the system, which uses a pathname abstraction, where, even if we agree to ignore issue (1) above, still does not work, because only filesystem interactions are mediated. AppArmor policy does not reflect the behavior of the system. The simple policy that users can so effortlessly manipulate is simple because it is wrong, and deliberately so. The design of the AppArmor is based on _appearing simple_, but at the expense of completeness and thus correctness. [1] http://lkml.org/lkml/2007/4/19/357 My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? - David Wagner, http://www.cs.berkeley.edu/~daw/ Indeed. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-22T08:41:51, Stephen Smalley [EMAIL PROTECTED] wrote: Sorry, do you mean the server as in the server system or as in the server daemon? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel. Oh, you're saying that this threat is out-of-scope? ;-) Kernel flaws aren't something we can address (reliably and in general) via a kernel mechanism. Versus a threat that can be addressed by kernel mechanism, like providing complete mediation and unambiguous access control. There is a difference. And we aren't ignoring the kernel correctness problem - there is separate work in that space, but it requires separate mechanism outside of SELinux itself. Note that here we've already strayed from the focus of the discussion; we're no longer arguing the implementation is ugly/broken, but you're claiming doesn't do what I need - which I'm not disagreeing with. It doesn't do what you want. Which is why you have SELinux, and it's going to stay. Fine. If we assume that the users who run it do have a need / use case for it which they can't solve differently, we should really get back to the discussion of how those needs can be met or provided by Linux in a feasible way. Part of the discussion has been whether those users' needs could be solved better via SELinux, whether via improved userspace tools (ala seedit possibly with an enhanced restorecond) or via extended kernel mechanism (ala named type transitions and some kind of inheritance model). It does however seem like there is a fundamental conflict there on renaming behavior; I do not believe that file protections should automatically change in the kernel upon rename and should require explicit userspace action. The question though is whether that renaming behavior in AA is truly a user requirement or a manufactured (i.e. made-up) one, and whether it is truly a runtime requirement or just a policy creation time one (the latter being adequately addressed by userspace relabeling). If that behavior is truly needed (a point I wouldn't concede), then the discussion does reduce down to the right implementation method. There it appears that the primary objection is to regenerating full pathname strings and matching them versus some kind of incremental matching either during lookup itself or via a reverse match as suggested. That discussion is principally one in which the vfs folks should be engaged, not me. Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't. Then yours isn't mandatory access control, nor is it confinement. I apologize for not using the word confinement in the way you expect it to be used. I certainly don't want to imply it does do things it doesn't. Keep in mind I'm not a native speaker, so nuances do get lost sometimes; nor do I have long years of experience in the security field. Thanks for clearing this up. So agreed, it is not confinement nor MAC. Would it be more appropriate if I used the word restricts or constrains? Yes. Or simply controls file accesses and capability usage. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote: On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-22T08:41:51, Stephen Smalley [EMAIL PROTECTED] wrote: Sorry, do you mean the server as in the server system or as in the server daemon? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel. Oh, you're saying that this threat is out-of-scope? ;-) Kernel flaws aren't something we can address (reliably and in general) via a kernel mechanism. Versus a threat that can be addressed by kernel mechanism, like providing complete mediation and unambiguous access control. There is a difference. And we aren't ignoring the kernel correctness problem - there is separate work in that space, but it requires separate mechanism outside of SELinux itself. Note that here we've already strayed from the focus of the discussion; we're no longer arguing the implementation is ugly/broken, but you're claiming doesn't do what I need - which I'm not disagreeing with. It doesn't do what you want. Which is why you have SELinux, and it's going to stay. Fine. If we assume that the users who run it do have a need / use case for it which they can't solve differently, we should really get back to the discussion of how those needs can be met or provided by Linux in a feasible way. Part of the discussion has been whether those users' needs could be solved better via SELinux, whether via improved userspace tools (ala seedit possibly with an enhanced restorecond) or via extended kernel mechanism (ala named type transitions and some kind of inheritance model). It does however seem like there is a fundamental conflict there on renaming behavior; I do not believe that file protections should automatically change in the kernel upon rename and should require explicit userspace action. The question though is whether that renaming behavior in AA is truly a user requirement or a manufactured (i.e. made-up) one, and whether it is truly a runtime requirement or just a policy creation time one (the latter being adequately addressed by userspace relabeling). I suppose there is also a question of whether that kind of model wouldn't be better implemented as an ACL model with implicit inheritance, e.g. if you specify an ACL on a directory, then all files accessed via that directory are controlled in accordance with that ACL unless they have their own more specific ACL, and if you move one of those files to a different directory, then they automatically pick up the protection of the new parent. Doesn't require the kernel to be matching pathname strings, just walking up the tree to determine the closest ancestor with an explicit ACL on it. If that behavior is truly needed (a point I wouldn't concede), then the discussion does reduce down to the right implementation method. There it appears that the primary objection is to regenerating full pathname strings and matching them versus some kind of incremental matching either during lookup itself or via a reverse match as suggested. That discussion is principally one in which the vfs folks should be engaged, not me. Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't. Then yours isn't mandatory access control, nor is it confinement. I apologize for not using the word confinement in the way you expect it to be used. I certainly don't want to imply it does do things it doesn't. Keep in mind I'm not a native speaker, so nuances do get lost sometimes; nor do I have long years of experience in the security field. Thanks for clearing this up. So agreed, it is not confinement nor MAC. Would it be more appropriate if I used the word restricts or constrains? Yes. Or simply controls file accesses and capability usage. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote: On Fri, 22 Jun 2007, Chris Mason wrote: The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. There are two distinct concepts here. A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves. Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc. Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door. What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of set your house into a rock wall so there is only one path to it. B. Pathname access control as a general abstraction for OS security. Which is what was being discussed above, in response to a question from Lars about technical issues, and that this _model_ doesn't generalize to the rest of the OS, regardless of whether you think the mechanism of pathname labeling itself is appropriate or not. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. I'm not trying to get into that discussion (I'm smart enough to know I'm far too stupid to hold my own there). I do understand that AA is different from selinux, and that you have valid points about the level and type of protection that AA offers. But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. We've been over the AA is different discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, Chris Mason wrote: But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one. Until people understand these issues, they certainly need to be addressed in the context of upstream merge. We've been over the AA is different discussion in threads about a billion times, and at the last kernel summit. I don't believe that people at the summit were adequately informed on the issue, and from several accounts I've heard, Stephen Smalley was effectively cut off before he could even get to his second slide. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? Keep in mind that this current thread arose from Greg KH asking about whether AppArmor could effectively be implemented via SELinux and userspace labeling. Some of us took the time to perform analysis and then provide feedback on this, in good faith. The underlying issues only came up again in response to an inflammatory post by Lars. If you want to avoid discussions of AppArmor's design, then I suggest taking it up with those who initiate them. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
--- Stephen Smalley [EMAIL PROTECTED] wrote: Mandatory access control as historically understood has always meant system-wide. Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control. Chapter and verse: TCSEC 3.2.1.4 Mandatory Access Control The TCB shall enforce a mandatory access control policy over all resources that are directly or indirectly accessible by subjects external to the TCB. The first reference is in the definition of a B1 system, while the second is for a B2 system. It was made clear to those of us doing TCSEC evaluations that there is a very real distintion between these two requirements. In the history that I've been through, starting in 1987, the B1 requirement has been read to allow for things that are not storage objects to be uncontrolled while the B2 requirement does not. If everything is a storage object, which is the approach everybody took, yes, you're looking at system wide. If, on the other hand, you were to take a different model approach and say that networking does not use storage objects you would not have to account for them under the B1 rules, while you would still have to for B2. Historically, no one succeeded with B2, and the mindset of B1 prevailed. So, historically, the understanding was that it was easier to declare everything a storage object and code up some MAC for it than it was to provide a security model that explained networking as it really works. I suggest that if AA wants to declare that as far as they are concerned sockets, ports, and packets are none of them storage objects but are instead pregnant weasels that is their peragotive as system designers and that a B1 evaluation team would have accepted that, provided sufficient evidence and explaination of the relevence of pregnant weasels was provided. It would not have worked at B2, but historically everyone understood that B2 was out of reach. Stephen is correct in that historically everyone implemented system that put everything under MAC, but is not in that it was well understood that if you could define something as not being a storage object you didn't have to submit it to MAC. Then as now it was easier to get people to code MAC than to get them to write papers about the security properties of pregnant weasels. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, Jun 22, 2007 at 10:23:03AM -0400, James Morris wrote: On Fri, 22 Jun 2007, Chris Mason wrote: But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one. Until people understand these issues, they certainly need to be addressed in the context of upstream merge. It is definitely useful to clearly understand the intended AA use cases during the merge. We've been over the AA is different discussion in threads about a billion times, and at the last kernel summit. I don't believe that people at the summit were adequately informed on the issue, and from several accounts I've heard, Stephen Smalley was effectively cut off before he could even get to his second slide. I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks So, yes Greg got it started and Lars is a well known trouble maker, and I completely understand if you want to say no thank you to an selinux based AA ;) The models are different and it shouldn't be a requirement that they try to use the same underlying mechanisms. -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, James Morris wrote: On Fri, 22 Jun 2007, Chris Mason wrote: But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one. Until people understand these issues, they certainly need to be addressed in the context of upstream merge. there are always going to be people who misunderstand things. by this logic nothing can ever be merged that can be misused. at least some of the intended audience (including me) do understand the limits and still consider the result useful. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 22 Jun 2007, Stephen Smalley wrote: On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-21T15:42:28, James Morris [EMAIL PROTECTED] wrote: And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. No the incomplete mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip. The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place. or it just means that the tool to regulat the network is different from the tool to regulate the filesystem. oh, by the way. that's how the rest of the *nix world works. firewall rules apply to networking, filesystem permissions and ACLs apply to the filesystem. this is like climing that the latest improvement to ipsec shouldn't go in becouse it down't allow you to handle things the same way that you handle temp files or a serial port. We have never claimed to be using pathname-based mediation IPC or networking. The natural abstraction approach does generize well enough and will be analyzable. I think we must have different understandings of the words generalize and analyzable. Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), then I need to be able to have a common reference point for my policy. When my policy is based on different abstractions (pathnames, IP addresses, window ids, whatever) for different objects, then I can no longer identify how data can flow throughout the system in a system-wide way. if you are doing a system-wide analysis then you are correct. the AA approach is to start with the exposed items and limit the damage that can be done to you. sysadmins already think in terms of paths and what can access that path (directory permissions), AA extends this in a very natural way and doesn't require any special tools or extra steps for normal administration. As a result sysadmins are far more likely to use this then they are to touch anything that requires that they do a full system analysis before they start. another advantage is that since the policies are independant of each other it becomes very easy for software to include sample policies with the source. Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible. No, it isn't possible when using ambiguous and unstable identifiers for the subjects and objects, nor when mediation is incomplete. it is possible to say that without assistance from an outside process the process cannot access the files containing your mail. if there is some other method of accessing the content no filesystem-level thing can know about it (for example, if another process is a pop server that requires no password). but I don't beleive that SELinux policies as distributed by any vendor would prevent this (yes, it would be possible for a tailored policy to prevent it, but if the policy is so complex that only distro staff should touch it that doesn't matter in real life) David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
* Chris Mason ([EMAIL PROTECTED]) wrote: I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions: 1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist. 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. 3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy). thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: > On Thu, 21 Jun 2007, Chris Mason wrote: >>> The incomplete mediation flows from the design, since the pathname-based >>> mediation doesn't generalize to cover all objects unlike label- or >>> attribute-based mediation. And the "use the natural abstraction for >>> each object type" approach likewise doesn't yield any general model or >>> anything that you can analyze systematically for data flow. >>> >> This feels quite a lot like a repeat of the discussion at the kernel >> summit. There are valid uses for path based security, and if they don't >> fit your needs, please don't use them. But, path based semantics alone >> are not a valid reason to shut out AA. >> > The validity or otherwise of pathname access control is not being > discussed here. > > The point is that the pathname model does not generalize, and that > AppArmor's inability to provide adequate coverage of the system is a > design issue arising from this. > The above two paragraphs appear to contradict each other. > Recall that the question asked by Lars was whether there were any > outstanding technical issues relating to AppArmor. > > AppArmor does not and can not provide the level of confinement claimed by > the documentation, and its policy does not reflect its actual confinement > properties. That's kind of a technical issue, right? > So if the document said "confinement with respect to direct file access and POSIX.1e capabilities" and that list got extended as AA got new confinement features, would that address your issue? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 21 Jun 2007, Joshua Brindle wrote: [EMAIL PROTECTED] wrote: On Thu, 21 Jun 2007, Joshua Brindle wrote: > Lars Marowsky-Bree wrote: > > On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > > > > > > > Um, no. It might not be able to directly open files via that > > path, but > > > showing that it can never read or write your mail is a rather > > different > > > matter. > > > > > Yes. Your use case is different than mine. > > > > So.. your use case is what? If an AA user asked you to protect his mail > from his browser I'm sure you'd truthfully answer "no, we can't do that > but we can protect the path to your mail from your browser".. I think > not. One need only look at the wonderful marketing literature for AA to > see what you are telling people it can do, and your above statement > isn't consistent with that, sorry. remember, the policies define a white-list Except for unconfined processes. correct, but we are talking about what a confined process can get to without assistance from an unconfined process. so if a hacker wants to have mozilla access the mail files he needs to get some other process on the sysstem to create a link or move a file to a path that mozilla does have access to. until that is done there is no way for mozilla to access the mail through the filesystem. other programs could be run that would give mozilla access to the mail contents, but it would be through some other path that the policy permitted mozilla accessing in the first place. Or through IPC or the network, that is the point, filesystem only coverage doesn't cut it; there is no way to say the browser can't access the users mail in AA, and there never will be. AA can be extended to cover these things in the future. remember 'release early release often'? how about 'perfect is the enemy of good enoug'? at this point they're trying to get the initial implementation in so that people can start takeing advantage of it. As a side effect the cost of maintaining it will decrease, and they can put effort into planning future enhancements. besides, as far as the network communication goes, doesn't netfilter now have a way to make rules for specific processes? if they don't then it could be added, but the details of the implementation would probably be very different from the current AA file controls. how does delaying the acceptance of the current implementation encourage the additional features being added? but to answer your two comments. how does mozilla access your mail over the network without first capturing your password from somewhere? as far as IPC goes, unix sockets are unavailable (AA as-is will control them), so you must be talking about signals or shared memory as the IPC mechanisms that mozilla would use to access your mail. please explain to me what mail client you are useing that exposes your mail via these mechinsms. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
[EMAIL PROTECTED] wrote: On Thu, 21 Jun 2007, Joshua Brindle wrote: Lars Marowsky-Bree wrote: On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote: > Um, no. It might not be able to directly open files via that path, but > showing that it can never read or write your mail is a rather different > matter. > Yes. Your use case is different than mine. So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry. remember, the policies define a white-list Except for unconfined processes. so if a hacker wants to have mozilla access the mail files he needs to get some other process on the sysstem to create a link or move a file to a path that mozilla does have access to. until that is done there is no way for mozilla to access the mail through the filesystem. other programs could be run that would give mozilla access to the mail contents, but it would be through some other path that the policy permitted mozilla accessing in the first place. Or through IPC or the network, that is the point, filesystem only coverage doesn't cut it; there is no way to say the browser can't access the users mail in AA, and there never will be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 21 Jun 2007, Chris Mason wrote: > > The incomplete mediation flows from the design, since the pathname-based > > mediation doesn't generalize to cover all objects unlike label- or > > attribute-based mediation. And the "use the natural abstraction for > > each object type" approach likewise doesn't yield any general model or > > anything that you can analyze systematically for data flow. > > This feels quite a lot like a repeat of the discussion at the kernel > summit. There are valid uses for path based security, and if they don't > fit your needs, please don't use them. But, path based semantics alone > are not a valid reason to shut out AA. The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor. AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: > On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: > > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote: > > > > > > A veto is not a technical argument. All technical arguments (except for > > > > "path name is ugly, yuk yuk!") have been addressed, have they not? > > > AppArmor doesn't actually provide confinement, because it only operates > > > on > > > filesystem objects. > > > > > > What you define in AppArmor policy does _not_ reflect the actual > > > confinement properties of the policy. Applications can simply use other > > > mechanisms to access objects, and the policy is effectively meaningless. > > > > Only if they have access to another process which provides them with > > that data. > > Or can access the data under a different path to which their profile > does give them access, whether in its final destination or in some > temporary file processed along the way. > > > And now, yes, I know AA doesn't mediate IPC or networking (yet), but > > that's a missing feature, not broken by design. > > The incomplete mediation flows from the design, since the pathname-based > mediation doesn't generalize to cover all objects unlike label- or > attribute-based mediation. And the "use the natural abstraction for > each object type" approach likewise doesn't yield any general model or > anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 21 Jun 2007, Joshua Brindle wrote: Lars Marowsky-Bree wrote: On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote: > Um, no. It might not be able to directly open files via that path, but > showing that it can never read or write your mail is a rather different > matter. > Yes. Your use case is different than mine. So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry. remember, the policies define a white-list so if a hacker wants to have mozilla access the mail files he needs to get some other process on the sysstem to create a link or move a file to a path that mozilla does have access to. until that is done there is no way for mozilla to access the mail through the filesystem. other programs could be run that would give mozilla access to the mail contents, but it would be through some other path that the policy permitted mozilla accessing in the first place. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-21T20:16:25, Joshua Brindle <[EMAIL PROTECTED]> wrote: > not. One need only look at the wonderful marketing literature for AA to > see what you are telling people it can do, and your above statement > isn't consistent with that, sorry. I'm sorry. I don't work in marketing. -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Lars Marowsky-Bree wrote: On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote: Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. Yes. Your use case is different than mine. So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 10:21:07PM +0200, Lars Marowsky-Bree wrote: > On 2007-06-21T22:07:40, Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > > Plus IIRC we have something like "AA has to allocate path-sized > > buffers along every syscall". > > That is an implementation bug though. I'm sure we have other bugs in the > kernel too - this isn't a design flaw. > > (If people are allowed to thinair solutions for implementing AA on top > of SELinux, I can thinair that this can be solved by reverse-matching > the dentry tree against the policy as the path is traversed and > constructed, requiring a constant sized buffer.) > Indeed there are a few solutions to "fix" this implementation "bug", of which reverse matching is one. For reverse matching the policy tables would become larger. Reverse matching wouldn't need any additional buffer for enforcement but would still fall back to d_path for logging. But we would still require the changes to the vfs and also a way to safely walk the tree backwards. So we would need to either export the namespace semaphore or add a generic walking function which we could pass a hook function to. pgpcWfvuaQGFD.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote: > Or can access the data under a different path to which their profile > does give them access, whether in its final destination or in some > temporary file processed along the way. Well, yes. That is intentional. Your point is? > The emphasis on never modifying applications for security in AA likewise > has an adverse impact here, as you will ultimately have to deal with > application mediation of access to their own objects and operations not > directly visible to the kernel (as we have already done in SELinux for > D-BUS and others and are doing for X). Otherwise, your "protection" of > desktop applications is easily subverted. That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation. > Um, no. It might not be able to directly open files via that path, but > showing that it can never read or write your mail is a rather different > matter. Yes. Your use case is different than mine. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote: > > > > A veto is not a technical argument. All technical arguments (except for > > > "path name is ugly, yuk yuk!") have been addressed, have they not? > > AppArmor doesn't actually provide confinement, because it only operates on > > filesystem objects. > > > > What you define in AppArmor policy does _not_ reflect the actual > > confinement properties of the policy. Applications can simply use other > > mechanisms to access objects, and the policy is effectively meaningless. > > Only if they have access to another process which provides them with > that data. Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way. > And now, yes, I know AA doesn't mediate IPC or networking (yet), but > that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your "protection" of desktop applications is easily subverted. > > You might define this as a non-technical issue, but the fact that AppArmor > > simply does not and can not work is a fairly significant consideration, I > > would imagine. > > If I restrict my Mozilla to not access my on-disk mail folder, it can't > get there. (Barring bugs in programs which Mozilla is allowed to run > unconfined, sure.) Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-21T22:07:40, Pavel Machek <[EMAIL PROTECTED]> wrote: > > AA is supposed to allow valid access patterns, so for non-buggy apps + > > policies, the rename will be fine and does not change the (observed) > > permissions. > That still breaks POSIX, right? Hopefully it will not break any apps, > but... No, it does not break POSIX. Unless, of course, there's a bug in the policy or in the program. Bugs are generally not covered by POSIX, for some strange reason. (The argument that POSIX codifies implementation bugs in Unix(tm) implementations of the time non-withstanding.) > > A veto is not a technical argument. All technical arguments (except for > > "path name is ugly, yuk yuk!") have been addressed, have they not? > There still is "it does not work with long pathnames". > > Plus IIRC we have something like "AA has to allocate path-sized > buffers along every syscall". That is an implementation bug though. I'm sure we have other bugs in the kernel too - this isn't a design flaw. (If people are allowed to thinair solutions for implementing AA on top of SELinux, I can thinair that this can be solved by reverse-matching the dentry tree against the policy as the path is traversed and constructed, requiring a constant sized buffer.) Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > > I believe AA breaks POSIX, already. rename() is not expected to change > > permissions on target, nor is link link. And yes, both of these make > > AA insecure. > > AA is supposed to allow valid access patterns, so for non-buggy apps + > policies, the rename will be fine and does not change the (observed) > permissions. That still breaks POSIX, right? Hopefully it will not break any apps, but... > > > If that is the only way to implement AA on top of SELinux - and so far, > > > noone has made a better suggestion - I'm convinced that AA has technical > > > merit: it does something the on-disk label based approach cannot handle, > > > and for which there is demand. > > What demand? SELinux is superior to AA, and there was very little > > demand for AA. Compare demand for reiser4 or suspend2 with demand for > > AA. > > SELinux is superior to AA for a certain scenario of use cases; as we can > see here, it is not superior to AA for _all_ use cases. The scenario where it does not seem superior is "I have system with AA here and I'd like to keep using it". > > > The code has improved, and continues to improve, to meet all the coding > > > style feedback except the bits which are essential to AA's function > > Which are exactly the bits Christoph Hellwig and Al Viro > > vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html > > . I believe it takes more than "2 users want it" to overcome veto of > > VFS maintainer. > > A veto is not a technical argument. All technical arguments (except for > "path name is ugly, yuk yuk!") have been addressed, have they not? There still is "it does not work with long pathnames". Plus IIRC we have something like "AA has to allocate path-sized buffers along every syscall". I guess Al Viro or Christoph Hellwig would be able to detail on that. I don't think they are vetoing stuff for fun. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote: > > A veto is not a technical argument. All technical arguments (except for > > "path name is ugly, yuk yuk!") have been addressed, have they not? > AppArmor doesn't actually provide confinement, because it only operates on > filesystem objects. > > What you define in AppArmor policy does _not_ reflect the actual > confinement properties of the policy. Applications can simply use other > mechanisms to access objects, and the policy is effectively meaningless. Only if they have access to another process which provides them with that data. And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. > You might define this as a non-technical issue, but the fact that AppArmor > simply does not and can not work is a fairly significant consideration, I > would imagine. If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.) If the argument is that AA provides somewhat different semantics - and for some use cases "weaker" ones - than SE Linux, that is undoubtly true. However, it appears to be the case that those are the differences which make AA's model different from SELinux as well, so it appears a trade-off best left to the admin / user to choose what fits their needs best. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! > >>The code has improved, and continues to improve, to meet all the coding > >>style feedback except the bits which are essential to AA's function > > > >Which are exactly the bits Christoph Hellwig and Al Viro > >vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html > >. I believe it takes more than "2 users want it" to overcome veto of > >VFS maintainer. > > so you are saying that _any_ pathname based solution is not acceptable to > the kernel, no matter what? You'd have to ask Christoph the same question. AFAICT, reconstructing full path then basing security on that is a no-no. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, 21 Jun 2007, Lars Marowsky-Bree wrote: > A veto is not a technical argument. All technical arguments (except for > "path name is ugly, yuk yuk!") have been addressed, have they not? AppArmor doesn't actually provide confinement, because it only operates on filesystem objects. What you define in AppArmor policy does _not_ reflect the actual confinement properties of the policy. Applications can simply use other mechanisms to access objects, and the policy is effectively meaningless. You might define this as a non-technical issue, but the fact that AppArmor simply does not and can not work is a fairly significant consideration, I would imagine. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
