From owner-freebsd-security Tue May 11 15:35:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from lazlo.internal.steam.com (lazlo.steam.com [199.108.84.37]) by hub.freebsd.org (Postfix) with ESMTP id 94FAA15026 for ; Tue, 11 May 1999 15:35:51 -0700 (PDT) (envelope-from cliff@steam.com) Received: from lazlo.internal.steam.com (cliff@lazlo.internal.steam.com [192.168.32.2]) by lazlo.internal.steam.com (8.9.3/8.9.3) with ESMTP id PAA02581; Tue, 11 May 1999 15:35:42 -0700 (PDT) Date: Tue, 11 May 1999 15:35:42 -0700 (PDT) From: Cliff Skolnick X-Sender: cliff@lazlo.internal.steam.com To: Thamer Al-Herbish Cc: freebsd-security@FreeBSD.ORG Subject: Re: Wrapping syscalls In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Two problems that I see of the top of my head. 1) Logging, if you disable loging you will be sad. Loging usually requires a "write" system call. I supposed you could log over a socket with send() and friends, but this may require many application changes. 2) mmap(), and perhaps more like it, define the read/write behavior as a parameter to the system call. A simply allow/disallow will not be a high enough granularity in many cases. Would it be possible to have a generic parameter mask associated with the system call? It would solve both the above issues by having a system open the log file for write, then mask off the write flag in any following open() syscalls. You could also just mask off the write ability in mmap(). A system call filter, looks like a user/kernel firewall. :) Cliff On Tue, 11 May 1999, Thamer Al-Herbish wrote: > 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. > > 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. > > Additionally, the child process will inheret its parent's > disposition and never be able to reclaim a system call. > > -- > Thamer Al-Herbish PGP public key: > shadows@whitefang.com http://www.whitefang.com/pgpkey.txt > [ The Secure UNIX Programming FAQ http://www.whitefang.com/sup/ ] > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Cliff Skolnick | "They that can give up essential liberty to obtain Steam Tunnel Operations | a little temporary safety deserve neither liberty cliff@steam.com | nor safety." http://www.steam.com/ | -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message