dillon at apollo.backplane.com
Fri Aug 1 18:13:12 PDT 2003
:liberal about its interpretation of the VFS namespace: sometimes, you'd
:like to be able to say "What *is* the name of that vnode" -- if you want
:to log behavior in kernel, etc: lack of a real "name" for objects is
:counter-intuitive for many users, who see the world through those names.
:You get neat computer science properties from such a flexible VFS, but you
:also make it a lot harder to do some relatively straight-forward things.
:I think the direction you'd like to explore is really interesting, but I
:worry that it has a lot of security pitfalls, not just novel security
:applications. Just some thoughts to stick in with the rest...
:Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
:robert at xxxxxxxxxxxxxxxxx Network Associates Laboratories
Well, it's a different way of thinking about the problem space...
Depending on every single file (of which there could be millions)
in a system having the correct user, group, modes, and attributes,
is probably at least as dangerous as a rules-based VFS environment
and I would argue even *more* dangerous. I'm not arguing that we
should do away with the traditional model, but the traditional model
has always been to provide an overly permissive environment for programs
run under it.
I feel that the *only* way one can truely secure a subsystem, such as
a web server, is by running it in a restricted environment. A
VFS wrapper just happens to be the easiest way to develop the model.
What we will probably wind up with will be a 'workhorse' VFS environment
that generates a wrapper based on a set of simple rules based in a
Consider the difference between running something like named as we run
it now, even in a chroot'd environment, verses running something like
named in a restricted environment which has the rules:
* R/W allowed in /etc/namedb/s, /etc/namedb/run, and
* /dev access only to /dev/null and /dev/zero
* read-access to standard /etc config files for libc support,
which does NOT include access to the password file.
* no ability to run suid/sgid programs or to connect to any
socket resource other then port X, Y, and Z.
* no other access (no ability to exec suid/sgid programs, no
ability to access other socket resources, no ability to access
random devices in /dev, no ability to run esoteric system calls
that named has no business running, whether they are supposed to
be secure or not. No ability to access the password file or
The same can be said for Apache, sendmail, and just about any other
service one might run, as well as programs like sudo which are
In addition, these sorts of VFS environments can be stacked. So for
example when you login a user you can emplace his login in an environment
that virtually guarentees nothing he does can corrupt the system without
having to resort to a chroot or a jail or removing world permissions from
suid programs, etc.
It is not possible to do that now. Right now we have a situation where
even the most unprivileaged program can potentially break into root
simply by finding a hole in an suid-root program, even if that program
would never normally have run such a program, or break into root by
finding a hole in a system call or /dev device that it would otherwise
There are too many 'holes' in the current security model. chroot has
holes, jails have holes, everything has holes. A VFS environment goes a
long ways towards fixing this rather serious problem.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel