Message-ID: <20030820173101.GQ55671@episec.com>
Date: Wed, 20 Aug 2003 13:31:02 -0400
From: ari <edelkind-bugtraq@...sec.com>
To: bugtraq@...urityfocus.com
Cc: secprog@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.


anil@...oil.org said this stuff:

> On Fri, Aug 15, 2003 at 11:01:54PM +0100, Alaric B Snell wrote:
> > But still - it sounds promising; it reminds me of an idea I was 
> > considering (but Theo de Raadt hated!) of allowing processes to drop 
> > certain syscalls (or certain modes of operation of syscalls - many are 
> > multi-function), shedding priveleges in the same manner as setuid-ing 
> > down to nobody or chrooting. So Apache could, after binding to its 
> > ports, drop the ability to bind to ports. After opening its log files, 
> > it could drop the ability to open files for writing. Each child process 
> > would abandon fork rights, and exec rights as soon as it sees it's not a 
> > CGI.
> 
> It just adds another layer of complexity to an already over-complex
> kernel/userland interface.  If you're going to change the source like this,
> I prefer privilege separation instead, which works without kernel changes.

Privilege separation is (1) not always an option, and (2) not a complete
solution.  For example, one may still open network sockets in a
chroot(2) environment, while running as a non-root user.  One may still
"fork bomb".  Dropping system calls is no more difficult than effecting
resource limits from the programmer's standpoint.  If the programmer
would rather not use resource limits, he need not be bothered.  If the
programmer would rather not drop system calls, he also need not be
bothered.

The ideas that alaric snell and evan teran have are similar to something
i'm currently implementing for freebsd; whether or not it will be
accepted into the core distribution is another story.  If it goes over
well with the community at large, i'll port it to linux and other
open-source BSD operating systems as well.  In truth, i have found it
neither difficult nor complex to implement.  Tedious, perhaps, but
neither difficult nor complex.

Banning kernel calls, however, is the wrong way to go about this.  To
effectively turn off filesystem accesses for a process, the programmer
would need to disable many system calls.  When the kernel is updated,
the number of system calls may change.  The programmer would then need
to change his code, and old versions of the software would become not
just old, but obsolete, even if no new bugs were fixed or features
added.  Programs would also become nonportable between operating
systems, and the programmer would even need to accommodate for
third-party patches, which may add additional system calls.  The proper
way to handle the concept is by action class; if i want to disable all
filesystem reads, i should be able to call a function that will
effectively disable all filesystem reads.  If i want to disable the
creation of files on the filesystem, i shouldn't need to specifically
disable open, bind, mkfifo, link, symlink, mkdir, and possibly others,
depending on what other kernel calls may be available.

I created a page about the idea, which can be found at:

    http://www.episec.com/people/edelkind/patches/kernel/flowpriv/

The page is a bit out of date now (i created it about a week ago), and
it doesn't discuss some of the technical design decisions i have made,
nor does it offer the proof-of-concept code i have written for it.  But
it will be modified to reflect all of this as soon as i find the time.

There is a mailing list referenced on the page as well; anyone
interested in the project is welcome to join.

Mind you, i do not believe that this idea should be considered a
replacement for system call profiling tools (such as systrace), just as
i don't believe that the existence of tools such as systrace obsoletes
this idea.  I believe that the two should work together:  one that
allows an administrator to create policies, and another that allows the
programmer to design additional security into programs, without
introducing more than a negligible performance impact.

I find it unfortunate that you say theo de raadt was not fond of the
idea.  Perhaps if he would like to subscribe to the mailing list and
voice his concerns, they may all be addressed.

ari (edelkind)

Powered by blists - more mailing lists