Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 May 1999 17:21:10 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Thamer Al-Herbish <shadows@whitefang.com>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Wrapping syscalls
Message-ID:  <Pine.BSF.3.96.990511171824.8606C-100000@fledge.watson.org>
In-Reply-To: <Pine.BSF.4.05.9905111251500.253-100000@rage.whitefang.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Search for wrappers in the mailin list archive -- TIS released a fairly
comprehensive package that does pretty much what you describe.

My own tokens kernel module does something fairly similar, hooking
additional security semantics onto a process, and providing additional
capabilities based on the tokens acquired and exchanged.  That code is
fairly experimental, however, and I'm not sure I ever put the latest code
online.

I'm currently making use of the exchangable syscall array mechanism to
create speculative copies of processes to generate disk prefetches, in a
differnet project.

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
> 


  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services             http://www.safeport.com/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990511171824.8606C-100000>