From: Evgeniy Polyakov <zbr@ioremap.net>
To: Michael Stone <michael@laptop.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] Security: Implement and document RLIMIT_NETWORK.
Date: Thu, 8 Jan 2009 00:59:36 +0300 [thread overview]
Message-ID: <20090107215935.GB4610@ioremap.net> (raw)
In-Reply-To: <20090107210758.GH3164@didacte.laptop.org>
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
next prev parent reply other threads:[~2009-01-07 22:00 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 5:48 RFC: Network privilege separation Michael Stone
2009-01-07 5:48 ` [PATCH] Security: Implement and document RLIMIT_NETWORK Michael Stone
2009-01-07 11:47 ` Evgeniy Polyakov
2009-01-07 16:52 ` Rémi Denis-Courmont
2009-01-07 17:48 ` Evgeniy Polyakov
2009-01-07 20:54 ` Rémi Denis-Courmont
2009-01-07 20:54 ` Rémi Denis-Courmont
2009-01-07 21:42 ` Evgeniy Polyakov
2009-01-07 18:35 ` C. Scott Ananian
2009-01-07 19:02 ` Evgeniy Polyakov
2009-01-07 19:39 ` Evgeniy Polyakov
2009-01-07 21:07 ` Michael Stone
2009-01-07 21:59 ` Evgeniy Polyakov [this message]
2009-01-08 0:56 ` Michael Stone
2009-01-08 4:27 ` Evgeniy Polyakov
2009-01-08 1:22 ` James Morris
2009-01-08 3:34 ` Michael Stone
2009-01-07 21:10 ` RFC: Network privilege separation Andi Kleen
2009-01-08 2:31 ` Michael Stone
2009-01-08 3:10 ` Andi Kleen
2009-01-08 4:51 ` Michael Stone
2009-01-08 5:41 ` Andi Kleen
2009-01-08 7:05 ` Oliver Hartkopp
2009-01-08 7:52 ` david
2009-01-08 10:43 ` Alan Cox
2009-01-12 18:44 ` Valdis.Kletnieks
2009-01-12 19:09 ` Bryan Donlan
2009-01-12 19:43 ` Andi Kleen
2009-01-12 19:47 ` Rémi Denis-Courmont
2009-01-12 20:14 ` Andi Kleen
2009-01-12 20:15 ` Rémi Denis-Courmont
2009-01-12 20:27 ` Evgeniy Polyakov
2009-01-12 20:39 ` Andi Kleen
2009-01-12 20:30 ` Rémi Denis-Courmont
2009-01-12 20:55 ` Andi Kleen
2009-01-12 20:47 ` Rémi Denis-Courmont
2009-01-12 21:50 ` Andi Kleen
2009-01-13 8:06 ` Rémi Denis-Courmont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090107215935.GB4610@ioremap.net \
--to=zbr@ioremap.net \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@laptop.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.