Tag Info

Hot answers tagged

8

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 ...


8

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 ...


6

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 ...


5

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 ...


3

The proc filesystem doesn't support capabilities, ACL, or even changing basic permissions with chmod. Unix permissions determine whether the calling process gets access. Thus only root can write that file. With user namespaces, that's the global root (the one in the original namespace); root in a container doesn't get to change sysctl settings. As far as I ...


3

Sadly, no. There isn't a way to make dpkg use file capabilities, and apparently nobody has ever asked, though the library itself is available. I skimmed through the Debian Policy Manual, and there isn't a single entry that reference this feature. That said, you can use dh_override_install (if you use debhelper), pre/post maintainer scripts or modifying the ...


3

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 ...


2

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


2

Would you consider writing a substitute to open(…) function, and loading it using LD_PRELOAD?


2

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.


2

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 ...


2

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 <mail@joachim-breitner.de> * * Based on code Copyright (C) 2013 Bastian Blank ...


2

As mentioned in this Kernel Mailing List message, whether a process needs extra security is checked in cap_bprm_secureexec() of the kernel file security/commoncap.c, which does check for capabilities. This is then exported to the process via the auxiliary vector. This can be accessed/tested via getauxval(AT_SECURE). I inserted getauxval(AT_SECURE) into a ...


2

Setting the hostname in linux is done via the sethostname(2) syscall. And /bin/hostname is a bare wrapper around this syscall (and a few related syscalls). /etc/hostname is supposed to be read during the boot process by some script, who subsequently runs /bin/hostname to complish its job. CAP_SYS_ADMIN is one of linux capabilities(7), allows a thread to ...


1

As an addendum to the accpted answer by Gilles: I managed to achieve my goal of writing to /proc/sys/vm/drop_caches (or to /proc in general, to be precise) in a much easier way when working with docker: docker run -ti --rm -v /proc:/writable_proc ubuntu:vivid bash # echo 3 > /writable_proc/sys/vm/drop_caches That does it for my purpose. Thank you very ...


1

Just use getcap: if nmap --version >/dev/null && getcap `which nmap` | grep -q cap_net_raw; then export NMAP_PRIVILEGED="1" else echo "WARNING: No Nmap with cap_net_raw in \$PATH!" >&2 fi


1

According to this discussion CAP_SYS_RAWIO capability needs to be applied to smartctl executable.


1

And one last desperate syntax guess pays off: # setcap cap_net_bind_service,cap_sys_boot=+ep /usr/bin/nodejs # getcap /usr/bin/nodejs /usr/bin/nodejs = cap_net_bind_service,cap_sys_boot+ep


1

If a user/process has cap_setfcap or cap_dac_override, then it is trivial to gain root access. If the user is trusted you can add them to group sudo/sudoers (depends on configuration), and they can use sudo. You can even add rules to /etc/sudoers.d/ to allow the user to run setcap only, and only in the specified ways. However this will just give you a ...


1

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.


1

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 ...


1

It turns out that setting +i on the wrapper does not add the capability to the CAP_INHERITABLE set for the wrapper process, thus it is not passed through exec. I therefore had to manually add CAP_DAC_OVERRIDE to CAP_INHERITABLE before calling execl: #include <sys/capability.h> #include <stdio.h> #include <unistd.h> int main(int argc, char ...


1

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 ...


1

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).


1

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.


1

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