Date: Thu, 8 Nov 2007 18:23:45 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: dexterclarke@Safe-mail.net Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: A TrustedBSD "voluntary sandbox" policy. Message-ID: <20071108172345.GE25224@garage.freebsd.pl> In-Reply-To: <N1-_PYrd0nIeB@Safe-mail.net> References: <N1-_PYrd0nIeB@Safe-mail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--IbVRjBtIbJdbeK1C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 07, 2007 at 10:20:28PM -0500, dexterclarke@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. >=20 > I'm aiming for a much simpler implementation, however. No interaction. > No privilege elevation (only restriction). No system call rewriting, > only access control. >=20 > The interface will look something like this: >=20 > (cat <<EOF > deny all=20 > 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 >=20 > Please note that the 'policy' given on the command line is purely for=20 > the sake of example, no syntax or semantics have been decided upon. >=20 > 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. >=20 > 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=20 > then runs /bin/ls with execve(). When the process exits, the memory for= =20 > the binary structure is freed. >=20 > 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. >=20 > 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. >=20 > 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). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --IbVRjBtIbJdbeK1C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHM0YhForvXbEpPzQRAu4KAKDXT+SpktNP9Im8NAWyqGKJXFASDACg84Cd E5KCkqy47CxgYdzFflYNwNI= =YGor -----END PGP SIGNATURE----- --IbVRjBtIbJdbeK1C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071108172345.GE25224>