Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Aug 1998 10:06:12 -0500 (EST)
From:      Alfred Perlstein <bright@www.hotjobs.com>
To:        freebsd-security@FreeBSD.ORG
Subject:   Re: Fwd: "Using capabilties aaginst shell code" <dps@IO.STARGATE.CO.UK>
Message-ID:  <Pine.BSF.3.96.980818100221.354P-100000@bright.fx.genx.net>
In-Reply-To: <Pine.BSF.3.96.980818085555.8259C-100000@fledge.watson.org>

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

besideds time constraints, why hasn't someone coded a "rootd", it would
use local domain sockets and allow root processes to connect and setup an
ACL, then setuid to nobody and send a "registration done" to the root
server.

all syscalls that needed to be done would have to be passed through the
ACL setup by the initial connection with "rootd", this could include:

1) a sort of FD passing to a chrooted dir as in:
	give me access to /var/run/mypid
	give me access to home directories
2) ability to bind ports

or is this just silly?

Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com
-- There are operating systems, and then there's BSD.
-- http://www.freebsd.org/

On Tue, 18 Aug 1998, Robert Watson wrote:

> 
> 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 <dps@IO.STARGATE.CO.UK>-----
> > 
> > From: Duncan Simpson <dps@IO.STARGATE.CO.UK>
> > 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
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe 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.980818100221.354P-100000>