A TrustedBSD "voluntary sandbox" policy.

[dexterclarke at Safe-mail.net]

I'm considering developing a policy/module for TrustedBSD loosely based
on the systrace concept - A process loads a policy and then executes
another program in a sandbox with fine grained control over what that
program can do.

I'm aiming for a much simpler implementation, however. No interaction.
No privilege elevation (only restriction). No system call rewriting,
only access control.

The interface will look something like this:

(cat <<EOF
deny all 
allow file_open /etc/passwd
allow file_open /dev/tty
allow sock_connect 127.0.0.1 80
allow sock_connect 208.77.188.166 80
rlimit core 0
rlimit cpu 20
rlimit nofile 10
EOF
) | sandbox /bin/ls -alF /bin

Please note that the 'policy' given on the command line is purely for 
the sake of example, no syntax or semantics have been decided upon.

The implementation appears to be simple, as far as I'm aware. I'm sure
there will be thorns and problems - that's what I'm here to find out.

The 'sandbox' process compiles the policy text into a binary structure
in userland, loads the binary structure into the kernel module via a
system call implemented with mac_syscall(), sets various rlimits and 
then runs /bin/ls with execve().  When the process exits, the memory for 
the binary structure is freed.

I would like, at this stage, to know if the above model is seriously
incompatible with the way the MAC framework works, it's not entirely
clear either way having read other policies such as mac_biba, mac_stub
etc.

For example - how to know when a process has exited? Policy for an
executed process would be kept in a small hash table, indexed by process
id. The policy will be enabled when the process sucessfully calls
execve() for the first time and will be destroyed when the process
exits.  If we're not notified when a process has exited, we can't remove
policy from the table.

Also, what should be done when a process decides to fork() or execve()?
It'd be rather unfortunate if the process could break out of the sandbox
just by executing another process but blocking all attempts to fork()
or execve() would make classes of programs unusable.

Comments, flames, etc, appreciated.

(cc'd to trustedbsd-discuss@ regardless of whether or not anybody actually
reads it).

--
dc