The way capabilities work in Linux is documented in man 7 capabilities.

Processes' capabilities in the effective set are against which permission checks are done. File capabilities are used during an execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to a process' inherited set and affects how capabilities are calculated during a call to execv. Capabilities can only be dropped from the bounding set, not added.

Permissions checks for a process are checked against the process' effective set. A process can raise its capabilities from the permitted to the effective set (using capget and capset syscalls, the recommended APIs are respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during an execv syscall. During execv, new effective and permitted sets are calculated and the inherited and bounding sets stay unchanged. The algorithm is described in the capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

P'(inheritable) = P(inheritable)    [i.e., unchanged]

Where P is the old capability set, P' is the capability set after execv and F is the file capability set.

If a capability is in both processes' inheritable set and the file's inheritable set (intersection/logical AND), it is added to the permitted set. The file's permitted set is added (union/logical OR) to it (if it is within the bounding set).

If the effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to the inherited and permitted sets and the effective bit is set. When your binary is executed, the process will have those capabilities in the effective and permitted sets if they are not limited by a bounding set.

[1] For the fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics for how capabilities are set in the effective and permitted sets.

In the link you provided , the use setcap Sniffing with Wireshark as a Non-Root User because, by default, raw access to network interfaces (e.g. eth0) requires root privileges and running it with root privileges is a bad idea .

setcap - set file capabilities

man page Link

Check file system capabilities Man Page

CAP_NET_ADMIN - Allow various network-related operations (e.g., setting privileged socket options, enabling multicasting, interface configuration, modifying routing tables).



CAP_NET_RAW - Permit use of RAW and PACKET sockets.

For more info Site

This sets the CAP_NET_RAW bit in both the "effective" (e) and "permitted" (p) capability sets. These two sets, along with the "inheritable" set, govern the capabilities that a process has or can set.

See more here:

capabilities - Linux man page

Capability Sets

Each thread has three capability sets containing zero or more of the above capabilities:

Effective - the capabilities used by the kernel to perform permission checks for the thread.

Permitted - the capabilities that the thread may assume (i.e., a limiting superset for the effective and inheritable sets). If a thread drops a capability from its permitted set, it can never re-acquire that capability (unless it exec()s a set-user-ID-root program).

inheritable - the capabilities preserved across an execve(2). A child created via fork(2) inherits copies of its parent's capability sets. See below for a discussion of the treatment of capabilities during exec(). Using capset(2), a thread may manipulate its own capability sets, or, if it has the CAP_SETPCAP capability, those of a thread in another process.

Searching for setcap

I believe setcap is contained in this package libcap2-bin. I found this by googling for "debian setcap" which led me to this man page:

• https://manpages.debian.org/jessie/libcap2-bin/setcap.8.en.html

The title of the man page tells you which package it resides in:

/ jessie / libcap2-bin / setcap(8)

Now that we "think" we know the package's name we can search for it:

• https://packages.debian.org/jessie/libcap2-bin

If you scroll down to the bottom of that page you'll see all the various architectures. Click the link for amd64:

• https://packages.debian.org/jessie/amd64/libcap2-bin/filelist

Found it

And there's setcap:

File list of package libcap2-bin in jessie of architecture amd64
/sbin/capsh
/sbin/getcap
/sbin/getpcaps
/sbin/setcap
/usr/share/doc/libcap2-bin/README.Debian
/usr/share/doc/libcap2-bin/changelog.Debian.gz
/usr/share/doc/libcap2-bin/changelog.gz
/usr/share/doc/libcap2-bin/copyright
/usr/share/man/man1/capsh.1.gz
/usr/share/man/man1/getpcaps.1.gz
/usr/share/man/man5/capability.conf.5.gz
/usr/share/man/man8/getcap.8.gz
/usr/share/man/man8/pam_cap.8.gz
/usr/share/man/man8/setcap.8.gz

I was experiencing this too, and was able to get it working by building and installing the latest version of libcap from source. This may not be the best solution, but it worked for me.

libcap-2.53

$ git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/morgan/libcap
$ cd libcap
$ git checkout libcap-2.53
$ make
$ make test
$ make sudotest
$ sudo make install

I ran the tests to confirm everything was working before install.

Once it had been installed I was able to run the commands listed in the perf-security doc as expected.

The setcap on the file stores the capabilities in an extended attribute with a call to setxattr. This extended attribute is stored like other attributes (ownership, rights...) in the filesystem.

Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability.

So, you don't have to reset your cap on each reboot.

I found the solution. I had to add this to the libcap recipe

PACKAGECONFIG_class-native = "attr"

As the generated binaries (setcap & getcap) are depending on libattr, and this has to be configured manually.

I found that it's already configured for the target package

PACKAGECONFIG ??= "attr ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)}"

Sorry for disturbing.