A TrustedBSD "voluntary sandbox" policy.

[Pawel Jakub Dawidek]

On Wed, Nov 07, 2007 at 10:20:28PM -0500, dexterclarke at Safe-mail.net wrote:
> 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.

First problem is that it is hard to operate on file paths. MAC passes a
locked vnode to you and you cannot go from there to a file name easly.
You could do it by comparsion: call VOP_GETATTR(9) on the given vnode,
do the same for /etc/passwd and others and compare their inodes and
file system ids. Performance hit may be significant for complex
policies.

You can register yourself for process_exit, process_fork and
process_exec in-kernel events and do your cleanups from your event
handler. Take a look at EVENTHANDLER(9).

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20071108/8333bb73/attachment.pgp