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

I am talking about servers that can be tricked into letting you write
to any file, rather than only letting you write to a particular
file/directory. Incoming ftp is one that comes to mind. No breaking
out of chroot, no running arbitrary code, just tricking the server in
allowing you to write when it should have said "the configuration
doesn't allow you to do that".

> > 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.

Server running as root. Server is supposed to become some other user
(say the one you logged in as for ftp), but it's tricked. Then you
write a file somewhere. You can't chroot out, because the protocol
doesn't support that, but you can write places.

I'm not saying that read-only lofs is the answer to all security
problems, but it would help tighten security in one area. Now maybe
implementing it will result in a horribly bloated and inefficient lofs
implementation, in which case it might not be worth it. But because I
think a read-only lofs has some benefits, I'd like to pursue that
avenue.

Anyway, that's my position. We seem to be going round in circles
here. If a read-write lofs goes into the kernel and I think a
read-only lofs is possible without to much bloat (IMO), then I'll
write one and submit it.

> > > 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.

That's a flaw in their implementation.

Regards,

Richard....

-
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.108 / U:0.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site