From owner-freebsd-security Tue May 11 14:24:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id F303614F6E for ; Tue, 11 May 1999 14:23:12 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id HAA00753; Wed, 12 May 1999 07:23:01 +1000 (EST) From: Darren Reed Message-Id: <199905112123.HAA00753@cheops.anu.edu.au> Subject: Re: Wrapping syscalls To: shadows@whitefang.com (Thamer Al-Herbish) Date: Wed, 12 May 1999 07:23:00 +1000 (EST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Thamer Al-Herbish" at May 11, 99 12:55:40 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Thamer Al-Herbish, sie said: > > I've recently had the idea of wrapping system calls with a > capability check per process. The end objective is to have a patch > for FreeBSD that adds a system call which can be used to drop the > capability of calling a certain system call. > > The simplest example would be a web server that after chroot()ing > would call lsyscall(EXECVE) and drop its ability to execve(). It may > also drop its write() ability and so on. Leaving only a few > read-only system calls that would effectively make it read-only. Logging would be interesting, as would write'ing data to be sent back to the client :-) Lets hope they're not interested in using CGI either :-) > Has anyone attempted something similar? Is there an inherent > effeciency problem with just adding checks to the beginning of every > system call? I'm aware of some security issues that are _not_ solved > by this: specificially dropping write() capabilities but still being > able to truncate files with the open() call. The Solaris implementation of ptrace or /proc allows for a monitor process to run and actully provide returns values in place of the kernel for system calls (this was described at a Usenix Security Symposium). > Additionally, the child process will inheret its parent's > disposition and never be able to reclaim a system call. This isn't a capability based solution in the traditional sense of that term, more of a means being able to deny yourself use of certain system calls. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message