/usr/share/doc/libcap
This explorer reads the filesystem of the server it runs on, so /workspace/user isn't present here. Browsing and the terminal still work against this server's own disk from /.
# Notes concerning wider use of capabilities ## Overview **NOTE** These notes were added to the libcap package inlibcap-1.03. They pre-date file capability support, but fullyanticipate it. They are some thoughts on how to restructure a systemto better leverage capability support. I've updated them to render asan `.md` formatted file. As of Linux 2.2.0, the power of the superuser has been partitionedinto a set of discrete capabilities (in other places, thesecapabilities are know as privileges). The contents of the libcap package are a library and a number ofsimple programs that are intended to show how an application/daemoncan be protected (with wrappers) or rewritten to take advantage ofthis fine grained approach to constraining the danger to your systemfrom programs running as 'root'. ## Notes on securing your system ### Adopting a role approach to system security Changing all of the system binaries and directories to be owned bysome user that cannot log on. You might like to create a user withthe name 'system' who's account is locked with a '*' password. Thisuser can be made the owner of all of the system directories on yoursystem and critical system binaries too. Why is this a good idea? In a simple case, the `CAP_FOWNER` capabilityis required for the superuser to delete files owned by a non-root userin a _sticky-bit_ protected non-root owned directory. Thus, the stickybit can help you protect the `/lib/` directory from a compromizeddaemon where the directory and the files it contains are owned by thesystem user. It can be protected to ensure that the daemon is notrunning with the `CAP_FOWNER` capability... ### Limiting the damage If your daemon only needs to be setuid-root in order to bind to a lownumbered port. You should restrict it to only having access to the`CAP_NET_BIND_SERVICE` capability. Coupled with not having any fileson the system owned by root, it becomes significantly harder for sucha daemon to damage your system. Note, you should think of this kind of trick as making things harderfor a potential attacker to exploit a hole in a daemon of thistype. Being able to bind to any privileged port is still a formidableprivilege and can lead to difficult but _interesting_man-in-the-middle attacks -- hijack the telnet port for example andmasquerade as the login program... Collecting passwords for anotherday. ### The /proc/ filesystem This Linux-specific directory tree holds most of the state of thesystem in a form that can sometimes be manipulated by fileread/writes. Take care to ensure that the filesystem is not mountedwith uid=0, since root (with no capabilities) would still be able toread sensitive files in the `/proc/` tree - `kcore` for example. [Patch is available for 2.2.1 - I just wrote it!]