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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > >> It's really not worth getting bothered by. Truth is, big > >> giant > >> pathnames break lots of stuff already, both kernel and > >> userspace. > > > >> Just look in /proc for some nice juicy kernel breakage: > >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps > > > >Well, but we should be fixing that, not adding more. And /proc is > >info-only, while this is security related code. > > Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. Running TOMOYO or AppArmor fixes the bug. :-) You can't get long paths that break /proc if you are running either. Therefore, one of those is required. - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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. pgpZxqz1nXSPS.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. pgp8OZqiuKpMW.pgp Description: PGP signature
