Hot answers tagged capabilities
How about creating an empty chroot, then bind-mount the main filesystem as read-only inside the chroot? Should probably be something like this to create a read-only bind-mount: mount --bind /foo/ /path/to/chroot/ mount -o remount,ro /path/to/chroot/ You can bind-mount other directories which you want the jail to have write access to as well. Be careful ...
The traditional answer is to run the program as another user and use iptables -m owner. That way, the network configuration is shared. However, with the advent of namespaces, there is an easier way. With namespaces, you unshare the network, then create a virtual network link if you need limited network access. To share unix domain sockets, all you need is ...
Although POSIX has a standard for capabilities which I think includes CAP_NET_BIND_SERVICE, these are not required for conformance and may in some ways be incompatible with the implementation on, e.g., linux. Since webservers like apache are not written for only one platform, using root privileges is the most portable method. I suppose it could do this ...
Setting capability on the script will not be effective. It's the similar situation as not working setuid bit on script. Similar as in the latter case it's the implementation of how execve handles shebang and the security reasoning behind it (for details see: Allow setuid on shell scripts). I think you have these options set the capabilities on interpreter ...
File system capabilities in Linux were added to allow more fine-grained control than setuid alone will allow. With setuid it's a full escalation of effective privileges to the user (typically root). The capabilities(7) manpage provides the following description: For the purpose of performing permission checks, traditional Unix implementations ...
A virtual machine would make it possible for the script to write anywhere without affecting the host system, and to inspect where it's actually trying to write to, which seem to be the goals. For example, you can easily start up Arch Linux with kvm -boot d -m 512 -cdrom archlinux-*.iso
Would you consider writing a substitute to open(…) function, and loading it using LD_PRELOAD?
You could run it in a chroot, mounting special versions of /tmp and such inside. Perhaps systemd is of help, and particularly systemd-nspawn(1), which looks just like what you want.
The simplest solution is probably a wrapper program that creates a new filesystem namespace with the relevant filesystems mounted read-only and then execs the program you are trying to restrict. This is what systemd does when you use ReadOnlyDirectories= to mark certain directories as read-only for a service. There is also an unshare command in util-linux ...
It seems that the right tool for this job is seccomp. Based on fsync-ignoring code by Bastian Blank, I came up with this relatively small file that causes all its childs to not be able to open a file for writing: /* * Copyright (C) 2013 Joachim Breitner <email@example.com> * * Based on code Copyright (C) 2013 Bastian Blank ...
One workaround is to not use expect fork or expect daemon, and just make your daemon a foreground process. Then Upstart will not trace it at all.
I'm now thinking this is a bug, and related to the way upstart starts services with "expect daemon" (i.e. services that fork twice upon startup). I notice that if I use strace on a process that is using capabilities(7) the capabilities are also ignored. I suspect that upstart, in order to determine the PID to wait on, traces a service specified with "expect ...
There are several reasons to start a web server as root: to bind to port 80 (ports below 1024 are reserved to root, so that if a remote user is connecting to a service on a low port, they know that this service is approved by root); to set up confinement, e.g. chroot; to read and serve users' web pages, where applicable. That least reason is a poor ...
What you want to do is not possible. Not only does pam_cap only manipulate the inheritable capabilities (so it does not actually grant any permitted/effective capability at all), it also only deals with users and not groups (not even primary groups).
One way to at least prevent the process from writing the files (but not from creating them) is to call ulimit -f 0 first. This will abort the process as soon as it tries to write to a file, but creating empty files is still possible.
Doing some initial setup as root is really the easiest way. Specifically, a chroot into a read-only bind mount is the path of least resistance. You can use bindfs instead of mount --bind to create the read-only view without needing to be root. However, you do need to do something as root to prevent access to other files, such as chroot. Another approach is ...
Only top voted, non community-wiki answers of a minimum length are eligible