lkml.org 
[lkml]   [1998]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: autofs vs. Sun automount -- new fs proposal
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.041 / U:0.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site