Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 May 1999 07:23:00 +1000 (EST)
From:      Darren Reed <avalon@coombs.anu.edu.au>
To:        shadows@whitefang.com (Thamer Al-Herbish)
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Wrapping syscalls
Message-ID:  <199905112123.HAA00753@cheops.anu.edu.au>
In-Reply-To: <Pine.BSF.4.05.9905111251500.253-100000@rage.whitefang.com> from "Thamer Al-Herbish" at May 11, 99 12:55:40 pm

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905112123.HAA00753>