Disallow File IO for a process except for FIFOs

Question

How do you start a process that cannot do any file IO (opening / closing files, creating / deleting files, reading / writing files, etc.), except to read and write to pre-created FIFOs?

(chroot will not work because the process can break out of it, but messing with / modifying the kernel and such is okay)

BTW: I cannot modify the programs that are being run

Are your requirements anymore than what's offered in this U&L Q&A titled: How to prevent a process from writing files — slm, Nov 03 '13 at 22:20
What do you mean a process can break out of a chroot? Unless it is root it shouldn't be able to AFAIK. You might want to submit a bug report to whatever kernel you use. — Kevin Cox, Nov 03 '13 at 22:29
Gilles idea of using a library that hooks into LD_PRELOAD might be a good alternative: http://unix.stackexchange.com/a/64745/7453. Specifically here: http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick — slm, Nov 03 '13 at 22:33

score 4 · Accepted Answer · edited May 23 '17 at 12:39

4

If

the program can be modified to make a system call of your choice before any of the untrusted code (this might be done via LD_PRELOAD), and
the program doesn't need to do any system calls beyond exit(), sigreturn(), read() and write()

then you can use seccomp (Wikipedia article). To allow for more that just those system calls there's seccomp-bpf, which uses Berkeley Packet Filter to determine which system calls to allow. The libseccomp library simplifies seccomp-bpf so (for example) if you wanted to allow the close() system call:

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(close), 0);

Or for something similar to chroot, but which can't be broken out of, you could try Linux containers, OpenVZ or Linux VServer.

edited May 23 '17 at 12:39

Community

1

answered Nov 03 '13 at 22:37

Matthew Cline

3,355

Is there any way to allow other non-IO related calls (ie: waitpid(), time(), alarm(), pause(), uname(), mmap(), etc.)? – haneefmubarak Nov 04 '13 at 01:53
There's seccomp-bpf, which uses Berkeley Packet Filter rules to determine which syscalls to allow. – Matthew Cline Nov 04 '13 at 21:48
I was looking more for something where I could specify syscalls. – haneefmubarak Nov 05 '13 at 08:58
I'd guess that libseccomp would allow you to just specify the syscalls. – Matthew Cline Nov 05 '13 at 12:14
That will work. Please add that libseccomp will allow specifying syscalls to the answer and I will mark it as correct. Thanks Matthew! – haneefmubarak Nov 06 '13 at 23:19
Done, plus I added an example line of libseccomp code which adds an allowed syscall. – Matthew Cline Nov 07 '13 at 02:48
Marked as correct. Thanks again, Matthew. – haneefmubarak Nov 07 '13 at 08:31

score 1 · Answer 2 · answered Nov 03 '13 at 22:20

1

Your best bet is to run the problem as an unprivileged user. The give the correct permissions to the FIFO.

That said the unprivileged user will have access to all the files any other non-privileged user will have.

To do more then that you would have to seriously modify things on the file system. but:

chmod o-rwx / -R

Will certainly lock things down. But again other users won't be able to read anything either.

I guess the more important questions to ask your self is "Why do I need this restriction?" Maybe there is a better way to obtain your goals?

answered Nov 03 '13 at 22:20

coteyr

4,310

1

Seems like too much work. Seems like he shouldn't have to lean on the environment this much. Also it fails for the same reason a chroot doesn't work here either. User's can play games and "level up". – slm Nov 03 '13 at 22:22
Ture, but you really need to look at why you need this restriction. It's likely that your over thinking some other problem. – coteyr Nov 03 '13 at 22:24
I don't doubt that, I'm just playing the OP's part in looking at this. Your idea is what I would've probably went with, truth be told. It passes my tests of being reasonably portable (just lift the setup of the account and a couple of chmods/chowns from boxA to boxB). – slm Nov 03 '13 at 22:26

score 1 · Answer 3 · edited Apr 13 '17 at 12:36

1

A process cannot break out of a chroot if you do things right, namely, run the process under its own user ID (i.e. there must not be any process running as the same user outside the chroot).

Chroot the process to a directory that the process cannot write to and that only contains FIFOs. You'll need to either put the executable and the libraries and data files it needs in that chroot, or else start the process as root, then chroot and then change the user ID.

If you can't involve root, you can use a namespace, but you need a recent kernel for that (≥3.8). First create a user namespace, then inside it chroot and change to an in-namespace user ID with the required absence of privileges.

Alternatively, this can be done (with root's cooperation) through security frameworks such as SELinux or AppArmor: disable all filesystem-related syscalls except open, read, write, close and lseek, and restrict open to the directory containing the FIFOs. Be sure to disable ptrace as well.

edited Apr 13 '17 at 12:36

Community

1

answered Nov 04 '13 at 22:46

Gilles 'SO- stop being evil'

829,060

I don't suppose there is some way to do the second way without the help of root (or at least, with root only being involved once in a setup of sorts)? – haneefmubarak Nov 05 '13 at 08:57
@haneefmubarak Without root being involved, you need either a recent Linux kernel for user namespaces or to go to full virtualization. (If you were only targetting cooperating processes, you could do it with LD_PRELOAD, but that can be easily worked around by a malicious process.) – Gilles 'SO- stop being evil' Nov 05 '13 at 09:07
How would a malicious process work around LD_PRELOAD? – haneefmubarak Nov 05 '13 at 09:48
Also, the lwn link is broken. – haneefmubarak Nov 05 '13 at 09:48
@haneefmubarak LD_PRELOAD only redirects library calls. A process can make system calls directly, this won't be affected. This needn't even be malicious (though in practice it does tend to work in most non-malicious situations): in particular LD_PRELOAD has no effect on a statically-linked binary. – Gilles 'SO- stop being evil' Nov 05 '13 at 11:19
And uh, do you have the lwn link on namespaces? – haneefmubarak Nov 06 '13 at 01:35

Disallow File IO for a process except for FIFOs

3 Answers3