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-fsdevel 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
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-fsdevel 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
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-fsdevel 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 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-fsdevel 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
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-fsdevel 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
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-fsdevel 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
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-fsdevel 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. 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. pgpa39172kAUO.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. pgpC22P7rGCbZ.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-fsdevel 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. 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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-fsdevel 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
* 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-fsdevel 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 Monday 18 June 2007 15:33, Stephen Smalley wrote: On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote: There are two things: 1) relabeling (non-tranquility) is very problematic in general because revocation is hard (and non-solved in Linux). So you would have to address concerns about that. I think we need to distinguish between relying on restorecond-like mechanisms for the security of SELinux vs. relying on them for emulating pathname-based security. The former would be a problem. The latter is no worse than pathname-based security already, because pathname-based security is inherently ambiguous and non-tranquil, and revocation isn't addressed fully in AA either. Emulation using lazy relabeling introduces a window where the files have the wrong label. In those windows, the pathname based policy is being violated, and unintended side effects are suddenly possible. This includes granting of access to files that applications should no longer have access to according to the pathname based policy, which would be similar to what happens when a process keeps an open file handle right now. But it also includes denial of access to files that applications should have access to, and this might cause those applications to fail. So this is where relabeling from user space is much worse. The only way to get rid of the denial of service problem would be to make the rename and relabel an atomic operation. The time this can take is huge though, so that's not acceptable. Another, less catastrophic problem is that rename has always been relatively fast and inexpensive, and I'm sure plenty of applications rely on this performance characteristic. Making rename a very expensive operation in at least some cases (which are more than theoretical) would hurt those applications, and nothing much could be done about it. Adding better new-file mechanisms to SELinux probably is a good idea, and it would weaken the SELinux seurity model for all I can tell. It doesn't address the relabeling problem though. Andreas - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 01:49, Greg KH wrote: But for those types of models that do not map well to internal kernel structures, perhaps they should be modeled on top of a security system that does handle the internal kernel representation of things in the way the kernel works. How exactly are struct vfsmount and struct dentry not in-kernel structures? Andreas - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
I've caught up on this thread with growing disbelief while reading the mails, so much that I've found it hard to decide where to reply to. So people are claiming that AA is ugly, because it introduces pathnames and possibly a regex interpreter. Ok, taste differs. We've got many different flavours of filesystems in the kernel because of that. However, the suggested cure makes me cringe. You're saying that relabeling file(s) from user-space after a rename is a possible solution. This breaks POSIX - renames must be atomic. It is possibly insecure; if this is fixed by making a rename automatically default to restrictive permissions, it'll be even more inconvenient. It will break applications which expect to be able to access the file(s) immediately after a rename. It is slow, and can possibly cause a lot of disk access. Possibly over NFS or via slow disks. By going through user-space - which could block and introduce all sorts of memory deadlocks (compared to that deadlock, a regex is harmless.) (I also wonder how you propose to relabel files on a r/o mount if the policy changes, btw; or if the NFS mount is made available on several nodes w/different permissions.) AA only enforces user-space defined policy - the argument that policy doesn't belong into the kernel is bull. Adding a wrapper to glibc to block until relabeling is complete? Let's first do the implementation and later worry about performance.? The timing window is neglible.? 30 minutes during installation does not seem silly.? You _must_ be kidding. The cure is worse than the problem. 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. 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 (like the pathname lookup and the regex parser; though I'm sure that in particular the later one could be swapped for a less complex matcher as well). It certainly isn't worse than many other areas of the kernel. You're pointing to each other's opposition to the features - that, my dear gentlemen, is a circular argument. One of you could readily break the chain. This is trying to get rid of AA for the sake of it, masquerading as technical reasons. At least fucking admit it. Don't lie. This is distasteful. 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-fsdevel 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 18:01:05, Andreas Gruenbacher wrote: On Saturday 16 June 2007 01:49, Greg KH wrote: But for those types of models that do not map well to internal kernel structures, perhaps they should be modeled on top of a security system that does handle the internal kernel representation of things in the way the kernel works. How exactly are struct vfsmount and struct dentry not in-kernel structures? That's what greg is talking about, AFAICT. Normal kernel code uses struct vfsmount + struct dentry. AA uses... guess what... char pathname[HUGE_VALUE]. 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-fsdevel 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
Hi! I've caught up on this thread with growing disbelief while reading the mails, so much that I've found it hard to decide where to reply to. So people are claiming that AA is ugly, because it introduces pathnames and possibly a regex interpreter. Ok, taste differs. We've got many different flavours of filesystems in the kernel because of that. However, the suggested cure makes me cringe. You're saying that relabeling file(s) from user-space after a rename is a possible solution. This breaks POSIX - renames must be atomic. It is possibly insecure; if this is fixed by making a rename automatically default to restrictive permissions, it'll be even more inconvenient. It will break applications inconvenient, yes, insecure, no. 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. You _must_ be kidding. The cure is worse than the problem. Possibly. 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. 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. 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-fsdevel 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-21T20:33:11, Pavel Machek [EMAIL PROTECTED] wrote: inconvenient, yes, insecure, no. Well, only if you use the most restrictive permissions. And then you'll suddenly hit failure cases which you didn't expect to, which can possibly cause another exploit to become visible. 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. The time window in the rename+relabel approach however introduces a slot where permissions are not consistent. This is a different case. You _must_ be kidding. The cure is worse than the problem. Possibly. Yes. 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 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? 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-fsdevel 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, 21 Jun 2007, Pavel Machek wrote: 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. well, if you _really_ want people who are interested in this to do weekly why isn't it merged yet you $%#$%# developers threads that can be arranged. the people who want this have been trying to be patient and let the system work. if it takes people being pests to get something implemented it can be done, but I don't think other people on the list will appriciate this. 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? David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-21T12:30:08, [EMAIL PROTECTED] wrote: well, if you _really_ want people who are interested in this to do weekly why isn't it merged yet you $%#$%# developers threads that can be arranged. the people who want this have been trying to be patient and let the system work. if it takes people being pests to get something implemented it can be done, but I don't think other people on the list will appriciate this. Please. We're so not going down _that_ route. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 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-fsdevel 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
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-fsdevel 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-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-fsdevel 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
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-fsdevel 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-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-fsdevel 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 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-fsdevel 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-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-fsdevel 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 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. pgpOvWugBbVvn.pgp Description: PGP signature
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: snip 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-fsdevel 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-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-fsdevel 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, 21 Jun 2007, Joshua Brindle wrote: Lars Marowsky-Bree wrote: On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote: snip 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-fsdevel 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: 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-fsdevel 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, 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-fsdevel 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
[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: snip 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-fsdevel 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
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-fsdevel 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
Casey Schaufler wrote: --- James Morris [EMAIL PROTECTED] wrote: On Fri, 15 Jun 2007, Casey Schaufler wrote: --- James Morris [EMAIL PROTECTED] wrote: On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner That's an eternity for that many files to be improperly labeled. If, and the if didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the safe argument. They've been known to balk before. To clarify: We are discussing a scheme where the underlying SELinux labeling policy always ensures a safe label on a file, and then relabeling newly created files according to their pathnames. To counter clarify: You are saying two things: 1. The policy always ensures a safe label. 2. Files can be relabeled in a reasonable and timely manner. I have no questions about 2. It's a hack, but you've already acknowledged that and it will work, allowing for some potential cases where someone is overeager about getting a file-in-transition. Regarding 1: This is a founding premise of the arguement, that the policy is written correctly such that there is no case where a file gets created with an unsafe label. Given the external nature of the policy, and the number of attributes used within the policy, and the overall sophistication of the policy mechanism, how does one ... a. know that a label is safe b. know that a file will get a safe label c. know that the policy is correctly written as required The question is not if fixxerupperd can set things right. The question is about the properly written policy that is required to make the mechanism worth discussing. There are only about 850 file type_transition rules in the policy shipped with RHEL and the vast majority of them are templated so this isn't as hard as you think. Most are things like: type_transition ftpd_t tmp_t : file ftpd_tmp_t; which 1) don't require relabeling to something else and 2) very easy to audit. A quick look suggests that the potentially less-restrictive label is never chosen, for example you'll see: type_transition groupadd_t etc_t : file shadow_t; type_transition useradd_t etc_t : file shadow_t; Instead of the default transition being etc_t they are labeled as shadow_t (more restrictive) and then potentially relabled to etc_t. That said, the lack of a type_transition in this case is as important as having one if the default type (the parent directory) is less restrictive. We already have tools that analyze policy and even tools to warn about potential errors in policy (apol and sechecker). It might be a good idea to add some more analysis to these tools to point out potential labeling errors that can be used in automatic analysis, which shouldn't be hard, I'll be sure to suggest that to the setools developers. There is no expectation that this scheme would be submitted for certification. De-nial. Several systems have gone off to cte and none of them use restorecond. These are custom build systems and relabeling is kept to a minimum and the applications are architected in a way that precludes this being necessary so I don't know what you are trying to get at here. Its purpose is to merely to provide pathname-based labeling outside of the kernel. If you already have an in-kernel labeling scheme that you trust to make the world safe until you get around to doing the labeling externally you can argue that it's good enough. But, to quote Cinderella's Stepmother, I said if. The if for SELinux is alot easier than you suggest. It certainly outweighs the disadvantages of the path based scheme IMHO. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-15 at 13:43 -0700, Casey Schaufler wrote: --- Stephen Smalley [EMAIL PROTECTED] wrote: On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote: --- Greg KH [EMAIL PROTECTED] wrote: A daemon using inotify can instantly[1] detect this and label the file properly if it shows up. In our 1995 B1 evaluation of Trusted Irix we were told in no uncertain terms that such a solution was not acceptable under the TCSEC requirements. Detection and relabel on an unlocked object creates an obvious window for exploitation. We were told that such a scheme would be considered a design flaw. I understand that some of the Common Criteria labs are less aggressive regarding chasing down these issues than the NCSC teams were. It might not prevent an evaluation from completing today. It is still hard to explain why it's ok to have a file that's labeled incorrectly _even briefly_. It is the systems job to ensure that that does not happen. Um, Casey, he is talking about how to emulate AppArmor behavior on a label-based system like SELinux, Yes. What I'm saying (or trying to) is that such an implementation would be flawed by design. not meeting B1 or LSPP or anything like that (which AppArmor can't do regardless). We're not talking about an implementation based on AppArmor. As you point out, we're talking about implementing name based access control as an extension of SELinux. We're talking about emulating pathname-based security on SELinux. Pathname-based security is inherently non-tranquil (names can change at any time) and ambiguous (a single name may refer to different objects in different namespaces, multiple names may refer to the same object in a single namespace), and thus cannot possibly meet information flow / classical confinement requirements. So using restorecond as the basis for such an emulation loses nothing from what you already had. Using restorecond as the fundamental basis for the security of SELinux itself would be a bad thing, agreed. As far as general issue goes, if your policy is configured such that the new file gets the most restrictive label possible at creation time and then the daemon relabels it to a less restrictive label if appropriate, then there is no actual window of exposure. Is it general practice to configure policy such that the new file gets the most restrictive label possible at creation time? I confess that my understanding of the current practice in policy generation is based primarily on a shouted conversation in a crowded Irish pub. Also, there is such a daemon, restorecond, in SELinux (policycoreutils) although we avoid relying on it for anything security-critical naturally. Yes, I am aware of restorecond. I find the need for restorecond troubling. Understand that we view it as a method of last resort, only to be considered after trying first to: 1) Configure policy transparently to label the file correctly at creation time (based on the creating process' label, the parent directory label, and the kind of file), or if that fails, 2) Modify the library or application code to label the file correctly at creation time (e.g. when multiple files that should be protected differently are created by the same process in the same directory, e.g. /etc/passwd vs. /etc/shadow). And one could introduce the named type transition concept that has been discussed in this thread without much difficulty to selinux. Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. I think you misunderstand what I mean by named type transition here - that is a reference to earlier discussions in this thread on extending the SELinux type_transition statements to let the kernel directly label new files based not only on creating process and parent directory label but also the last component name. With such an extension, SELinux could directly distinguish e.g. /etc/shadow from /etc/passwd at file creation time in the kernel without needing anything like restorecond in userspace. There is no temporary mislabeling with such a mechanism. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-15 at 18:24 -0400, Karl MacMillan wrote: On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote: On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote: Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. My point is that there is a segment of the security community that had not found this acceptable, even under the conditions outlined. If it meets your needs, I say run with it. If that segment feels that way, then I imagine AA would not meet their requirements today due to file handles and other ways of passing around open files, right? So, would SELinux today (without this AA-like daemon) fit the requirements of this segment? Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC using the features of SELinux where appropriate. Great, but is there the requirement in the CC stuff such that this type of delayed re-label that an AA-like daemon would need to do cause that model to not be able to be certified like your SELinux implementation is? There are two things: 1) relabeling (non-tranquility) is very problematic in general because revocation is hard (and non-solved in Linux). So you would have to address concerns about that. I think we need to distinguish between relying on restorecond-like mechanisms for the security of SELinux vs. relying on them for emulating pathname-based security. The former would be a problem. The latter is no worse than pathname-based security already, because pathname-based security is inherently ambiguous and non-tranquil, and revocation isn't addressed fully in AA either. 2) Whether this would pass certification depends on a lot of factors (like the specific requirements - CC is just a process not a single set of requirements). I don't know enough to really guess. More to the point, though, the requirements in those documents are outdated at best. I don't think it is worth worrying over. As I'm guessing the default label for things like this already work properly for SELinux, I figure we should be safe, but I don't know those requirements at all. Probably not - you would likely want it to be a label that can't be read or written by anything, only relabeled by the daemon. Karl -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Greg KH wrote: On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Then there's all the other problems, such as file systems that don't support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labeling scheme that labels files as they are pulled into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels. You still haven't answered Stephen's response to NFSv3, so until then, please don't trot out this horse. Ok then ... Stephen Smalley wrote: - File systems that do not support labels: I'm a bit surprised that you would advocate this given your experience in developing EA and ACL support for local filesystems and NFS. The pathname-based approach in NFS seems even scarier than in the local case - the clients may have different views of the namespace than one another or the server and the potential for inconsistent views of the tree (particularly as it is being modified) during access checks is only greater in the NFS case, right? It may be more expedient to implement, but is it the right technical approach? I'm actually unclear on what the question is. Stephen appears to be thinking of confining the NFS server daemon, and our intended use case is to use AppArmor to confine applications that access data on NFS clients. * Each NFS *client* machine has a view of the NFS mount point that is consistent for that client. * The AA confinement is of the application accessing the NFS mount on the client, *not* the NFS server daemon. * The fact that the views of multiple clients are different from each other is irrelevant, because we are confining applications on the client, not the NFS server daemon. * As noted in Andreas' technical document http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf there is no purpose to confining the NFS server daemon; it is a kernel process, and if it mis-behaves, it can completely subvert any kernel security policy, including AA and SELinux. Since this point seems to be subtle, here's a motivating example. Consider I have a diskless workstation, and my home dir /home/crispin is NFS mounted from a big NAS server over there. I like to run my FireFox confined, so that it only has access to /home/crispin/.mozilla/** and /home/crispin/Downloads/** so that if my browser is compromised, the attacker doesn't get to my /home/.ssh* stuff. Yes, the data served over NFS is vulnerable to a local network attack, but that is not what AA is preventing here. The threat is coming from attacks that make the web browser misbehave. Under SELinux, I either give the web browser access to all of /home/crispin (the entire mount point) or none of it. Under AA, the pathname specification works fine, we can control which directories on the mount point the application can access. The same argument applies to server applications that access data served NFS mount points. Consider a large application server that hosts all my enterprise resource management stuff, and a large NAS server that hosts the data. Perhaps the NAS server is a Network Appliance server, not even using a Linux file system, just supplying NFS3 mounts. The application server is hosting both the payroll system and the customer relationship application. The data for both are on the NetApp, serviced via NFS to the application server. I want to confine the payroll application to access only the payroll data, and the CRM application to access only CRM data. The only way SELinux could do this would be to have anticipated the problem and store my data on separate partitions, so you could supply separate mount points. AppArmor can just use path specifications to confine each application to its own part of a single NFS mount point. In a perfect world the admin would use separate mount points, AppArmor is a tool for an imperfect world. 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-fsdevel 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
--- James Morris [EMAIL PROTECTED] wrote: On Fri, 15 Jun 2007, Casey Schaufler wrote: --- James Morris [EMAIL PROTECTED] wrote: On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner That's an eternity for that many files to be improperly labeled. If, and the if didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the safe argument. They've been known to balk before. To clarify: We are discussing a scheme where the underlying SELinux labeling policy always ensures a safe label on a file, and then relabeling newly created files according to their pathnames. To counter clarify: You are saying two things: 1. The policy always ensures a safe label. 2. Files can be relabeled in a reasonable and timely manner. I have no questions about 2. It's a hack, but you've already acknowledged that and it will work, allowing for some potential cases where someone is overeager about getting a file-in-transition. Regarding 1: This is a founding premise of the arguement, that the policy is written correctly such that there is no case where a file gets created with an unsafe label. Given the external nature of the policy, and the number of attributes used within the policy, and the overall sophistication of the policy mechanism, how does one ... a. know that a label is safe b. know that a file will get a safe label c. know that the policy is correctly written as required The question is not if fixxerupperd can set things right. The question is about the properly written policy that is required to make the mechanism worth discussing. There is no expectation that this scheme would be submitted for certification. De-nial. Its purpose is to merely to provide pathname-based labeling outside of the kernel. If you already have an in-kernel labeling scheme that you trust to make the world safe until you get around to doing the labeling externally you can argue that it's good enough. But, to quote Cinderella's Stepmother, I said if. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, Greg KH wrote: Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. I agree, and yet, somehow, SELinux today handles this just fine, right? :) no it doesn't, SELinux as-is should take no action when the above command is run, but SELinux implementing path-based permissions will have to relabel every file or directory in both trees. Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users. if you are willing to live with the race conditions from the slow (re)labeling and write the software to scan the entire system to figure out the right policies (and then use inotify to watch the entire system for changes and (re)label the appropriate files) and accept that you can't get any granular security for filesystems that don't nativly support it you could make SELinux behave like AA. but why should they be required to? are you saying that the LSM hooks are not a valid API and should be removed with all future security modules being based on SELinux? David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 Sat, Jun 16, 2007 at 01:09:06AM -0700, [EMAIL PROTECTED] wrote: On Fri, 15 Jun 2007, Greg KH wrote: Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. I agree, and yet, somehow, SELinux today handles this just fine, right? :) no it doesn't, SELinux as-is should take no action when the above command is run, but SELinux implementing path-based permissions will have to relabel every file or directory in both trees. Agreed. Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users. if you are willing to live with the race conditions from the slow (re)labeling and write the software to scan the entire system to figure out the right policies (and then use inotify to watch the entire system for changes and (re)label the appropriate files) and accept that you can't get any granular security for filesystems that don't nativly support it you could make SELinux behave like AA. You make it sound like such a pretty picture :) Anyway, I don't think there are race conditions, just a bit of a delay at times for situations that are not common or normal operations. And as I think the speed issues can be drasticly reduced, I don't think that's a really big deal just yet. I'm trying to determine if there's any logical reason why we can't do this and have yet to see proof of that. but why should they be required to? are you saying that the LSM hooks are not a valid API and should be removed with all future security modules being based on SELinux? Woah, that's a huge logical jump that I am not willing to make at this point in time. The reason I am proposing this for AA is due to the impeadance between the AA model and how the kernel internally works. A number of core kernel VFS developers have objected to the AA code and changes because of this problem and me and Pavel are here working to try to resolve this in a way that is acceptable to everyone involved (kernel developers and AA developers and AA end users.) I'll leave the whole LSM should be just replaced with SELinux discussion for later, as it is not relevant to this current topic at all. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote: Andreas Gruenbacher wrote: On Saturday 09 June 2007 02:17, Greg KH wrote: On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. Woah, that describes the userspace side of AA just fine, it means nothing when it comes to the in-kernel implementation. There is no reason that you can't implement the same functionality using some totally different in-kernel solution if possible. I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is if possible, and in fact if possible is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible. In particular, to layer AppArmor on top of SELinux, the following problems must be addressed: * New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says /home/*/.plan r to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux. A daemon using inotify can instantly[1] detect this and label the file properly if it shows up. * Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename. Same daemon can do the re-label. * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in real-life on a production server is quite small, if at all. * New Policies: The SEEdit approach of compiling AA profiles into SELinux labels involves computing the partition set of files, so that each element of the partition set is unique, and corresponds to all the policies that treat every file in the element identically. If you create a new profile that touches *some* of the files in such an element, then you have to split that synthetic label, re-compute the partition set, and re-label the file system. Again, same daemon can handle this logic. * File Systems That Do Not Support Labels: The most important being NFS3 and FAT. Because they do not support labels at all, SELinux has to give you an all-or-nothing access control on the entire remote volume. AA can give you nuanced access control in these file systems. SELinux already provides support for the whole mounted filesystem, which, in real-life testing, seems to be quite sufficient. Also, the SELinux developers are working on some changes to make this a bit more fine-grained. See also Stephan's previous comments about NFSv3 client directories and multiple views having the potential to cause a lot of havoc. You could support all of these features in SELinux, but only by adding an in-kernel file matching mechanism similar to AppArmor. I don't think that is necessary at all, see above for why. It would basically load an AppArmor policy into the kernel, label files as they are brought from disk into the cache, and then use SELinux to do the access controls. No, do the labeling in userspace with a daemon using inotify to handle the changing of the files around. Or has this whole idea of a daemon been disproved already with a prototype somewhere that failed? If not, a simple test app would not be that hard to hack up. Maybe I'll see if I can do it during the week of June 24 :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-15 at 11:01 -0700, Casey Schaufler wrote: --- Greg KH [EMAIL PROTECTED] wrote: A daemon using inotify can instantly[1] detect this and label the file properly if it shows up. In our 1995 B1 evaluation of Trusted Irix we were told in no uncertain terms that such a solution was not acceptable under the TCSEC requirements. Detection and relabel on an unlocked object creates an obvious window for exploitation. We were told that such a scheme would be considered a design flaw. I understand that some of the Common Criteria labs are less aggressive regarding chasing down these issues than the NCSC teams were. It might not prevent an evaluation from completing today. It is still hard to explain why it's ok to have a file that's labeled incorrectly _even briefly_. It is the systems job to ensure that that does not happen. Um, Casey, he is talking about how to emulate AppArmor behavior on a label-based system like SELinux, not meeting B1 or LSPP or anything like that (which AppArmor can't do regardless). As far as general issue goes, if your policy is configured such that the new file gets the most restrictive label possible at creation time and then the daemon relabels it to a less restrictive label if appropriate, then there is no actual window of exposure. Also, there is such a daemon, restorecond, in SELinux (policycoreutils) although we avoid relying on it for anything security-critical naturally. And one could introduce the named type transition concept that has been discussed in this thread without much difficulty to selinux. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
--- Greg KH [EMAIL PROTECTED] wrote: A daemon using inotify can instantly[1] detect this and label the file properly if it shows up. In our 1995 B1 evaluation of Trusted Irix we were told in no uncertain terms that such a solution was not acceptable under the TCSEC requirements. Detection and relabel on an unlocked object creates an obvious window for exploitation. We were told that such a scheme would be considered a design flaw. I understand that some of the Common Criteria labs are less aggressive regarding chasing down these issues than the NCSC teams were. It might not prevent an evaluation from completing today. It is still hard to explain why it's ok to have a file that's labeled incorrectly _even briefly_. It is the systems job to ensure that that does not happen. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Hi! And before you scream races, take a look. It does not actually add them: I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is if possible, and in fact if possible is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible. In particular, to layer AppArmor on top of SELinux, the following problems must be addressed: * New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says /home/*/.plan r to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux. A daemon using inotify can instantly[1] detect this and label the file properly if it shows up. Or just create the files with restrictive labels by default. That way you fail closed. * Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename. Same daemon can do the re-label. ...and no, race there is not important. Attacker may have opened the file under old name and is keeping open file descriptor. So this does not add a new race relative to AA. * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in real-life on a production server is quite small, if at all. And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. 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-fsdevel 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 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: Hi! And before you scream races, take a look. It does not actually add them: Hey, I never screamed that at all, in fact, I completly agree with you :) I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is if possible, and in fact if possible is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible. In particular, to layer AppArmor on top of SELinux, the following problems must be addressed: * New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says /home/*/.plan r to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux. A daemon using inotify can instantly[1] detect this and label the file properly if it shows up. Or just create the files with restrictive labels by default. That way you fail closed. From my limited knowledge of SELinux, this is the default today so this would happen by default. Anyone with more SELinux experience want to verify or fix my understanding of this? * Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename. Same daemon can do the re-label. ...and no, race there is not important. Attacker may have opened the file under old name and is keeping open file descriptor. So this does not add a new race relative to AA. Agreed. * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in real-life on a production server is quite small, if at all. And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Agreed. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Exactly. I can't think of a real world use of moving directory trees around that this would come up in as a problem. Maybe a source code control system might have this issue for the server, but in a second or two everything would be working again as the new files would be relabled correctly. Can anyone else see a problem with this that I'm just being foolish and missing? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-15 at 14:14 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote: Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. My point is that there is a segment of the security community that had not found this acceptable, even under the conditions outlined. If it meets your needs, I say run with it. If that segment feels that way, then I imagine AA would not meet their requirements today due to file handles and other ways of passing around open files, right? So, would SELinux today (without this AA-like daemon) fit the requirements of this segment? Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC using the features of SELinux where appropriate. Karl - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, Greg KH wrote: Or just create the files with restrictive labels by default. That way you fail closed. From my limited knowledge of SELinux, this is the default today so this would happen by default. Anyone with more SELinux experience want to verify or fix my understanding of this? This is entirely controllable via policy. That is, you specify that newly create files are labeled to something safe (enforced atomically at the kernel level), and then your userland relabeler would be invoked via inotify to relabel based on your userland pathname specification. This labeling policy can be as granular as you wish, from the entire filesystem to a single file. It can also be applied depending on the process which created the file and the directory its created in, ranging from all processes and all directories, to say, just those running as user_t in directories labeled as public_html_t (or whatever). - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote: On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote: Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. My point is that there is a segment of the security community that had not found this acceptable, even under the conditions outlined. If it meets your needs, I say run with it. If that segment feels that way, then I imagine AA would not meet their requirements today due to file handles and other ways of passing around open files, right? So, would SELinux today (without this AA-like daemon) fit the requirements of this segment? Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC using the features of SELinux where appropriate. Great, but is there the requirement in the CC stuff such that this type of delayed re-label that an AA-like daemon would need to do cause that model to not be able to be certified like your SELinux implementation is? As I'm guessing the default label for things like this already work properly for SELinux, I figure we should be safe, but I don't know those requirements at all. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-15 at 14:44 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote: On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote: Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. My point is that there is a segment of the security community that had not found this acceptable, even under the conditions outlined. If it meets your needs, I say run with it. If that segment feels that way, then I imagine AA would not meet their requirements today due to file handles and other ways of passing around open files, right? So, would SELinux today (without this AA-like daemon) fit the requirements of this segment? Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC using the features of SELinux where appropriate. Great, but is there the requirement in the CC stuff such that this type of delayed re-label that an AA-like daemon would need to do cause that model to not be able to be certified like your SELinux implementation is? There are two things: 1) relabeling (non-tranquility) is very problematic in general because revocation is hard (and non-solved in Linux). So you would have to address concerns about that. 2) Whether this would pass certification depends on a lot of factors (like the specific requirements - CC is just a process not a single set of requirements). I don't know enough to really guess. More to the point, though, the requirements in those documents are outdated at best. I don't think it is worth worrying over. As I'm guessing the default label for things like this already work properly for SELinux, I figure we should be safe, but I don't know those requirements at all. Probably not - you would likely want it to be a label that can't be read or written by anything, only relabeled by the daemon. Karl - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Greg KH wrote: On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in real-life on a production server is quite small, if at all. And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Agreed. We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Exactly. You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here: http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue. I can't think of a real world use of moving directory trees around that this would come up in as a problem. Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else. Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache. In a smaller scale example, I want to share some files with a friend. I can't be bothered to set up a proper access control system, so I just mv the files to ~crispin/public_html/lookitme and in IRC say get it now, going away in 10 minutes and then move it out again. Yes, you can manually address this by running restorecon ~crispin/public_html. But AA does this automatically without having to run any commands. You could get restorecon to do this automatically by using inotify. But to make it as general and transparent as AA is now, you would have to run inotify on every directory in the system, with consequences for kernel memory and performance. This problem does not exist for SELinux, because SELinux does not expect access to change based on file names. This problem does not exist in the proposed AA implementation, because the patch makes the access decision based on the current name of the file, so it doesn't have a consistency problem between the file and its label; there is no label. The problem is induced by trying to emulate AA on top of SELinux. They don't fit well together. AA fits much better with LSM, which is the reason LSM exists. Maybe a source code control system might have this issue for the server, but in a second or two everything would be working again as the new files would be relabled correctly. Try an hour or two for a large source code repository. Its linear in the number of files, and several hundred thousand files would take a while to relabel. A large GIT tree would be particularly painful because of the very large number of files. Can anyone else see a problem with this that I'm just being foolish and missing? It is not foolish. The label idea is so attractive that last September from discussions with Arjan we actually thought it was the preferred implementation. However, what we've been saying over and over again is that we *tried* this, and it *doesn't* work at the implementation level. There is no good answer, restorecon is an ugly kludge, and so this seductive approach turns out to be a dead end. Caveat: I am *not* saying that labels in general are bad, just that they are a bad way to emulate the AppArmor model. And yes, I am working on a model paper that is more abstract than Andreas' paper http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf, but that takes time. Then there's all the other problems, such as file systems that don't support extended
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Pavel, please focus on the current AppArmor implementation. You're remembering a flaw with a previous version of AppArmor. The pathnames constructed with the current version of AppArmor are consistent and correct. Thanks. pgps7yFSK4Br7.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Pavel, please focus on the current AppArmor implementation. You're remembering a flaw with a previous version of AppArmor. The pathnames constructed with the current version of AppArmor are consistent and correct. Ok, I did not know that this got fixed. How do you do that? Hold a lock preventing renames for a whole time you walk from file to the root of filesystem? 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-fsdevel 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 15, 2007 at 05:42:08PM -0400, James Morris wrote: On Fri, 15 Jun 2007, Greg KH wrote: Or just create the files with restrictive labels by default. That way you fail closed. From my limited knowledge of SELinux, this is the default today so this would happen by default. Anyone with more SELinux experience want to verify or fix my understanding of this? This is entirely controllable via policy. That is, you specify that newly create files are labeled to something safe (enforced atomically at the kernel level), and then your userland relabeler would be invoked via inotify to relabel based on your userland pathname specification. This labeling policy can be as granular as you wish, from the entire filesystem to a single file. It can also be applied depending on the process which created the file and the directory its created in, ranging from all processes and all directories, to say, just those running as user_t in directories labeled as public_html_t (or whatever). Oh great, then things like source code control systems would have no problems with new files being created under them, or renaming whole trees. So, so much for the it's going to be too slow re-labeling everything issue, as it's not even required for almost all situations :) thanks for letting us know. greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Greg KH wrote: On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in real-life on a production server is quite small, if at all. And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Agreed. We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem. How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but somehow SELinux already handles this, so I think you should be fine. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Exactly. You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here: http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue. Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue. Agreed, so we fix that. There are ways to speed those kinds of things up quite a bit, and I imagine since the default SELinux behavior doesn't use restorecon in this kind of use-case, no one has spent the time to do the work. I can't think of a real world use of moving directory trees around that this would come up in as a problem. Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else. Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache. Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. In a smaller scale example, I want to share some files with a friend. I can't be bothered to set up a proper access control system, so I just mv the files to ~crispin/public_html/lookitme and in IRC say get it now, going away in 10 minutes and then move it out again. Yes, you can manually address this by running restorecon ~crispin/public_html. But AA does this automatically without having to run any commands. I'm saying that the daemon will automatically do it for you, you don't have to do anything on your own. You could get restorecon to do this automatically by using inotify. Yes. But to make it as general and transparent as AA is now, you would have to run inotify on every directory in the system, with consequences for kernel memory and performance. What kernel memory and performance issues are there? Your SLED machine already has inotify running on every directory in the system today, and you don't seem to have noticed that :) This problem does not exist for SELinux, because SELinux does not expect access to change based on file names. Agreed. This problem does not exist in the proposed AA implementation, because the patch makes the access decision based on the current name of the file, so it doesn't have a consistency problem between the file and its label; there is no label. No, that's not the issue here. The issue is if we can use the model that AA is exporting to users and apply it to the model that the kernel uses internally to access internal data
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 15 Jun 2007, Greg KH wrote: On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Greg KH wrote: On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Exactly. You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here: http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue. how do you 'fix' the laws of physics? the problem is that with a directory that contains lots of files below it you have to access all the files metadata to change the labels on it. it can take significant amounts of time to walk the entire three and change every file. I can't think of a real world use of moving directory trees around that this would come up in as a problem. Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else. Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache. Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Hi! Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Exactly. You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here: Ok, so what I described was actually secure. Good. Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. 30 minutes during installation does not seem silly to me. And that race does not make it insecure, because of the open file descriptors. Good. Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue. You seem to imply it is security related, it is not. I can have open files for hours or days. I can't think of a real world use of moving directory trees around that this would come up in as a problem. Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else. And you do that exactly how, without the race? I do not think ve have three_way_rename(name1, name2, name3) system call. Notice that 1) mv can take minutes already if you move cross filesystem. 2) this is easily avoided by mv-ing somewhere with same permissons, then doing quick moves when daemon is done. You could get restorecon to do this automatically by using inotify. But to make it as general and transparent as AA is now, you would have to run inotify on every directory in the system, with consequences for kernel memory and performance. So you run inotify everywhere. IIRC beagle does it already. Can anyone else see a problem with this that I'm just being foolish and missing? It is not foolish. The label idea is so attractive that last September from discussions with Arjan we actually thought it was the preferred implementation. However, what we've been saying over and over again is that we *tried* this, and it *doesn't* work at the implementation level. There is no good answer, restorecon is an ugly kludge, and so this seductive approach turns out to be a dead end. Talking about dead ends... just put path-based security module into kernel recently got pretty strong NACK from Christoph Hellwig (see TOMOYO Linux thread), and I believe there was similar comment from Al Viro in past. That seems to me as dead-endy as it gets. mv takes 30 minutes is road slightly covered with bushes... compared to that. So we can either forget about AA completely, or take a way Christoph did not NACK. restorecond is such a way, and with inotify it should be acceptable. find does _not_ take that long, not even for git trees. [EMAIL PROTECTED]:/data/l/linux$ time find . /dev/null 0.04user 0.37system 11.50 (0m11.504s) elapsed 3.56%CPU (If you wanted to be super-nice, you could introduce rename() helper into glibc, that would do re-labeling synchronously, and only return when it is done. All the nice applications call glibc anyway, and all the exploits can't take advantage of it, because it is secure already.). 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-fsdevel 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 Sat, Jun 16, 2007 at 01:39:14AM +0200, Pavel Machek wrote: Pavel, please focus on the current AppArmor implementation. You're remembering a flaw with a previous version of AppArmor. The pathnames constructed with the current version of AppArmor are consistent and correct. Ok, I did not know that this got fixed. How do you do that? Hold a lock preventing renames for a whole time you walk from file to the root of filesystem? We've improved d_path() to remove many of its previous shortcomings: eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 pgpWzjYHnHhk0.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote: We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem. How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but somehow SELinux already handles this, so I think you should be fine. SELinux does not relabel files when containing directories move, so it is not a problem they've chosen to face. How well does inotify handle running attached to every directory on a typical Linux system? Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue. Restorecon traverses the filesystem from a specific down. In order to apply to an entire system (as would be necessary to try to emulate AppArmor's model using SELinux), restorecon would need to run on vast portions of the filesystem often. (mv ~/public_html ~/archived; or tar zxvf linux-*.tar.gz, etc.) I'm not sure we need to run restorecon every time rename(2) is called. Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue. Agreed, so we fix that. There are ways to speed those kinds of things up quite a bit, and I imagine since the default SELinux behavior doesn't use restorecon in this kind of use-case, no one has spent the time to do the work. The time for restorecon is probably best imagined as a kind of 'du' that also updates extended attributes as it does its work. It'd be very difficult to improve on this. What kernel memory and performance issues are there? Your SLED machine already has inotify running on every directory in the system today, and you don't seem to have noticed that :) I beg to differ. :) pgp4PjM5RH2rc.pgp Description: PGP signature
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache. Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. 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?) So, proposed solution has different performance tradeoffs, but should still be a win -- opens are more common than moves. 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-fsdevel 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 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote: On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote: We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem. How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but somehow SELinux already handles this, so I think you should be fine. SELinux does not relabel files when containing directories move, so it is not a problem they've chosen to face. How well does inotify handle running attached to every directory on a typical Linux system? Look at SLED and Beagle (taking the indexing logic out of the equation.) It runs good enough that a major Linux vendor is willing to stake its reputation on it :) Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue. Restorecon traverses the filesystem from a specific down. In order to apply to an entire system (as would be necessary to try to emulate AppArmor's model using SELinux), restorecon would need to run on vast portions of the filesystem often. (mv ~/public_html ~/archived; or tar zxvf linux-*.tar.gz, etc.) I'm not sure we need to run restorecon every time rename(2) is called. Ok, so we optimize it. Putting speed issues aside right now as a mere implementation details, I'm looking for logical reasons the AA model will not work in this type of system. Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue. Agreed, so we fix that. There are ways to speed those kinds of things up quite a bit, and I imagine since the default SELinux behavior doesn't use restorecon in this kind of use-case, no one has spent the time to do the work. The time for restorecon is probably best imagined as a kind of 'du' that also updates extended attributes as it does its work. It'd be very difficult to improve on this. Is that a bet? :) What kernel memory and performance issues are there? Your SLED machine already has inotify running on every directory in the system today, and you don't seem to have noticed that :) I beg to differ. :) The Beagle index backend is known to slow things down at times, yes, but is that the fault of the inotify watches, or the use of mono and a big-ass database on the system at the same time? In the original inotify development, the issue was not inotify at all, unless you have some newer numbers in this regard? And Crispin mentioned that you all already implemented this. Do you have the code around so that we can take a look at it? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 15, 2007 at 05:01:25PM -0700, [EMAIL PROTECTED] wrote: On Fri, 15 Jun 2007, Greg KH wrote: On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Greg KH wrote: On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that when madly moving trees we sometimes construct path file never ever had. Exactly. You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here: http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly. Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue. how do you 'fix' the laws of physics? the problem is that with a directory that contains lots of files below it you have to access all the files metadata to change the labels on it. it can take significant amounts of time to walk the entire three and change every file. Agreed, but you can do this in ways that are faster than others :) I can't think of a real world use of moving directory trees around that this would come up in as a problem. Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else. Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache. Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up. on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. I agree, and yet, somehow, SELinux today handles this just fine, right? :) Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, Greg KH wrote: Oh great, then things like source code control systems would have no problems with new files being created under them, or renaming whole trees. It depends -- I think we may be talking about different things. If you're using inotify to watch for new files and kick something in userspace to relabel them, it could take a while to relabel a lot of files, although there are likely some gains to be had from parallel relabeling which we've not explored. What I was saying is that you can use traditional SELinux labeling policy underneath that to ensure that there is always a safe label on each file before it is relabeled from userspace. So, so much for the it's going to be too slow re-labeling everything issue, as it's not even required for almost all situations :) You could probably get an idea of the cost by running something like: $ time find /usr/src/linux | xargs setfattr -n user.foo -v bar On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner, on a stock standard ext3 filesystem with a SATA drive. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, [EMAIL PROTECTED] wrote: on the contrary, useing 'mv' is by far the cleanest way to do this. mv htdocs htdocs.old;mv htdocs.new htdocs this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result. OTOH, you've performed your labeling up front, and don't have to effectively relabel each file each time on each access, which is what you're really doing with pathname labeling. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, Seth Arnold wrote: How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but somehow SELinux already handles this, so I think you should be fine. SELinux does not relabel files when containing directories move, so it is not a problem they've chosen to face. It's a deliberate design choice, and follows traditional Unix security logic. DAC permissions don't change on every file in the subtree when you mv directories, either. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, Seth Arnold wrote: The time for restorecon is probably best imagined as a kind of 'du' that also updates extended attributes as it does its work. It'd be very difficult to improve on this. restorecon can most definitely be improved. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
--- James Morris [EMAIL PROTECTED] wrote: On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner That's an eternity for that many files to be improperly labeled. If, and the if didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the safe argument. They've been known to balk before. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 15 Jun 2007, Casey Schaufler wrote: --- James Morris [EMAIL PROTECTED] wrote: On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner That's an eternity for that many files to be improperly labeled. If, and the if didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the safe argument. They've been known to balk before. To clarify: We are discussing a scheme where the underlying SELinux labeling policy always ensures a safe label on a file, and then relabeling newly created files according to their pathnames. There is no expectation that this scheme would be submitted for certification. Its purpose is to merely to provide pathname-based labeling outside of the kernel. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 15, 2007 at 09:21:57PM -0400, James Morris wrote: On Fri, 15 Jun 2007, Greg KH wrote: Oh great, then things like source code control systems would have no problems with new files being created under them, or renaming whole trees. It depends -- I think we may be talking about different things. If you're using inotify to watch for new files and kick something in userspace to relabel them, it could take a while to relabel a lot of files, although there are likely some gains to be had from parallel relabeling which we've not explored. What I was saying is that you can use traditional SELinux labeling policy underneath that to ensure that there is always a safe label on each file before it is relabeled from userspace. Ok, yes, I think we are in violent agreement here :) So, so much for the it's going to be too slow re-labeling everything issue, as it's not even required for almost all situations :) You could probably get an idea of the cost by running something like: $ time find /usr/src/linux | xargs setfattr -n user.foo -v bar On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner, on a stock standard ext3 filesystem with a SATA drive. Yeah, that should be very reasonable. I'll wait to see Crispin's code to work off of and see if I can get it to approach that kind of speed. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
[EMAIL PROTECTED] wrote: On Sun, 10 Jun 2007, Pavel Machek wrote: But you have that regex in _user_ space, in a place where policy is loaded into kernel. then the kernel is going to have to call out to userspace every time a file is created or renamed and the policy is going to be enforced incorrectly until userspace finished labeling/relabeling whatever is moved. building this sort of race condigion for security into the kernel is highly questionable at best. AA has regex parser in _kernel_ space, which is very wrong. see Linus' rants about why it's not automaticaly the best thing to move functionality into userspace. remember that the files covered by an AA policy can change as files are renamed. this isn't the case with SELinux so it doesn't have this sort of problem. How about using the inotify interface on / to watch for file changes and updating the SELinux policies on the fly. This could be done from a userspace daemon and should require minimal SELinux changes. The only possible problems I can see are the (hopefully) small gap between the file change and updating the policy and the performance problems of watching the whole system for changes. Just my $0.02. Jack - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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, 14 Jun 2007, Jack Stone wrote: [EMAIL PROTECTED] wrote: On Sun, 10 Jun 2007, Pavel Machek wrote: But you have that regex in _user_ space, in a place where policy is loaded into kernel. then the kernel is going to have to call out to userspace every time a file is created or renamed and the policy is going to be enforced incorrectly until userspace finished labeling/relabeling whatever is moved. building this sort of race condigion for security into the kernel is highly questionable at best. AA has regex parser in _kernel_ space, which is very wrong. see Linus' rants about why it's not automaticaly the best thing to move functionality into userspace. remember that the files covered by an AA policy can change as files are renamed. this isn't the case with SELinux so it doesn't have this sort of problem. How about using the inotify interface on / to watch for file changes and updating the SELinux policies on the fly. This could be done from a userspace daemon and should require minimal SELinux changes. The only possible problems I can see are the (hopefully) small gap between the file change and updating the policy and the performance problems of watching the whole system for changes. as was mentioned by someone else, if you rename a directory this can result in millions of files that need to be relabeled (or otherwise have the policy changed for them) that can take a significant amount of time to do. David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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-10T23:05:47, Pavel Machek [EMAIL PROTECTED] wrote: But you have that regex in _user_ space, in a place where policy is loaded into kernel. AA has regex parser in _kernel_ space, which is very wrong. That regex parser only applies user defined policy. The logical connection between your two points doesn't exist. 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-fsdevel 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 Sun, 10 Jun 2007, Pavel Machek wrote: extended out this can come close to giving each file it's own label. AA essentially does this and calls the label the path and computes it at runtime instead of storing it somewhere. Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take each file it's own label over _that_ any time. and if each file has it's own label you are going to need regex or similar to deal with them as well. But you have that regex in _user_ space, in a place where policy is loaded into kernel. then the kernel is going to have to call out to userspace every time a file is created or renamed and the policy is going to be enforced incorrectly until userspace finished labeling/relabeling whatever is moved. building this sort of race condigion for security into the kernel is highly questionable at best. AA has regex parser in _kernel_ space, which is very wrong. see Linus' rants about why it's not automaticaly the best thing to move functionality into userspace. remember that the files covered by an AA policy can change as files are renamed. this isn't the case with SELinux so it doesn't have this sort of problem. David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 Sun, 10 Jun 2007, Crispin Cowan wrote: Casey Schaufler wrote: --- [EMAIL PROTECTED] wrote: Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take each file it's own label over _that_ any time. and if each file has it's own label you are going to need regex or similar to deal with them as well. Now that you're going to have to explain. Nothing like that on any of the MLS systems I'm familiar with, and I think that I know just about all of them. I suspect that David meant that if you were using unique label per file as an implementation technique to implement AA on top of SELinux, that you would then need a regexp to discern labels. exactly. say that we give each file a unique label, and for simplicity we set the label == path (note that this raises the issue, what will SELinux do when there are multiple paths to the same file) now say that you want to grant apache access to all files that have labels that follow the pattern '/home/*/http/* ? you are either going to use regex matching, or you are going to have to enumerate every label that matches this (potentially a very large list). and if you try to generate the enumerated list you need to add a label to the list if a file is renamed or created to match the pattern, and delete a file from the list if it is renamed to no longer match the pattern It's hard to recall with all the noise, but at this point in the thread the discussion is about the best way to implement AA. Some have alleged that AA layered on top of SELinux is the best way. I think that is clearly wrong; AA layered on top of SELinux is possible, but would require a bunch of enhancements to SELinux first, and the result would be more complex than the proposed AA patch and have weaker functionality and performance. AA as-is needs to figure out how to deal with bind-mounts, and how to handle hardlink creation in a more ganular manner (and potentially other resources like network sockets), but it's useful now even without these improvements AA over SELinux would need for SELinux to figure out how to handle file creation, file renames, and multiple paths for the same file (hard-links and bind-mounts). In addition a userspace daemon would have to be written to re-label files and/or change policy on the fly as files are renamed. the result would still have race conditions due to the need to re-label large numbers of files ACPI should have taught everyone that sometimes putting an interpreter in the kernel really is the best option. looking at the problems of bouncing back out to userspace for file creation and renames it looks like a regex in the kernel is a lot safer and more reliable. David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 Sun, 10 Jun 2007 23:45:16 -0700 (PDT) [EMAIL PROTECTED] wrote: say that we give each file a unique label, and for simplicity we set the label == path (note that this raises the issue, what will SELinux do when there are multiple paths to the same file) So don't do that then. now say that you want to grant apache access to all files that have labels that follow the pattern '/home/*/http/* ? you are either going to use regex matching, or you are going to have to enumerate every label that matches this (potentially a very large list). and if you try to generate the enumerated list you need to add a label to the list if a file is renamed or created to match the pattern, and delete a file from the list if it is renamed to no longer match the pattern If AA requires regex matching in the kernel, perhaps it really isn't appropriate for inclusion. Surely there has to be a better way than requiring the kernel to do regex matches at runtime? AA over SELinux would need for SELinux to figure out how to handle file creation, file renames, and multiple paths for the same file (hard-links and bind-mounts). In addition a userspace daemon would have to be written to re-label files and/or change policy on the fly as files are renamed. the result would still have race conditions due to the need to re-label large numbers of files WRONG. The labels would be obtained from AA as needed, never recorded in the file attributes. This would change nothing about what AA needed to compute at runtime, just the way it implements the result. ACPI should have taught everyone that sometimes putting an interpreter in the kernel really is the best option. looking at the problems of bouncing back out to userspace for file creation and renames it looks like a regex in the kernel is a lot safer and more reliable. There hasn't yet been shown a requirement for a userspace daemon to implement AA over SeLinux. Sean - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Hi! ACPI should have taught everyone that sometimes putting an interpreter in the kernel really is the best option. looking at the problems of bouncing back out to userspace for file creation and renames it looks like a regex in the kernel is a lot safer and more reliable. What do ACPI and AA have in common? * they both start with A * there are both nightmare * they both put interpretter into kernel 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-fsdevel 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 Mon, 11 Jun 2007 02:33:30 -0700 (PDT) [EMAIL PROTECTED] wrote: Ok, you are proposing throwing out all the label handling that SELinux does, including any caching. forgive me if I agree with the SELinux people that this is a very bad idea. Well presumably AA would be doing caching etc.. so that doesn't seem like a problem. The SELinux people seem to think that accepting AA into the kernel and supporting path based security at all is a mistake. I guess I forgive you for agreeing with them ;) I thought the userspace component was what you were proposing instead of doing the regex matching in the kernel. if this isn't it what exactly are you proposing? No.. i've said quite a few times now that i'm not talking about calling out to userspace. The entire discussion of regex matching is a completely separate discussion. It's either the right thing to do, or not. But the same issues in regard to regex matching apply whether AA is built on top of SELinux or not. AA policies are defined in terms of regex expressions. you say that this should be able to be done on top of SELinux somehow without changing the policies. so somewhere, something needs to interpret the regex to see if it matches the path. this needs to be either kernel code or userspace code. you have ruled out kernel code and are now claiming that userspace isn't needed. For whatever it's worth, i'll repeat again. The AA kernel extension would be associating paths with labels (using regex, or not). At that point all policy decisions would be enforced by SELinux using standard SELinux policy rules. The SELinux policy would be a translated version of the AA policy file. The translation could of course happen in userland. The net affect of all that... is that you get a version of SELinux which can be configured with the user friendly AA policy file format. And, files won't need to carry around security labels with them. I leave the debate about whether that's a good idea in general to others. But from what i can tell, it's the only significant difference between SELinux and AA. Depending on the way it was implemented, its conceivable that users could mix and match native SELinux policy with custom AA policies as they saw fit. Sean - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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 Sat, 2007-06-09 at 00:03 +0200, Andreas Gruenbacher wrote: On Wednesday 06 June 2007 15:26, Stephen Smalley wrote: - under AA, each file may have an arbitrary set of labels or policies applied to it depending on what programs are accessing it and what names are being used to reference it - there is no system view of the subjects and objects and thus no way to identify the overall system policy for a given file. Look at it this way: under SELinux, the set of files that share a label forms an equivalence class -- they are all treated identically by the system's security policy. The rules in AppArmor profiles also define equivalence classes in the sense that they partition the filesystem namespace into sets of files that are treated identically, but this classification is not explicit -- the entire rule base contributes to the classification. This doesn't mean that there is not a global policy, just that the policy is modeled differently. The equivalence classes are not directly obvious from the AA profiles. No, it really does mean that there is no global policy, and it goes beyond not directly obvious to can not be determined from the AA profiles. You can't compose the set of AA profiles and say anything useful, because they are written in terms of ambiguous and unstable identifiers. /a/b/c may refer to completely different objects in two different profiles, or to the same object as /d/e/f in the same or another profile. Contrast this with SEEdit, which compiles AA-style rules into labels (and thus equivalence classes). The resulting SELinux policy is a static snapshot that cannot easily accommodate rule base changes, is more limited with respect to new files (which would likely be fixable), and behaves differently in complex ways with file renames. What's more, most likely the compiled policy will be anywhere from very hard to impossible to analyze, so you pretty much lose on all ends. Just to clarify, you can change the allowed accesses from a given subject to a given object without relabeling, just by changing the policy allow rules; you only have to relabel the object in the case where you want to distinguish that object from another object with the same label for the same subject. I think the new file situation could be improved without any major change to the SELinux model, and am not opposed to leveraging the component name there, as previously noted. On the file rename case, I think we have it right - access rights shouldn't change automatically when a file is renamed, any more than DAC ownership or file modes should. - names are far less tranquil than labels. If I'm getting things right, a tranquil system with respect to labels would be one that does not permit re-labeling, while a tranquil system with respect to path names would be one that does not permit renaming. Both approaches would buy greater analyzability with reduced usability, and both seem unrealistic to me. SELinux and AppArmor evidently have different goals, and tranquility is more important to SELinux. Tranquility is important to correctness and understandability of policy; if labels (or pathnames in your case) can change at any time, then you have the problems of revocation of access (impractical to completely implement in Linux) and your effective policy now varies over time, so you have to consider time as a factor in your policy analysis. AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. SELinux is applicable in areas where AppArmor is not (e.g., MLS), but this comes at a cost. For me the question is not SELinux or AppArmor, but if AppArmor's security model is a good solution in common scenarios. In my opinion, AppArmor is a better answer than SELinux in a number of scenarios. This gives it value, nonwithstanding the fact that SELinux can be taken further. I'd agree that we shouldn't try to emulate AA as it is on SELinux. The question is more of whether we can meet the higher level functionality goals that make some people want to use AA via SELinux. That requires separating those goals from the implementation details of AA. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Hi! So, AA developers, do you have such a document anywhere? I know there are some old research papers, do they properly describe the current model you are trying to implement here? Greg, to implement the AA approach useing SELinux you need to have a way that files that are renamed or created get tagged with the right label automaticaly with no possible race condition. If this can be done then it _may_ be possible to do the job that AA is aimed at with SELinux, but the work nessasary to figure out what lables are needed on what file would still make it a non-trivial task. as I understand it SELinux puts one label on each file, so if you have three files accessed by two programs such that program A accesses files X Y program B accesses files Y Z then files X Y and Z all need seperate labels with the policy stateing that program A need to access labels X, Y and program B needs to access files Y Z extended out this can come close to giving each file it's own label. AA essentially does this and calls the label the path and computes it at runtime instead of storing it somewhere. Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take each file it's own label over _that_ any time. 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-fsdevel 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 Sun, 10 Jun 2007, Pavel Machek wrote: Hi! So, AA developers, do you have such a document anywhere? I know there are some old research papers, do they properly describe the current model you are trying to implement here? Greg, to implement the AA approach useing SELinux you need to have a way that files that are renamed or created get tagged with the right label automaticaly with no possible race condition. If this can be done then it _may_ be possible to do the job that AA is aimed at with SELinux, but the work nessasary to figure out what lables are needed on what file would still make it a non-trivial task. as I understand it SELinux puts one label on each file, so if you have three files accessed by two programs such that program A accesses files X Y program B accesses files Y Z then files X Y and Z all need seperate labels with the policy stateing that program A need to access labels X, Y and program B needs to access files Y Z extended out this can come close to giving each file it's own label. AA essentially does this and calls the label the path and computes it at runtime instead of storing it somewhere. Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take each file it's own label over _that_ any time. and if each file has it's own label you are going to need regex or similar to deal with them as well. David Lang - To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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
Andreas Gruenbacher wrote: On Saturday 09 June 2007 02:17, Greg KH wrote: On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. Woah, that describes the userspace side of AA just fine, it means nothing when it comes to the in-kernel implementation. There is no reason that you can't implement the same functionality using some totally different in-kernel solution if possible. I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is if possible, and in fact if possible is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible. In particular, to layer AppArmor on top of SELinux, the following problems must be addressed: * New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says /home/*/.plan r to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux. * Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename. * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. * New Policies: The SEEdit approach of compiling AA profiles into SELinux labels involves computing the partition set of files, so that each element of the partition set is unique, and corresponds to all the policies that treat every file in the element identically. If you create a new profile that touches *some* of the files in such an element, then you have to split that synthetic label, re-compute the partition set, and re-label the file system. * File Systems That Do Not Support Labels: The most important being NFS3 and FAT. Because they do not support labels at all, SELinux has to give you an all-or-nothing access control on the entire remote volume. AA can give you nuanced access control in these file systems. You could support all of these features in SELinux, but only by adding an in-kernel file matching mechanism similar to AppArmor. It would basically load an AppArmor policy into the kernel, label files as they are brought from disk into the cache, and then use SELinux to do the access controls. That doesn't make it a good idea: * The patch would be at least as complex and intrusive as the proposed AppArmor patch, there is no simplicity already-upstream savings here. * It would require the VFS and d_path patches that AppArmor needs to pass mount points down. * It would make AppArmor's ability to change policies on a live system more difficult. * The necessary extensions would not be appealing to the SELinux community. LSM is the common code that AA and SELinux have agreed to be mutually useful. Forcing AA to sit on top of SELinux would harm both AA and SELinux. 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-fsdevel 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
--- [EMAIL PROTECTED] wrote: Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take each file it's own label over _that_ any time. and if each file has it's own label you are going to need regex or similar to deal with them as well. Now that you're going to have to explain. Nothing like that on any of the MLS systems I'm familiar with, and I think that I know just about all of them. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
