Enterprise secure dapper? sudo concerns/proposal

[john]

On Mon, Apr 10, 2006 at 01:18:48AM +0100, Tristan Wibberley wrote:
> > PROPOSALS:
> > These are some creative thoughts, some might be more wise than others. I
> > know plans like plash[2] (to reduce the amount of code ran as root) are

Actually, Plash is just as important to reduce the amount of code that
runs as user. Once an admin account has be trojaned it is had to stop
privilege escalation.

It is well known that you should drop root system-wide privs where ever
possible. However in this day and age you should really drop user (~/) wide
privs as often as possible.

E.g. does mozilla really need write access to ~/.bashrc?

I would suggest that /usr/bin/mozilla be a wrapper like:
   plash --read /usr --rw ~/.mozilla mozilla-bin

> plash is good as a prototype, but, having read about it briefly, its
> functionality should be moved into the kernel to catch all programs, not
> just well behaved, dynamically linked ones.

``Sandboxed processes do not use the kernel's filename-based system calls,
such as "open". Plash effectively disables these system calls by putting
the sandboxed process in a very minimal chroot() jail. (It also gives
the sandboxed process a unique, dynamically-allocated UID and GID.)''
-- http://plash.beasts.org/

Misbehaved apps that directly access the kernel do not bypass the security
rules, they simply do not work. These should be rare enough that it is
feasible to rewrite them to be well behaved.

If this too much trouble, we could use the SysTrace architecture which
runs the application in debug mode and traps syscalls, only allowing
syscalls that match policy. Systrace can dynamically generate policy by
popping up a window when the app attempts a syscall that the user hasn't
allowed, or has allowed but not with the parameters that the app is
presently trying to call it with, which is kind of cool.

-- 
John C. McCabe-Dansted
Masters Student