Re: [PATCH] Security: Implement and document RLIMIT_NETWORK.

[Michael Stone <michael@laptop.org>]

Evgeniy,

First, thanks very much for all your comments and questions.

On Wed, Jan 07, 2009 at 02:47:03PM +0300, Evgeniy Polyakov wrote:

>> +  * it's available to unprivileged programs
>> +
>
>It isn't, since it can not set rlimit, and if it can, it still can drop
>it.

Some sample code will probably clarify the use of my patch: 

   http://dev.laptop.org/git?p=users/mstone/test-rlimit-network;a=blob;f=disable_network.c;hb=HEAD

This C code describes a 'disable_network' exec-chain script which, when run as
any user, irrevocably disables network access as described in my previous
emails. 

As you can see, processes start with full access to the 'network' resource and
may, at any time, irrevocably (modulo CAP_SYS_RESOURCE) limit their and their
future children's access to this resource by lowering both their soft and hard
limits to 0.

>Your code does not cover sendpage() interface (aka splice() and
>sendfile()) 

Nor should it. Applications should continue to be able to send data on any
sockets where were already connected and should be able to accept new
connections on sockets which were already bound.

I have done some primitive testing to ensure that the patch implements this
functionality by means of the test utilities provided here:

  http://dev.laptop.org/git?p=users/mstone/test-rlimit-network;a=tree

Can you confirm my results?

> and with your approach application will suddenly stops sending data even into
> old sockets, but will be able to receive it from anywhere. Is it intentional?

Why do you think this would happen? 

(My test results, e.g. via
    http://dev.laptop.org/git?p=users/mstone/test-rlimit-network;a=blob;f=positive_localhost_tcp;hb=HEAD
  show otherwise.)

>The same goal can be achieved with 'owner' iptables match module btw.

As Rémi explained, the iptables 'owner' match module solves a different
problem.

> but when parent sets the rlimit it is not updated in the childs.

This is by design. Limiting my shell's networking privileges in preparation for
running an untrusted command should not limit the privileges of programs that I
have previously started running from the same shell process.

Regards,

Michael

P.S. - Rémi, Scott: Thanks very much for your supportive comments.