Re: Buffer overflow?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:...
: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@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
    configuration file.

    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 
	  /var/run/named.pid

	* /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
	  database).

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

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

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>