linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20090107114703.GB28161@ioremap.net>
Date:	Wed, 7 Jan 2009 14:47:03 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Michael Stone <michael@...top.org>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Security: Implement and document RLIMIT_NETWORK.

Hi Michael.

On Wed, Jan 07, 2009 at 12:48:54AM -0500, Michael Stone (michael@...top.org) wrote:
> Daniel Bernstein has observed [1] that security-conscious userland processes
> may benefit from the ability to irrevocably remove their ability to create,
> bind, connect to, or send messages except in the case of previously connected
> sockets or AF_UNIX filesystem sockets. We provide this facility by implementing
> support for a new rlimit called RLIMIT_NETWORK.
> 
> This facility is particularly attractive to security platforms like OLPC
> Bitfrost [2] and to isolation programs like Rainbow [3] and Plash [4].
> 
> [1]: http://cr.yp.to/unix/disablenetwork.html
> [2]: http://wiki.laptop.org/go/OLPC_Bitfrost
> [3]: http://wiki.laptop.org/go/Rainbow
> [4]: http://plash.beasts.org/
> ---
>  Documentation/rlimit_network.txt |   48 ++++++++++++++++++++++++++++++++
>  fs/proc/base.c                   |    1 +
>  include/asm-generic/resource.h   |    4 ++-
>  net/socket.c                     |   57 +++++++++++++++++++++++++++++--------
>  net/unix/af_unix.c               |   28 ++++++++++++++++++
>  5 files changed, 124 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/rlimit_network.txt
> 
> diff --git a/Documentation/rlimit_network.txt b/Documentation/rlimit_network.txt
> new file mode 100644
> index 0000000..e7cc3e4
> --- /dev/null
> +++ b/Documentation/rlimit_network.txt
> @@ -0,0 +1,48 @@
> +Purpose
> +-------
> +
> +Daniel Bernstein has observed [1] that security-conscious userland processes
> +may benefit from the ability to irrevocably remove their ability to create,
> +bind, connect to, or send messages except in the case of previously connected
> +sockets or AF_UNIX filesystem sockets.
> +
> +This facility is particularly attractive to security platforms like OLPC
> +Bitfrost [2] and to isolation programs like Rainbow [3] and Plash [4] because:
> +
> +  * it integrates well with standard techniques for writing privilege-separated
> +    Unix programs
> +
> +  * it's available to unprivileged programs
> +

It isn't, since it can not set rlimit, and if it can, it still can drop
it.

Your code does not cover sendpage() interface (aka splice() and
sendfile()) 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?

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

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/