From owner-freebsd-security Tue Aug 18 06:01:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16237 for freebsd-security-outgoing; Tue, 18 Aug 1998 06:01:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16223 for ; Tue, 18 Aug 1998 06:00:57 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id JAA08326; Tue, 18 Aug 1998 09:00:12 -0400 (EDT) Date: Tue, 18 Aug 1998 09:00:12 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Philippe Regnauld cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: "Using capabilties aaginst shell code" In-Reply-To: <19980814123240.63855@deepo.prosa.dk> 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 Some work was going on at TIS Advanced Research and Engineering (now TISLabs at NAI) concerning a "Wrappers" project that involved replacing syscalls using an lkm to modify the security policy of a host. There was a paper at USENIX a while ago I believe; I'll try to send out URL references later today, but am not currently in the office. If I understand correctly, they had some problems with the mmap file IO mechanism as it is one of the read/write mechanisms that does not involve the syscall interface (once initiated). I have been thinking about implementing posix capabilities in BSD, but don't have a copy of the spec. Anyone have any pointers to where I could find it? From what I have heard, Posix capabilities are not the answer to the unix security problem (that is, the desired for fine-grained access controls), as it only addresses a few specific (but common) cases. Robert Watson On Fri, 14 Aug 1998, Philippe Regnauld wrote: > (see message below) > > Is this any form of restriction that can be implemented > in *BSD systems ? I.e.: restricting system calls to > certain classes of daemons ? > > As mentioned in the example below, why should POPd be allowed > to exec() ? This seems like a very sane approach (of course, > it implies knowledge/auditing of the code). > > Then we could have certain untrusted (i.e.: running as > root) daemons launched in such an environment, on top > of being chroot()ed. > > -----Forwarded message from Duncan Simpson ----- > > From: Duncan Simpson > Subject: Using capabilties aaginst shell code > To: BUGTRAQ@NETSPACE.ORG > Date: Wed, 12 Aug 1998 21:33:51 +0200 > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > The development of capabilities with Linux (and some section of POSIX, if the > header is to be believed) creates an opportunity for tightening security by > sandboxing daemons---imapd and popd have no legitimate use for various system > calls, for example. In particular exec is fundamental to most buffer overrun > shellcode and not required by many daemons. > > [...] > > -----End of forwarded message----- > > -- > -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- > > The Internet is busy. Please try again later. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message