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/