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

    At last, a decent example. Now my alternative:

    You allocate a group for every ftp user, you make your files group
    readable, but you have them owned by a different user. Now each ftp
    user can read only the files that they are supposed to read, but they
    can't write to those files.

    The most trivial example is anonymous ftp. There is just one ftp user -
    "anonymous", and you check that the anonymous user cannot write to any
    files or directories.

    If you are imagining a situation where you allow users to write to
    files and directories if they are logged in, but not via ftp, then I
    don't see the point - ie. you are solving a problem which doesn't exist.

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

    If you can trick it into doing that, you're probably doomed anyway.
    This can, and should, be fixed by changing the design of the ftp
    daemon so give it a more obvious security boundary. The interactaction
    with the unauthenticated user should not be done as root; only the
    part of ftpd that switches user needs privilege. That part should take
    in a password, verify it, change uid, and call the rest of the ftpd -
    the privileged part will then be small and therefore easier to get right.

    > I'm not saying that read-only lofs is the answer to all security
    > problems, but it would help tighten security in one area.

    I don't think its the solution to any of the CERT advisories, and it
    is a very poor solution for programs running as root (for the same
    reason that chroot is), but you have convinced me that it's not
    completely worthless.

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

    If it's easy, then yes I agree. However, if you think a read-only lofs
    is important, you need to think about how to do it now and not try and
    layer it on afterwards.

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

    The implementation is correct; it's the *design* that's wrong -
    implementing read-only in their design is very difficult. It is,
    however, an obvious design, and it is likely to have been repeated
    elsewhere, which is why I would never write code that depended on the
    'obvious' semantics of read-only lofs.

    The same problems may occur in Linux unless read-only is part of the
    design. That is why I wanted you to give a justification now, rather
    than waiting until a lofs implementation is complete.

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