Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Sep 2009
Wrapper to sandbox individual processes
There have been various solutions and attempted solutions, and as far as I know there's nothing that's both secure and cross-platform. Also, you have to consider what you need this for: if you want to prevent a process from writing to the filesystem, does that mean this process is untrusted, potentially malicious? If so then the problem becomes a lot more complicated. Even if a process can't write files on your machine, it could perform some mischief on the network... And if you're really dealing with malicious code, it could be written to exploit known bugs in software you run (esp. the kernel or any packages that elevate privileges) - which could put a great big vulnerability into an otherwise-secure sandbox...
The Google Chrome browser is being written to implement sandboxes for any plugins that run in the browser - their goal is to prevent any bugs (or malicious code) in plugins from causing damage to the system. They're pursuing various approaches to the problem on various platforms. Their sandboxing method for Linux is apparently not totally secure yet, but it's worth looking up if you're interested in this kind of thing.
The most straightforward way of restricting a process's capabilities is to do things like chroot() and setuid() - change the user ID to an account with no significant privileges and chroot() to restrict their view of the filesystem to an area where they can't do any damage. However, there are various limitations to keep in mind. First off, this does nothing to prevent network access. Second, if the process in the chroot() jail has a way of elevating its privileges, it can (on most systems) use another call to chroot() to break out of the jail and gain access to the rest of the system. So this approach has its uses but it's not adequate for running possibly malicious code.
Linux process namespaces
Linux 2.4.19 introduced the CLONE_NEWNS flag to the clone() syscall. More recently in the 2.6 series they introduced CLONE_NEWPID, CLONE_NEWNET, CLONE_NEWIPC, etc. These "namespaces" for filesystems, process IDs, network configuration, and so on give you the ability to create a process that doesn't have the same access to these facilities as processes on the outside have. For instance, with CLONE_NEWNS your new process can have a whole new set of filesystem mounts... With CLONE_NEWPID the process gets a new process ID table (effectively cutting off the new process's access to processes on the outside) - and with CLONE_NEWNET the process (I think) doesn't get any network access at all unless you set up a virtual network device to provide (possibly firewalled) access to the system's real network interfaces.
Limitations: It's not available in all kernel versions, of course... The clone() man page says CLONE_NEWNET is incomplete (possibly out-of-date? I haven't been able to find further details on this) - and I don't know how secure these mechanisms really are. Of course that depends largely on whether there are any major kernel bugs in the kernel version you run.
This isn't a Linux feature... But it's worth mentioning because it's the first case I saw of jail functionality being explicitly provided by a free OS... The implementation is, I think, pretty similar to Linux's process namespaces - in Linux terminology, the jail provides a new process namespace, mount namespace, and net namespace. It also restricts various sensitive bits of functionality even if code manages to achieve root access from within the jail (i.e. can't load kernel modules, can't change the network configuration, can't mount filesystems or create device nodes, etc.) As with the Linux process namespaces I don't know how secure this really is.
seccomp is a largely-unused Linux feature that implements a very restrictive process jail. Actually it's too restrictive IMO... Basically, once you activate seccomp for a process, any attempt by that process to run a syscall other than read(), write(), exit(), and sigreturn() will result in termination of the process. So you could load a shared object of untrusted code, establish a few communication channels to the outside, then enter seccomp mode and run the untrusted code. The security model is therefore very simple: pretty much the only thing you can do is communicate using already-open file descriptors. The down-side is that this approach severely limits what you can do. You can't even call exec() - which means it's impossible to use this approach to securely run an executable program.
Tracing features in Linux such as ptrace or ftrace can also (if used aggressively) be used to restrict what a process may do. The basic idea is to intercept any syscalls, check their arguments, and reject the call if it's not acceptable according to your security policy. I don't know much about ftrace, but there's at least one big problem with using ptrace for this sort of thing: there's a race condition if the process calls fork(). If you allow fork(), the newly-created process is not traced until you attach the tracer to it. In that time, the new process could perform another syscall (such as another fork()) that would escape the tracer's attention.
(See also, plash and sydbox, which implement this approach.)
Unfortunately I know very little about what systems like SELinux or AppArmor can do in terms of sandboxing... A quick Google search turned up this:
So I guess it's possible...
I want to talk about fakeroot just because you brought it up... It's not meant for any kind of security, its purpose is strictly to provide an environment that gives the illusion of root access for the purpose of building packages. It does this without elevating the user's real authority by using LD_PRELOAD to replace various standard C library functions. This means it can't do anything with syscalls like open(). This also means that this approach, by itself, is incapable of restricting a malicious program's activities. If the program uses syscalls instead of C standard library calls, the whole fakeroot mechanism is subverted.
That's pretty much what I know about process jails on Linux. I'd love to learn more...