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: Luca Barbieri on 8 Mar 2010 21:00 >> 4. It doesn't matter at all if anyone reads a file that happens to be >> at /etc/shadow while not containing shadow passwords (with the same >> path, but different content) > > What the hell are you smoking? I mean, what is interesting for security of reading is the fact that the file contains shadow passwords (and thus is labeled as "secret" or with a specific label), not that it is at /etc/shadow. The same security check would need to apply to an administrator's backup copy of /etc/shadow, but would not need to apply in the hypotetical case that /etc/shadow did not contain shadow passwords, but, say, was empty or contained a pointer to a network server to use. This is to illustrate the point, not something expected to happen; it also represents the ideal security model, not necessarily any concrete one. So what really is interesting for reads is what the content is (in practice, what the content label is), not the path. For writes, it is exactly the opposite: you don't care about writing to a private copy, but you don't want to let a random file be put on a system path. For instance, if I copy /etc/passwd somewhere else, the result should have the same content label (since it is identical), but I should now be able to write to it since the path allows me to. -- 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 21:00 On Tue, 9 Mar 2010, Al Viro wrote: > > BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_ > sadistic), you'll see how seriously do they take pathname-based *anything*. > LSM hooks for namespace operations (you know, mount, umount) are lousy, but > they exist. Not used by apparmor. That's a good point, btw, and shows one conceptual difference between content-based and pathname-based rules. For example, if you want to log any changes to "/etc/passwd" (which is something pretty reasonable to do at least conceptually), what about doing a bind mount on top of that file? That bind mount doesn't actually change the underlying file in any way. It doesn't even really _access_ it. From a content standpoint of the filesystem that contains the file, it's a total no-op. But from an attack standpoint, you don't actually care, because nobody cares about the inode that used to be the contents of "/etc/passwd": all anybody _really_ cares about is "could somebody change what happens to the _name_ '/etc/passwd'". But yeah, it's easy to overlook namespace changes when the obvious operations are read/write/unlink/rename. And I'm not at all surprised that people do. 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 21:00 On Tue, Mar 09, 2010 at 02:51:55AM +0100, Luca Barbieri wrote: > >> 4. It doesn't matter at all if anyone reads a file that happens to be > >> at /etc/shadow while not containing shadow passwords (with the same > >> path, but different content) > > > > What the hell are you smoking? > > I mean, what is interesting for security of reading is the fact that > the file contains shadow passwords (and thus is labeled as "secret" or > with a specific label), not that it is at /etc/shadow. <sarcasm> Yeah, especially when it's read by sshd. Who cares, indeed? So it's got a passwordless root, that's even better, right? Nobody will see your real root password that way... </sarcasm> -- 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 21:10 On Mon, Mar 08, 2010 at 05:49:10PM -0800, Linus Torvalds wrote: > That's a good point, btw, and shows one conceptual difference between > content-based and pathname-based rules. > > For example, if you want to log any changes to "/etc/passwd" (which is > something pretty reasonable to do at least conceptually), what about doing > a bind mount on top of that file? Doesn't have to be a binding over /etc/passwd, BTW. /etc as a mountpoint will serve just as well. -- 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: Luca Barbieri on 8 Mar 2010 21:10
> <sarcasm> > Yeah, especially when it's read by sshd. �Who cares, indeed? �So it's got > a passwordless root, that's even better, right? �Nobody will see your > real root password that way... > </sarcasm> Not sure what you mean exactly. You won't have a passwordless root if you don't allow anyone to modify the file at /etc/shadow, or change that dentry by deleting a file there or putting an arbitrary file there (with creat, rename or link). This is conceptually a path-based security check. It is also separate from the problem of not giving anyone knowledge of the root password or hash of it, which a conceptually content-based security check on reads. -- 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/ |