Messages in this thread | | | From | (Peter Benie) | Subject | Re: autofs vs. Sun automount -- new fs proposal | Date | Thu, 17 Dec 1998 10:35:22 +0000 |
| |
Richard Gooch writes ("Re: autofs vs. Sun automount -- new fs proposal"): > Peter Benie writes: > > > > If the server is running as one uid, and the file is owned by a > > different uid, then no amount of cracking will allow the server to > > write to the file (at least, not directly). > > > > A server might write to the file indirectly by exploiting bugs in > > privileged programs on the same machine. Chroot guards against most of > > those attacks. > > "Most" != "all".
I am comparing read-only loopback with other techniques. The attacks that chroot does not guard against have *nothing whatsoever* to do with loopback mounts. (If you think I'm wrong, educate me.)
> > > Sometimes network servers have to run as root. > > > > For most network servers, the part that must run as root is very > > small. Many servers are misdesigned and run all their code as root, > > but read-only lofs is not a quick fix for that problem. > > No, but it provides an extra level of security.
Nonsense. If read-only loopback mounts are made a standard feature of the Linux kernel, all the attacks against Linux will perform the necessary activities to circumvent the loopback mount, so you will gain you no extra security.
> Most of the exploits I see published in CERT relate to violating file > permissions, not to running arbitrary code as root. That's not to say > that the latter doesn't happen, just that the former seems more > likely. It's easier to find a file access weakness to exploit than a > root execution weakness.
As I said before, if your servers are running as a different uid, they shouldn't be able to violate your file permissions. Please give an example where this is not true.
> > Do you have any real applications for read-only loopback mounts that > > cannot be solved using conventional, portable techniques? > > Yeah, network servers, like I said. I've found "mount -o ro" to be > pretty portable. I don't think it's fair to label a read-only lofs as > unconventional and unportable.
Read only lofs is very unportable. Many Unix systems don't have loopback mounts at all, and flagging lofs as read-only doesn't always do what you expect.
On a Solaris system:
bash:~$ cat foo
(foo is an empty file)
bash:~$ mv foo bar mv: cannot rename foo: Read-only file system bash:~$ rm foo rm: foo not removed: Read-only file system
Correct. The working directory is on a read-only loopback filesystem.
bash:~$ cat >foo foobar bash:~$ cat foo foobar
Oops! This is why it's bad to write code that relys on read-only lofs.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |