14

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


14

To remove capabilities from a file use the -r flag setcap -r /path/to/program This will result in the program having no capabilities.


9

Capabilities are properties of processes. Traditionally there are three sets: Permitted capabilities (p): capabilities that may be "activated" in the current process. Effective capabilities (e): capabilities that are currently usable in the current process. Inheritable capabilities (i): file capabilities that may be inherited. Programs run as root always ...


9

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


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


8

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


8

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


8

What @stephen-harris posted is right. But I believe it removes all capabilities added to the program in one shot. To remove a specific capability, following would work (following the example in the question) setcap 'cap_net_bind_service=-ep' /path/to/program, Notice the '-' sign. You can verify the {effect of the commands} capabilities over an executable ...


8

I actually found the NoNewPrivileges= option that allows my process children to use the setuid(). From what they are saying, it is certainly not an option one should lightly choose to use. However, the default is: do not allow the setuid() feature. (what they mean by «elevate privileges».) What worked for me was to do this: NoNewPrivileges=false Note ...


8

Extended permissions such as access control lists set by setfacl and capability flags set by setcap are stored in the same place as traditional permissions and set[ug]id flags set by chmod: in the file's inode. (They may actually be stored in a separate block on the disk, because an inode has a fixed size which has room for the traditional permission bits ...


8

# getcap ./some_bin ./some_bin =ep That binary has ALL the capabilites permitted (p) and effective (e) from the start. In the textual representation of capabilities, a leading = is equivalent to all=. From the cap_to_text(3) manpage: In the case that the leading operator is =, and no list of capabilities is provided, the action-list is assumed to refer ...


7

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


7

How capabilities work in Linux is documented in man 7 capabilities. Process' capabilities in the effective set are against which permission checks are done. File capabilities are used during execv call (which happens when you want to run another program1) to calculate the new capability sets for the process. Files have two sets for capabilities, permitted ...


6

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


5

Lekensteyn's answer seems accurate and complete but I will try to provide another explanation from a different angle that will try to emphasize the problem that the ambient capabilities set solves. When you run sudo capsh --user=<some_user> -- There are 2 system calls of interest that cause capabilities to be recalculated (and potentially dropped): ...


5

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


5

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


5

Yes it is expected behaviour. I don't have a document that says it but you can see in this patch from 2007 When a file with posix capabilities is overwritten, the file capabilities, like a setuid bit, should be removed. This patch introduces security_inode_killpriv(). This is currently only defined for capability, and is called when ...


5

Indeed, iptables uses the netlink interface to communicate with the kernel. It opens a netlink socket to xtables, then issues commands via this socket. Access control is performed when the socket is opened, not for individual commands, so the same permissions are required for listing and modifying rules. The only way to allow a user to list rules but not ...


5

Solaris has privileges, as described here: https://docs.oracle.com/cd/E23824_01/html/821-1456/prbac-2.html. Generally, Privileges would be assigned to roles, and then roles to users, and within the roles, you can assign very granular sets of privileges to executables and scripts. Solaris RBAC seems similar at first to sudo, however it's really sort of the ...


4

It seems that the right tool for this job is fseccomp Based on sync-ignoringf code by Bastian Blank, I came up with this relatively small file that causes all its children 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 <waldi@debian....


4

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


4

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


4

It appears iptables needs both CAP_NET_RAW and CAP_NET_ADMIN to be able to read the tables. I tried $ cp /usr/sbin/iptables ~/iptables # note, it may be a symbolic link $ sudo setcap CAP_NET_RAW,CAP_NET_ADMIN+ep ~/iptables $ ~/iptables -nvL and it was ok.


4

setcap sets file capabilities which are stored in filesystem extended attribute. These are explained in man 7 capabilities: The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability. You can inspect the capabilities of a running process by examining CapInh/CapPrm/CapEff fields in /proc/PID/status. See my ...


4

What does "F(effective) ? P'(permitted) : 0" mean? The expression predicate ? a : b, comes from C like languages. It means a if predicate else b or if the predicate is true it evaluates to a else it evaluates to b. Therefore P'(effective) = F(effective) ? P'(permitted) : 0 means if the files effective bit is set, then copy the permitted set into the ...


4

Since we’re discussing Linux specifically (at least, I take it that’s what you want since you used the linux tag), the fork and execve manpages are the appropriate references; they list all the attributes which aren’t preserved. Most of this behaviour is specified by POSIX, but there are some Linux specificities. The man pages don’t list attributes which ...


4

Yes, the idea of capabilities is that the user id itself doesn't give any special abilities. An UID 0 process can also drop unneeded capabilities. It would still retain access to files owned by UID 0 (e.g. /etc/shadow or /etc/ssh/sshd_config), so switching to another UID would still likely be a smart thing to do in addition. We can test this with capsh, it ...


4

The capabilities are put in the permitted set (p), and all permitted capabilities are copied into the effective set (e). There does not seem to be any capabilities in your example (where did you get it from?). The e is used for legacy programs (possibly most programs at the current time), that is programs that don't know about capabilities, so can not them-...


3

You need libcap-progs sudo zypper install libcap-progs


Only top voted, non community-wiki answers of a minimum length are eligible