netdev - Re: [PATCH] Security: Implement and document RLIMIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Jan 2009 16:07:58 -0500
From:	Michael Stone <michael@...top.org>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Security: Implement and document RLIMIT_NETWORK.

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html