ref: a1a120547768ee33ddaae4ee1965dfcf85149d8a
dir: /sys/doc/nssec.ms/
.HTML "Namespaces as Security Domains" .TL Namespaces as Security Domains .AU Jacob Moody .AB We aim to explore the use of Plan 9 namespaces as ways of building isolated processes. We present here code for increasing the ability and granularity for which a process may isolate itself from others on the system. .AE .SH Introduction .PP .FS First presented in a slightly different form at the 9th International Workshop on Plan 9. .FE .LP In a Plan 9 system the kernel exposes hardware and system interfaces through a myriad of filesystem trees. These trees, or sharp devices, replace the functionality of many would be system calls through use of standard file system operations. A standard Plan 9 environment is comprised of a composition of these individual devices together, the collection of such being the processes namespace. .LP With these principles it is quite easy for a process to build a slim namespace using only what it may need for operation. This could be done in service to reduce the "blast radius" of awry or malicious code to some effect. But to be fully effective a process must also be able to remove the ability to bootstrap these capabilities back. We will explore different ways of building isolated namespaces, their pitfalls, ways to address those issues, along with new solutions. .SH Outside World .LP There have been many solutions for sandboxing within the UNIX™ world. There are more classical approaches such as .CW zones , [Price04] and .CW jails , that all provide an abstraction of building some number of smaller full unix boxes out of a single physical host. However these interfaces are presented more as a systems management tool, the mechanisms for which an administrator creates and manages these resources is unergonomic to use on a per-process basis. Instead it seems more the fashion now to isolate specific pieces of the system, and expect it possible that each process on the system may choose to manage its environment. The most successful execution of this idea in the wild is the OpenBSD project's .CW unveil and .CW pledge [Beck18] system calls, allowing a processes to cut off specific parts of the filesystem or system call interfaces. Linux namespaces [Biederman06] implement this idea by allowing a process to fork off private versions of specific global resources. In both these cases the sandboxing of a process is through gradual steps, removing potentially dangerous tools one by one. .SH Existing Work .LP Let us first define the resources we are restricting access to. The aforementioned gradual solutions provide ways in which a process can remove itself from specific kernel interfaces. In plan9 the kernel exposes almost all of its functionality through individual filesystems. These devices are accessed globally by prefixing a path with a sharp('#'), and have conventional places they are bound within the namespace. .LP A processes namespace in plan9 is typically constructed using a namespace file. These files are a collection of namespace operations formatted as one would expect to see them in a shell script. They typically begin by binding in some number of sharp devices in to their expected location. .P1 bind #d /fd bind -c #e /env bind #p /proc bind -c #s /srv .P2 Then using the globals provided, in particular /srv, to bring in the rest of the root filesystem. A process can at any point choose to construct itself a new namespace, but it must do so when changing users. This is done in part to ensure that each filesystem that the program would like to use has their chance to authenticate and be notified. Because this information is only exchanged on attach, the new user must construct a namespace from scratch. .LP Many programs, like network services, wish to drop their current user and become the special user .CW none user on startup, and in doing so must rebuild their namespace. The conventional default namespace files used is /lib/namespace, but most programs allow the user to specify an alternative with a flag. It is here that we already can approximate a chroot style environment by changing the root filesystem used in a namespace file. .P1 bind #s /srv mount /srv/myboot /root bind -a /root / .P2 By having another filesystem exposed in /srv/myboot and modifying the provided namespace file, we've allowed this process to work within an entirely separate root filesystem. .SH RFNOMNT .LP The issue in using these namespaces as security barriers is that there is nothing preventing a process from bootstrapping a resource back. While our example code places a different root filesystem in the namespace, nothing is preventing that process or its children from potentially rebootstrapping the real root filesystem back. For this issue there is a special rfork flag .CW RFNOMNT the prevents a process from accessing any almost any sharp device of consequence. This is done by preventing a process from walking to a device by its location within '#'. This allows existing binds of resources to continue working within the namespace but restricts a process from binding in new resources from the kernel. .LP While effective we found this to be too large a hammer in practice. Doing as its name implies .CW RFNOMNT also prevents a process from performing any mounts or binds. This in practice creates a single point in time in which a process gives up all of its control, instead of the idealized gradual process. This makes it quite hard to make use of in practice, only a single program in a chain may be the one to invoke .CW RFNOMNT or must hope that no other program further in the chain may want to make use of its namespace. The interface itself feels very clunky, there is a nice gradual addition of these kernel devices to the namespace why must the removal be all at once? .SH Chdev .LP We propose a new write interface through /dev/drivers that functionally replaces .CW RFNOMNT . /dev/drivers now accepts writes in the form of .P1 chdev op devmask .P2 Devmask is a string of sharp device characters. Op specifies how devmask is interpreted. Op is one of .TS lw(1i) lw(4.5i). \f(CW&\fP T{ Permit access to just the devices specified in devmask. T} \f(CW&~\fP T{ Permit access to all but the devices specified in devmask. T} \f(CW~\fP T{ Remove access to all devices. Devmask is ignored. T} .TE .LP This allows a process to selectively remove access to sections of sharp devices with quite a bit of control. In order to mimic all of .CW RFNOMNT 's features, removing access to .CW devmnt , which is not normally accessible directly, disables the processes ability to perform mount and bind operations. .LP For the implementation, we extended the existing .CW RFNOMNT flag attached to the process namespace group into a bit vector. Each bit representing an index into .CW devtab . The following function illustrates how this vector is set. .P1 void devmask(Pgrp *pgrp, int invert, char *devs) { int i, t, w; char *p; Rune r; u64int mask[nelem(pgrp->notallowed)]; if(invert) memset(mask, 0xFF, sizeof mask); else memset(mask, 0, sizeof mask); w = sizeof mask[0] * 8; for(p = devs; *p != 0;){ p += chartorune(&r, p); t = devno(r, 1); if(t == -1) continue; if(invert) mask[t/w] &= ~(1<<t%w); else mask[t/w] |= 1<<t%w; } wlock(&pgrp->ns); for(i=0; i < nelem(pgrp->notallowed); i++) pgrp->notallowed[i] |= mask[i]; wunlock(&pgrp->ns); } .P2 Devmask is called from the write handler for /dev/drivers. This bitmask is then consulted any time a name is resolved that begins with '#'. This is done from within the .CW namec () function using the following function to check if a particular device .CW r is permitted. .P1 int devallowed(Pgrp *pgrp, int r) { int t, w, b; t = devno(r, 1); if(t == -1) return 0; w = sizeof(u64int) * 8; rlock(&pgrp->ns); b = !(pgrp->notallowed[t/w] & 1<<t%w); runlock(&pgrp->ns); return b; } .P2 .LP We found that once removal is made to a core verb of these sharp devices it becomes easy to start to view access to them as capabilities. This is aided by system functionally already neatly organized into the various devices themselves. For example, one could say a process is capable of accessing the broader internet if it has access to the .CW devip device. This access can either be direct via it's path under '#' or through a location in the namespace where this device had already been bound. With these changes, the entire capability list of a process is on display through just its /proc/$pid/ns file. This .CW ns file would indicate if a particular device is bound and now also includes the list of devices a process has access to. .LP In practice, this results in a pattern of binding in a sharp device, making use of them and removing them when no longer needed. A namespace file for a web server could now look like .P1 bind #s /srv # /srv/www created by srvfs www /lib/www mount /srv/www /lib/ unmount /srv chdev -r s # chdev &~ s .P2 In this example we have created a new root for the process by using exportfs to expose a little piece of the boot namespace. We unmount .CW devsrv and remove access to it with .CW chdev ensuring there is no way for our process to talk to the real .CW /srv/boot . This provides a nice succinct lifetime of access to .CW devsrv and makes the removal of these sharp devices as easy as it is to use them in the first place. .LP Like .CW RFNOMNT , .CW chdev does not restrict access to sharp devices that had already been mounted. This allows a process to use a subsection or only one piece of sharp devices as well. One example of this may be to restrict a process to just a single network stack .P1 bind '#I1' /net chdev -r I .P2 .SH /srv/clone .LP With this .CW chdev mechanism, the ability for a device to provide isolation of its own became more powerful. Partially illustrated in the previous .CW devip example. .CW Devsrv , the sharp device providing named pipes, was an ideal target for adding isolation. Devsrv provides a bulletin board of all posted 9p services for a given host. We wanted to provide a mechanism for a process, or family tree of process to share a private .CW devsrv between themselves. .LP The design for this was borrowed from devip, one in which a process opens a .CW clone file to read its newly allocated slot number. This new 'board' appears as a sibling directory to the .CW clone it was spawned from. This new board is itself a fully functioning .CW devsrv with its own clone file, making nesting to full trees of .CW srvs quite easy, and completely transparent. The following illustrates how one could replace their global .CW /srv with a freshly allocated one. .P1 </srv/clone { s='/srv/'^`{read} bind -c $s /srv exec p } .P2 Also like devip, once the last reference to the file descriptor returned by opening .CW clone is closed the board is closed and posters to that board receive an EOF. It is important to bake this kind of ownership into the design, as self referential users of .CW /srv are quite common in current code. .LP This along with chdev can be used to create a sandbox for /srv quite easily, the process allocates itself a new /srv then removes access to the global root srv. This allows potentially untrusted process to still make use of the interface without needing to worry about their access to the global state. The practice of having new boards appear as subdirectories allows the entire state to easily be seen by inspecting the root of devsrv itself. .SH Restricting Within a Mount .LP As shown earlier with the use of .CW srvfs , an intermediate file server can be used to only service a small subsection of a larger namespace. In that example we used this to expose only /lib/www from the host to processes running a web server. This can be limited as the invocation of .CW exportfs can become more complicated if the user wishes to use multiple pieces from completely separate places within the file tree. To address this a utility program .CW protofs was written to easily create convincing mimics of the filesystem it was run from. .CW protofs accepts a .CW proto file, a text file containing a description of file tree, and uses it to provide dummy files mimicking the structure. These dummies can then be used by a process as targets for bind mounts of its current namespace, providing the illusion of trimming all but select pieces. This new root cannot be simply bound over the real one, that still allows an unmount to escape back to the real system, but rexporting the namespace still works. To illustrate a more involved setup than before: .P1 # We want to provide our web server # with /bin, /lib/www and /lib/git ; cat >>/tmp/proto <<. bin d775 lib d775 www d775 git d775 . ; protofs -m /mnt/proto /tmp/prot ; bind /bin /mnt/proto/bin ; bind /lib/www /mnt/proto/lib/www ; bind /lib/git /mnt/proto/lib/git # A private srv could be used, omitted for brevity ; srvfs webbox /mnt/proto # Namespace file for using our new mini-root ; cat >>/tmp/ns <<. mount #s/webbox /root bind -b /root / chdev -r s . ; auth/newns -n /tmp/ns ls / bin lib ; .P2 .SH Future Work .LP While we think these bring us closer to namespaces as security boundaries, there is still plenty of work and understanding to be done. One particular item of interest is attempting some kind of isolation of .CW devproc , possibly in a similar fashion to the .CW /srv/clone implementation, but attempts have yet to be made. The exact nature of .CW namespace files and how they relate to sandboxing as a whole has yet to be fully worked out. There is clear potential, but it is likely additional abilities may be required. It is somewhat difficult to synthesize a namespace entirely from nothing, which is something we found ourselves reaching for when building alternative roots to run processes within. There is potential for some merger of .CW proto and .CW namespace files to provide a template of the current namespace to graft on to the next one. .LP Both .CW chdev and .CW /srv/clone are merged into 9front and their implementations are freely available as part of the base system. .SH REFERENCES .LP [Beck18] Bob Beck, ``Pledge, and Unveil, in OpenBSD'', .I "BSDCan Slides" Ottawa, July, 2018. .LP [Price04] Daniel Price, Andrew Tucker, ``Solaris Zones: Operating System Support for Consolidating Commercial Workloads'', .I "Proceedings of the 18th Large Installation System Administration Conference" pp. 241-254, Atlanta, November, 2004. .LP [Biederman06] Eric W. Biederman ``Multiple Instances of the Global Linux Namespaces'', .I "Proceedings of the 2006 Linux Symposium Volume One" pp. 102-112, Ottawa, Ontario July, 2006.