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: Alan Cox on 8 Mar 2010 12:40 > In that sense it appears to me that it's pretty much a universal truth that > 'pathnames' are a far more fitting abstraction to any 'human based security Ingo - just about all the serious security work disagrees with you. Pathnames are references to objects and keep changing. What matters is the object itself. This is also how Unix has always worked Imagine if chmod applied to the path not the inode ? > Also, why was/(is?) AppArmor considered as a 'hostile competitor' I don't believe it was. It was perceived as a technical failure, and then the file system people shredded the bits the security folks didn't. There are certain things path name bases security works quite nicely for, primarily systems that have no concept of links. It's why it works ok-ish for httpd but for the general case nobody has ever really made it work properly. Alan -- 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 13:10 On Mon, 8 Mar 2010, Alan Cox wrote: > > Ingo - just about all the serious security work disagrees with you. > Pathnames are references to objects and keep changing. What matters is > the object itself. This is also how Unix has always worked The thing is, that's simply not the whole truth. It's _part_ of the truth, but there very much are pathname-based security in Unix too, including very much traditionally. Things like "/etc/passwd" really are about the _pathname_, not the inode. It really is the _path_ that is special, because that is fundamentally the thing you trust. You can try to turn that into a content-based security issue by claiming that it's about the "content of the '/etc' directory", and that is (along with other tricks) obviously how a a content-based security model has to work. But it's not actually _true_ in any deeper sense. You're really just trying to enforce a pathname-based model using a inode/content based security hammer. So that's an example of "if all you have is a hammer, everything looks like a nail" issue. If all you have is a content/inode-based security, you have to turn path-names into "directory inode" issues, and it's doable, but it's really like trying to convince everybody that screws do not exist because all you have is a hammer. And when you base your security on inodes, you _do_ have problems with things like /etc. Exactly because there are many different paths in that directory, and they actually have _different_ security issues. A program that is supposed to be able to edit/replace /etc/hosts is _not_ supposed to be able to edit/replace /etc/passwd. 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. And again - you can emulate this with the inode-based thing. Your hammer does work, but it doesn't really invalidate the fact that the path really is what is most fundamental in that case, because the pathname is fundamentally the shared piece of information that different processes work with. You end up making up new ideas to handle this: it's why traditional BSD UNIX security has the setgid and sticky bit on directories, and it's also obviously why selinux ends up having special rules for "link" and "rename" etc - exactly so that you can emulate security that is really fundamentally about the pathname. In other words: it really _does_ make more sense to say "this process has rights to overwrite the path '/etc/passwd'" than it does to try to label the file. The _fundamental_ rule is about the pathname. The labeling comes about BECAUSE YOU USED A HAMMER FOR A SCREW. I really don't understand why some people are unable to admit this fact. 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: Al Viro on 8 Mar 2010 13:50 On Mon, Mar 08, 2010 at 10:08:31AM -0800, Linus Torvalds wrote: > In other words: it really _does_ make more sense to say "this process has > rights to overwrite the path '/etc/passwd'" than it does to try to label > the file. The _fundamental_ rule is about the pathname. The labeling comes > about BECAUSE YOU USED A HAMMER FOR A SCREW. > > I really don't understand why some people are unable to admit this fact. Because you don't have to use that pathname to modify the bits returned by read() after open() on that pathname? I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply doesn't match how the pathname resolution is defined on Unix... -- 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: Alan Cox on 8 Mar 2010 14:10 > Things like "/etc/passwd" really are about the _pathname_, not the inode. > It really is the _path_ that is special, because that is fundamentally the > thing you trust. Why can I trust the path ? > But it's not actually _true_ in any deeper sense. You're really just > trying to enforce a pathname-based model using a inode/content based > security hammer. Quite untrue. I've actually *used* path based security systems (DEC10 ACLs) and for almost every case its brain-dead. Imagine a world where this happened echo "hello" > fred chmod 666 fred ls -l fred fred rw-rw-rw- mv fred bill ls -l bill bill rw------- week later vi fred ls -l fred fred rw-rw-rw- Your password file is a special case > And when you base your security on inodes, you _do_ have problems with > things like /etc. Exactly because there are many different paths in that > directory, and they actually have _different_ security issues. A program > that is supposed to be able to edit/replace /etc/hosts is _not_ supposed > to be able to edit/replace /etc/passwd. In a secure system I don't just care if its called /etc/passwd. I care that whoever made changes to it was trusted to do so and furthermore that the suid binary, the libraries it relies upon and the other points of trust that matter. Real security is *not* a file permissions system its a trust model including things like integrity validation. Another reason this is true is how passwd is updated - the tool creates a new file of some name like passwd.tmp and does processing into that, then renames it over the top. If I break passwd.tmp then you'll trust the result "because it's called passwd", while a system that keeps permissions and labels attached to the object will not because someone tampered with the object that became passwd. > 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. No - they come from whatever created or modified the file. It doesn't matter what an object is called if I need to know whether the data in it is honest. > You end up making up new ideas to handle this: it's why traditional BSD > UNIX security has the setgid and sticky bit on directories, and it's also > obviously why selinux ends up having special rules for "link" and "rename" > etc - exactly so that you can emulate security that is really > fundamentally about the pathname. The directory bits move with the directory - they are object permissions to retrofit delete permission (a gap in the original Unix design) and a very crude inheritance hack. They are not about paths. If you mv a file into a directory with these properties they don't magically inherit the properties. > the file. The _fundamental_ rule is about the pathname. The labeling comes > about BECAUSE YOU USED A HAMMER FOR A SCREW. > > I really don't understand why some people are unable to admit this fact. Perhaps because - They understand what they are talking about and have studied the research - They've got a grasp of the mathematical/logical models that this is all based upon - They know the difference between access control lists and security models - They aren't so arrogant as to assume that using the capslock key overrides fifty years of research ?? Alan -- 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 14:10
On Mon, 8 Mar 2010, Al Viro wrote: > > > > I really don't understand why some people are unable to admit this fact. > > Because you don't have to use that pathname to modify the bits returned > by read() after open() on that pathname? The thing is, I don't think it's an "either or". Sure, there is content security. Nobody disputes that. The security decision about how to open a file is about the contents of the file. 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. > I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply > doesn't match how the pathname resolution is defined on Unix... Again, I'm not claiming that we should change how "open" works and has always worked. I don't even understand why you have that crazy "either or" mentality to begin with. Why? It's not "either pathname or inode". I'm saying _both_ make sense. In some situations, the name itself really is what is fundamentally special about the file. 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/ |