disablenetwork() syscall?

disablenetwork() syscall?

[Pekka Savola]

Hi,

In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
has been brought up in the past.  I'm not sure whether it's feasible or 
not, but at least it (and other methods to limit the functions of a 
user-level code) might bear consideration.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---------- Forwarded message ----------
Date: 4 Jul 2003 23:17:20 -0000
From: D. J. Bernstein <djb@cr.yp.to>
To: bugtraq@securityfocus.com
Subject: Re: Email marketing company gives out questionable security advice

[...]
P.S. It's hard for a portable chroot tool to cut off a program's network
access. Kernel designers should provide a disablenetwork() syscall, with
the disabling inherited by children. Other kernel changes would be nice,
but disablenetwork() is the only critical change.

Re: disablenetwork() syscall?

[Jeff Garzik]

On Mon, Jul 07, 2003 at 10:40:02PM +0300, Pekka Savola wrote:
> In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
> has been brought up in the past.  I'm not sure whether it's feasible or 
> not, but at least it (and other methods to limit the functions of a 
> user-level code) might bear consideration.

What about some URLs to what you are describing?

The most information you provided was in $subject, whose content
makes me a bit leery...

	Jeff

Re: disablenetwork() syscall?

[Pekka Savola]

On Mon, 7 Jul 2003, Jeff Garzik wrote:
> On Mon, Jul 07, 2003 at 10:40:02PM +0300, Pekka Savola wrote:
> > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
> > has been brought up in the past.  I'm not sure whether it's feasible or 
> > not, but at least it (and other methods to limit the functions of a 
> > user-level code) might bear consideration.
> 
> What about some URLs to what you are describing?
> 
> The most information you provided was in $subject, whose content
> makes me a bit leery...

Well, apart from the post scriptum, there was very little content about 
the feature/idea :-), and the details would seem to be up for everyone's 
imagination. 

FWIW, the body of the message is below:

=====
Richard M. Smith writes:
  [ mail readers disabling inline images ]
> It will be interesting to see how email marketing companies and
> spammers adapt to these technical changes in HTML email.
                                                                                                  
ASCII porn, perhaps? Especially if the sender can control the color, and
size, of text. I suppose those will be the next casualties in the war on
spam.
                                                                                                  
It's quite depressing that this is what people think of as ``security'':
patch maniacally; install a scanner that checks for yesterday's attacks;
don't view the pictures, don't drink the water, don't breathe the air.
                                                                                                  
I've been playing with a radically different system design (I'm thinking
of calling it ``UNIX'') where conceptually separate tasks are split into
separate processes. If you want to gunzip a stream of data, for example,
you run a gunzip program in its own chroot jail, under its own uid, with
no way to read any interesting data except through a predefined IPC hook
(I'm thinking of calling that a ``pipe'' on ``standard input'') and with
no way to touch anything except through another predefined IPC hook. The
only thing that an attacker can do by taking over this gunzip program is
generate arbitrary output data, which he could have done anyway. Typical
picture-generating programs can be isolated in the same way.
====

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: disablenetwork() syscall?

[Mitchell Blank Jr]

Pekka Savola wrote:
> In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
> has been brought up in the past.  I'm not sure whether it's feasible or 
> not, but at least it (and other methods to limit the functions of a 
> user-level code) might bear consideration.

It sounds like something that could be a implemented as a capability
(CAP_NET_ACCESS or such)

-Mitch

Re: disablenetwork() syscall?

[Arnaldo Carvalho de Melo]

Em Mon, Jul 07, 2003 at 10:52:15PM +0300, Pekka Savola escreveu:
> On Mon, 7 Jul 2003, Jeff Garzik wrote:
> > On Mon, Jul 07, 2003 at 10:40:02PM +0300, Pekka Savola wrote:
> > > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
> > > has been brought up in the past.  I'm not sure whether it's feasible or 
> > > not, but at least it (and other methods to limit the functions of a 
> > > user-level code) might bear consideration.
> > 
> > What about some URLs to what you are describing?
> > 
> > The most information you provided was in $subject, whose content
> > makes me a bit leery...
> 
> Well, apart from the post scriptum, there was very little content about 
> the feature/idea :-), and the details would seem to be up for everyone's 
> imagination. 
> 
> FWIW, the body of the message is below:

Incomplete, here is the part that he mention the disablenetwork syscall:

------------------------------------- 8< ------------------------------

P.S. It's hard for a portable chroot tool to cut off a program's network
access. Kernel designers should provide a disablenetwork() syscall, with
the disabling inherited by children. Other kernel changes would be nice,
but disablenetwork() is the only critical change.

------------------------------------- 8< ------------------------------

Re: disablenetwork() syscall?

[James Morris]

On Mon, 7 Jul 2003, Pekka Savola wrote:

> Hi,
> 
> In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
> has been brought up in the past.

Such a feature already exists in SELinux.

>  I'm not sure whether it's feasible or 
> not, but at least it (and other methods to limit the functions of a 
> user-level code) might bear consideration.

This is precisely what LSM is for, so new security models can be 
implemented without any direct effect on the core kernel.


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: disablenetwork() syscall?

[Pekka Savola]

FWIW,

DJB created a (probably biased) web page:

 http://cr.yp.to/unix/disablenetwork.html

to describe the idea and alternatives at a bit more length.

On Tue, 8 Jul 2003, James Morris wrote:

> On Mon, 7 Jul 2003, Pekka Savola wrote:
> 
> > Hi,
> > 
> > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure 
> > has been brought up in the past.
> 
> Such a feature already exists in SELinux.
> 
> >  I'm not sure whether it's feasible or 
> > not, but at least it (and other methods to limit the functions of a 
> > user-level code) might bear consideration.
> 
> This is precisely what LSM is for, so new security models can be 
> implemented without any direct effect on the core kernel.
> 
> 
> - James
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings