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/