Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 May 1999 15:35:42 -0700 (PDT)
From:      Cliff Skolnick <cliff@steam.com>
To:        Thamer Al-Herbish <shadows@whitefang.com>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Wrapping syscalls
Message-ID:  <Pine.BSF.4.10.9905111527120.510-100000@lazlo.internal.steam.com>
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


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




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