linux-kernel - Network isolation with 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-next>] [day] [month] [year] [list]

Date:	Sat, 12 Dec 2009 22:19:37 -0500
From:	Michael Stone <michael@...top.org>
To:	linux-kernel@...r.kernel.org
Cc:	Michael Stone <michael@...top.org>
Subject: Network isolation with RLIMIT_NETWORK, cont'd.

Dear lkml,

A few months ago [1], I asked for feedback on a new network isolation primitive
named "RLIMIT_NETWORK" designed for use with Unix sandboxing utilities like
Rainbow, Plash, and friends [2]. Thank you to all those CC'ed for your helpful
early remarks.

Here is an updated patchset with responses to the following criticisms:

  1. ptrace() 
     
     It was pointed out by Alan Cox, Andi Kleen, and others that processes
     which dropped their RLIMIT_NETWORK rlimit were still able to directly
     perform networking through a ptrace()'d victim.

     The new patchset adds an access check to __ptrace_may_access() to prevent
     this behavior.

  2. unshare(CLONE_NEWNET)

     It was pointed out by James Morris that network namespaces could be used
     to implement behavior similar to the behavior this patchset is designed to
     implement. To address this criticism, I added support for network
     namespaces to my sandboxing utility (Rainbow).

     Unfortunately, I have discovered that network namespaces in their current
     form are not appropriate for my use cases because they prevent the
     namespace'd apps from connecting to the X server, even over plain old
     AF_UNIX sockets.

     The RLIMIT_NETWORK facility I propose contains a specific exception for
     AF_UNIX filesystem sockets since those sockets are already bound by
     regular Unix discretionary access control.

  3. style

     I have made the patches more consistent with the kernel style
     guidelines.

Further suggestions?

Michael

[1] http://kerneltrap.org/mailarchive/linux-netdev/2009/1/7/4624864
[2] http://sandboxing.org
--
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/