Prev: fork problem in multithreaded process -- segmentation fault seen
Next: [PATCH 2/2 V3] io-controller: Document for blkio.weight_device
From: Linus Torvalds on 8 Mar 2010 14:20 On Mon, 8 Mar 2010, Linus Torvalds wrote: > > Sure, there is content security. Nobody disputes that. The security > decision about how to open a file is about the contents of the file. Btw, I would also say that content security is generally the _common_ case. So I'm not at all saying that the traditional unix model or the selinux model is in any way "wrong". Not at all. It's just that I certainly understand why some people think AppArmor is more "intuitive". And I think it's directly related to the fact that sometimes the pathname-based approach is the one that more directly reflects the particular issue (and people are often happy with the traditional UNIX semantics for plain inode-based security, so again, it's not like AppArmor _replaces_ inode-based security, it _extends_ on it). 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: Alan Cox on 8 Mar 2010 14:20 > 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. SELinux uses both. Things like "I put a file in my public_html directory" are a good example. Its object based in the sense that the origin of the data might matter (eg 'no app which opens the credit card db creates a file httpd can send') Its path based in the sense that public_html has a path based meaning by convention understood by httpd. Copy a jpeg into your public_html and it will be labelled up for http access under the Fedora shipped rule sets. 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: Al Viro on 8 Mar 2010 14:20 On Mon, Mar 08, 2010 at 10:59:11AM -0800, Linus Torvalds wrote: > > 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. And mapping from names to files is a function of contents of many objects. You need to protect that contents on all objects involved *anyway*. Which leaves what for "protecting by pathname"? I'm not saying that it's either or. I am saying that it's been oversold to hell and back, BTW, but that's a separate story. And I'm very sceptical about separate protection of different directory entries, which is *all* that is left for pathname-based stuff, AFAICS. -- 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:40 On Mon, 8 Mar 2010, Alan Cox wrote: > > Its path based in the sense that public_html has a path based meaning by > convention understood by httpd. Copy a jpeg into your public_html and it > will be labelled up for http access under the Fedora shipped rule sets. Umm. That was my point all along: you can basically "emulate" pathname based decisions by labeling things. But it's not always the most direct approach, and some people clearly do find AppArmor (or Tomoyo, which I think is also largely based on pathnames) to be more "intuitive". So I don't understand it when people then complain about a mechanism that base their decisions fundamentally on the pathname. It's not like AppArmor got rid of the traditional unix inode-based protections and replaced them (like your silly DEC10 example). But whatever. The fact is, Ubuntu uses it. We'll merge it. 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: James Kosin on 8 Mar 2010 14:40
On 3/8/2010 2:20 PM, Linus Torvalds wrote: > > > > My whole (and only) argument is against the "only one way is correct" > mentality. > > Linus > -- Well said Linus. If there where only one way to do this, it would have been done long ago. Fortunately, or unfortunately, there are about as many ways as there are grains of sand. James K. -- 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/ |