Messages in this thread | | | Date | Thu, 8 Jan 2009 00:59:36 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [PATCH] Security: Implement and document RLIMIT_NETWORK. |
| |
On Wed, Jan 07, 2009 at 04:07:58PM -0500, Michael Stone (michael@laptop.org) wrote: > First, thanks very much for all your comments and questions.
you are welcome :)
> >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.
Argh, I see. That clarifies most questions indeed.
> >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?
Your patch adds a rlimit check into __sock_sendmsg() call, which is invoked via usual send() path, but sendfile() and splice() are still exectuted without this check and thus will be able to send data after rlimit applied.
> >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.)
I meant that connected or accepted socket will not be able to send data via send() call, but will be able to receive data using recv().
-- Evgeniy Polyakov
| |