Buffer overflow?

[Robert Watson]

On Fri, 1 Aug 2003, Matthew Dillon wrote:

>     Well, I am neutral on the topic.  I generally consider these
>     sorts of security fixes as masking the problem rather then
>     fixing it.  What I would like to see (and another reason for
>     doing the VFS layer and syscall emulation) is a way to limit
>     a program's ability to manipulate its environment to just
>     the files that we say it can access/modify.  Also, the ability
>     to wrap a program with another program which takes control of
>     its syscalls (another reason for doing syscall messaging).
> 
>     As an extreme example take a program like 'ls'.  There is
>     no reason under the sun for the system to allow a program
>     like 'ls' to exec(), yet nearly all UNIX systems do allow
>     this.  You get the drift of where I'm going...
> 
>     The key is to make this all doable in userland.  Restricting
>     these sorts of features to the kernel greatly reduces the
>     number of people who can potentially develop code up 
>     related projects.

I guess my concern with this approach is that it actually makes it very
hard to reason about the resulting system.  In the current UNIX approach,
taken by most (but not all) UNIX operating systems, the various system
namespaces are relatively consistent across all processes, as are the
services reachable using those namespaces.  Security properties of
processes are centrally maintained in the kernel, and decisions are
administered in a relatively central manner.  This means, when doing an
analysis of the system to argue about its correctness, you have to look in
fewer places, and you can make a more simple argument.

In systems that have mutable namespaces, you spend a lot more time
reasoning about how the namespace affects the service received by an
entity.  For example, in traditional BSD, processes (on the whole) see one
file system namespace, and protections of objects are explicit.  It's
fairly easy to measure the protections to determine how the system
currently operates.  The addition of chroot() caused a number of new
classes of security vulnerabilities to open up: applications that
previously trusted that the namespace contained constant, trustworthy
components ("/etc/master.passwd") could no longer make that working
assumption.  As a result, use of chroot() was limited to privileged users,
who it is assumed will make sure that if there are multiple filesystem
namespaces, they are each configured correctly.  Similar vulnerabilities
have been found in Mach-derived systems, where privilege is held by
processes with namespaces controlled by other unprivileged processes. 
When I want to ask the question "What assumptions does this application
make in order to operate correctly", the answer is much more complicated
than before.

My concern with placing VFS wrapping and substitution in the control of
user processes is that it's increased the complexity of answering
questions about what the actual effects of an application will be, and
whether application programs can easily reason about the behavior of their
software.  From playing some with System V IPC namespaces on FreeBSD, I
can say that it sucked quite a bit to say "Ah, but I can't delete that
object from this process, because it's in a different namespace from this
other process".  Too much flexibility can mean less structure.

This isn't to say there aren't some successful examples of systems that
permit this sort of substitution and namespacing -- you can get some nice
functionality benefits from it, and virtualization can sometimes be
offered as a security feature (chroot is often used for security
purposes).  Neils Provos's systrace permits some very interesting
security-related experimentation, although the issue of namespacing has
come up as a problem in that environment as well.

Occasionally, I find myself wishing that the BSD VFS wasn't quite so
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