Is it possible to limit standard streams available to linux at the process level?

Question

I would like to be able to spawn a linux process that would only have access to stdin, stdout, and stderr (nothing more and nothing less). Can I do this at the process level itself? I am also implicitly stating (oxymoron) that I don't want the spawned process to be able to change the "thing" that the other end of the stream points to.

Metaphorically:

• the process has a input pipe that comes from somewhere, it cannot change where the pipe starts from, so it cannot control where input comes from.
• the process has output and error pipes that go somewhere, it cannot change where the other end of the output pipes point to, so it cannot control where output goes to.
• it cannot create any new pipes.

I am also currently looking at SElinux. Would this allow me to create a process that only had access to these three streams? Thank you.

Answer 1

If you're root, you can chroot to a directory, drop privileges so that you no longer have filesystem write access, then exec. That will prevent a program from creating new files. But there's no way to prevent a program from creating pipes and sockets (well, no-sockets is possible with SELinux), and there's no way to prevent a program from rearranging and closing its file descriptors.

Well, I suppose you could use ptrace to trap all syscalls, and only allow the ones that you approve of, so when I say "there's no way" I mean "there's no easy way". This incurs a noticable overhead, but if you're careful enough you can make it secure. The strace or UMview projects may be good starting points if you decide to go down this path.

Answer 2

SELinux could do the job; you can assign permissions for certain programs to use certain system calls. By denying access to open, pipe, and others, you should be able to do exactly what you describe.

A second possible route is to use the LD_PRELOAD capability, and provide your own open,pipe,etc. functions. This isn't 100% secure, as the program could still access the system calls more directly ( assuming that this is a potentially hostile program )

Answer 3

This sounds very much like what is described this LWN article which basically blocks all syscalls except read, write and exit.

Answer 4

As stated in another answer SELinux does have various permissions that help lock down any process.

The kernel manages access to certain objects (with associated set of permissions) for example a file is an object, a directory is an object, a unix datagram socket is an object and many more.

probably the easiest thing to do is write a little policy. Luckily SELinux is deny by default so run your program and look at the logs for SELinux denials and only allow your program to do what you want. In other words you would avoid adding permission that involve object classes like msg (messages in a systemV message queue), msgq (SystemV message queue itself), sem (semaphores), shm (shared memory) and probably others depending on what it does.

I suggest the first time you do it have SELinux on but in permissive (see setenforce 0)

I would also suggest tools to help you build some policy, it can be a bit overwhelming to write basically raw M4