Upstream first policy
in [Kernel]
|
Prev: fork problem in multithreaded process -- segmentation fault seen
Next: [PATCH 2/2 V3] io-controller: Document for blkio.weight_device
From: Eric Paris on 8 Mar 2010 18:20 On Mon, Mar 8, 2010 at 5:12 PM, Ulrich Drepper <drepper(a)gmail.com> wrote: > On Mon, Mar 8, 2010 at 10:08, Linus Torvalds > <torvalds(a)linux-foundation.org> wrote: >> Notice how it's really fundamentally about the pathname? When you create a >> new file and overwrite /etc/passwd with that file, the security rules >> really do _not_ come from your newly created inode, they come from the >> fact that you made the path "/etc/passwd" point to that inode. > > This is not a fundamental problem. �It's rather a detail of the > current policies and legacy apps. > > I think I would like to see /etc/passwd to also get a file type like > /etc/shadow. �This is I think today not done because of the work > involved and the perceived lower severity because passwords are in > /etc/shadow. > > So let's talk about /etc/shadow. �If somehow the file is removed and > somebody creates a new file that file won't automatically get the > right label. �This means that code reading the file then could be > prevented from doing this with appropriate policy rules. �Here the > filename is not sufficient for access. �You also need the label and > that you won't get without subverting the system. �With filename based > mechanisms this isn't the case: once the file is compromised the > attack succeeded. > > Yes, the current situation isn't optimal. �We have to make the > policies more complicated and we have to get rid of restorecond (at > least for most cases). �But there is no fundamental problem with > labels while filename-based mechanisms provide no security > improvement. At the moment the default label of a new file is created based on the label of the creating process and the label of the parent directory. It's certainly not impossible that a third factor could be added 'the last component of the pathname of the new inode' to the decision matrix. Doing so would eliminate the need for restorecond in most (or maybe all) situations while maintaining the useful security principles of label based enforcement. It actually has been suggested and implemented, but as I recall we were told it violated some VFS rules to pass the information we passed where we passed it and it was abandoned. *tongue in cheek* if TOMOYO and AppArmour can do thing which the VFS maintainer say is wrong and unacceptable merely by sending them to the security maintainer instead I guess SELinux can do that as well! answering a different post in the same email: I accept "THERE ARE DIFFERENT CASES." You go on to say "So I'm not suggesting we _replace_ content-based security with pathname-based security. I'm just saying that pathnames actually do matter for security, and that they are an independent issue." But what you are suggesting is EXACTLY that our users should _replace_ content-based security with pathname-based security when they have to boot with security=TOMOYO instead of security=SMACK. Rather than finding a flexible framework, finding problems or inadequacies in that framework, and solving those problems you instead force our users to have to choose between LSMs which are either A) secueable but non-intuitive or B) not securable but known to be 'easier'. I think the inode based security view as a hammer might not be all that bad. It works really well on nails (you know the truely hard well researched security questions) and it can beat screws into a piece of wood as well (although sometimes the wood cracks). Calling pathname based security a screwdriver fits too, it can put the screws in but we know there are a lot of nails out there which it can't ever deal with. Personally I think we should all get together and agree on a framework and fix the framework to meet all of the needs and look like a swiss army hammer driver drill thing rather than having 4 options, none of which meet all the needs, and then forcing our uneducated users to choose between them. But, hey, we all know that isn't going to happen so I'll just go back to happy go lucky dream land where Linus is not running around naked with a chain saw. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 8 Mar 2010 18:30 On Mon, 8 Mar 2010, Eric Paris wrote: > > answering a different post in the same email: I accept "THERE ARE > DIFFERENT CASES." You go on to say "So I'm not suggesting we > _replace_ content-based security with pathname-based security. I'm > just saying that pathnames actually do matter for security, and that > they are an independent issue." But what you are suggesting is > EXACTLY that our users should _replace_ content-based security with > pathname-based security when they have to boot with security=TOMOYO > instead of security=SMACK. No. Because we already _have_ content-based security. The traditional UNIX model is all about "labeling", ie the inode-based security. The fact that the extended security is then using something else in Tomoyo or AppArmor doesn't remove the traditional security model. Again, your whole email is just "assuming" that selinux is the thing to be. No logic to your post at all. If you are using a AppArmor-based thing, you're not "switching" from SELinux to AppArmor. You're just using it. Get it? The Ubuntu people seem to be happy with AppArmor. Deal with it. SELinux isn't the end-all and be-all of everything. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 8 Mar 2010 18:40 On Mon, 8 Mar 2010, Rik van Riel wrote: > > On the other hand, '/etc/shadow' has the opposite constraint, > where the system will not trust most of the applications with > the data from that file. Umm. No. /etc/shadow is in no way at all different from /etc/passwd. Both of them have pathname-based security issues. The fact that both of them _also_ have content-based security issues is an independent issue that I just assumed everybody would take for granted. Clearly I assumed too much. So I was assuming that everybody realized that the normal inode-based UNIX security obviously means that you can only open /etc/passwd read-only as any normal user (and not open /etc/shadow at all: but that is in _no_ way different from /etc/passwd). That's an example of non-pathname-based security, where you actually mark the content itself restricted some way. It's very naturally done with labels on the inode itself. It's what UNIX has _always_ done Nobody has ever suggested removing that. That would be crazy. But that thing is _independent_ from the other totally unrelated issue, namely the fact that "/etc/passwd" is a special name in the namespace. In other words, there is "content security", but then there is also "namespace security". Of course, you can make /etc unwritable, and that is indeed the traditional UNIX model of handling namespace security: by just implementing it as "content security" of the directory. The sgid and sticky bits can be used to further try to make it more fine-grained (exactly becuase it is _not_ sufficient to say "you can't read or write this directory" on a whole-directory basis), and obviously SELinux has extensions of its own too. Can you really not see the difference between security of naming thigns certain things (like "/etc/passwd") - pathname based issues - and the separate security of limiting access to any named device - actual markings on the inode itself? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel on 8 Mar 2010 19:00 On 03/08/2010 06:37 PM, Linus Torvalds wrote: > That's an example of non-pathname-based security, where you actually mark > the content itself restricted some way. It's very naturally done with > labels on the inode itself. It's what UNIX has _always_ done > > Nobody has ever suggested removing that. That would be crazy. It is quite clear that the content based security protects the content from being manipulated by processes that should not be able to do so. However, what is unclear to me is ... > But that thing is _independent_ from the other totally unrelated issue, > namely the fact that "/etc/passwd" is a special name in the namespace. In > other words, there is "content security", but then there is also > "namespace security". .... what exactly does the namespace security protect against? What is the threat model that the namespace security protects against, which is not protected by the content based security? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Al Viro on 8 Mar 2010 19:20
On Mon, Mar 08, 2010 at 03:37:38PM -0800, Linus Torvalds wrote: > Of course, you can make /etc unwritable, and that is indeed the > traditional UNIX model of handling namespace security: by just > implementing it as "content security" of the directory. > > The sgid and sticky bits can be used to further try to make it more > fine-grained (exactly becuase it is _not_ sufficient to say "you can't > read or write this directory" on a whole-directory basis), and obviously > SELinux has extensions of its own too. But that's not what the apparmor et.al. are doing. If you want (and that's not obviously a good thing) fine-grained access control for directory entries, it would at least make some sense. Prohibitively pricy, probably, but that's a separate story. But they are *NOT* protecting /foo/bar directory entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards root. And if you *do* protect each ancestor and try to keep granularity, you'll end up with complexity from hell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |