Subject: Network isolation with RLIMIT_NETWORK, cont'd.
Date: Sunday 13th December 2009 03:19:37 UTC (over 7 years ago)
Dear lkml, A few months ago , 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 . 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  http://kerneltrap.org/mailarchive/linux-netdev/2009/1/7/4624864  http://sandboxing.org