From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 8 17:44:32 2007 Return-Path: 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 D9A9E16A46C; Thu, 8 Nov 2007 17:44:32 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7B213C4B3; Thu, 8 Nov 2007 17:44:31 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E381E45CD9; Thu, 8 Nov 2007 18:23:58 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id B018545684; Thu, 8 Nov 2007 18:23:54 +0100 (CET) Date: Thu, 8 Nov 2007 18:23:45 +0100 From: Pawel Jakub Dawidek To: dexterclarke@Safe-mail.net Message-ID: <20071108172345.GE25224@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IbVRjBtIbJdbeK1C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2007 17:44:33 -0000 --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 < 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--