From owner-freebsd-hackers@FreeBSD.ORG  Thu Nov  8 03:20:54 2007
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4CC3916A420
	for <freebsd-hackers@freebsd.org>; Thu,  8 Nov 2007 03:20:54 +0000 (UTC)
	(envelope-from dexterclarke@Safe-mail.net)
Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230])
	by mx1.freebsd.org (Postfix) with ESMTP id B44E513C4B2
	for <freebsd-hackers@freebsd.org>; Thu,  8 Nov 2007 03:20:53 +0000 (UTC)
	(envelope-from dexterclarke@Safe-mail.net)
Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52)
	id 1IpxwT-0002ma-3p; Wed, 07 Nov 2007 22:20:29 -0500
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net;
	b=zSMTtO8ZtvERLJbsjmq2q0nxjvx2IdaSO2HrzojvzAw/HP+87yur4EY7xWGH5adB
	65QXRqZjvbRdEX6kLxqNa+i6ZqqXnHx8U0vPEdCprqvCURO9pPCagr7rR2Do7HDj
	HBATBuuYw5vOmfW1p281xfB/3KKZFmPbQaYDPseZfBg=;
Received: from pc ([81.86.41.187]) by Safe-mail.net with https
Date: Wed, 7 Nov 2007 22:20:28 -0500
From: dexterclarke@Safe-mail.net
To: freebsd-hackers@freebsd.org
X-SMType: Regular
X-SMRef: N1-_PYrd0nIeB
Message-Id: <N1-_PYrd0nIeB@Safe-mail.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMSignature: oEqF6kpRn7ckCrL5q+G+kitXdHsTQ/V54fnE13kkIywzCZHAqqbYDjlo9t7aGaoP
	6pMEmir1TLI4B61d2HznEb+TIHXFP+hUcCoeIulDgQhPiKKyh5OzPYdCj02cmJOG
	FANvKHlA+mp3fjkZB8ZQO7K4n541Oc4iNRsiVSxHldo=
Cc: trustedbsd-discuss@freebsd.org
Subject: A TrustedBSD "voluntary sandbox" policy.
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2007 03:20:54 -0000

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