I have a situation where I need a non-root user to be allowed to create TUN/TAP interfaces. I understand that this requires the CAP_NET_ADMIN capability. There have been other questions about this, but the answers seem to focus on granting the CAP_NET_ADMIN capability to a **file**/**program**, not to the user. In my case, I need the capability to be assigned to the **user**, so they can use whatever tool they see fit to create the interfaces (i.e. not restricted to a specific file/program used to create them). Is this possible in Linux? Specifically, I'm using Ubuntu 22.04. For context, the reason for this is that I'm creating the TUN interface through a custom program that makes the system calls, and I need this to work while debugging it. Since it builds a new binary every time I run the debugger, switching to root and assigning the capability to the binary and then switching back to debug the binary is not feasible.

I am having a difficult time understanding how capabilities are inherited. It is possible there is no such thing as "capability inheritance" and that I have completely misunderstood this documentation: https://man7.org/linux/man-pages/man7/capabilities.7.html So I may need help re-orienting my entire understanding of what linux capabilities are! In terms of how I tried to understand capability inheritance, here is the experiment I ran:

bob@bob:~$ getcap /bin/bash # show no capabilities
bob@bob:~$ getpcaps $$ # shows no capabilities
2076: =
bob@bob:~$ sudo cp /bin/bash /usr/local/bin/testing_bash # let's make a copy of bash and give it all capabilities
bob@bob:~$ sudo setcap all=eip /usr/local/bin/testing_bash # giving all capabilities
bob@bob:~$ getcap /usr/local/bin/testing_bash # shows all capabilities
/usr/local/bin/testing_bash =eip
bob@bob:~$ /usr/local/bin/testing_bash # run bash with same capabilities as root
bob@bob:~$ getpcaps $$ # confirmed I have same capabilities as root
2092: =ep
bob@bob:~$ mkdir hello
bob@bob:~$ mount -t tmpfs test hello
mount: /home/bob/helloworld: must be superuser to use mount.

Basically I copied the bash command to testing_bash and gave it all capabilities so that I can run it as if i were root user. I run the testing_bash and confirmed that I do have all the escalated capabilities. But when I run the mount command later, it did not inherit my escalated capabilities, and instead I get a permission error. I tried reading this link here but I fail to comprehend: https://man7.org/linux/man-pages/man7/capabilities.7.html Specifically the line on Inheritable. I thought if I add the letter i to eip in the setcap all=eip, that means all child processes will inherit the capabilities of /usr/local/bin/testing_bash? I repeated a similar experiment with the User Namespace and still encountered the same capabilities error:

bob@bob:~$ unshare -U /usr/local/bin/testing_bash
nobody@bob:~$ getpcaps $$
2123: =ep
nobody@bob:~$ unshare -m /bin/bash
unshare: unshare failed: Operation not permitted

In other words, I start a new namespace with the testing_bash, confirmed I have all capabilities, but running the unshare command gives a capabilities/permission error. So my question is, **have I mis-understood how capability inheritance works?** ----- I am very new to learning about linux in general and linux capabilities. It's possible my question above is related to these two other questions I asked recently: https://unix.stackexchange.com/questions/792580/can-a-non-zero-not-0-not-root-user-run-a-process-with-capabilities-pid-e https://unix.stackexchange.com/questions/792603/how-come-setcap-all-eip-has-fewer-capabilities-than-setcap-cap-sys-admin-eip

**Background:** I have written a Java program to capture network packets. The code uses a wrapper API around libpcap and works nicely – as long as I run the program via **sudo**. I am now trying to figure out how to set up things so that I can run the program as a "regular" user. Ultimately, it will be run on a system where I **do not** have sudo privilege. After some investigation, a possible solution has been found that involves setting capabilities that provide privileged access in a specific way. Part of this involves setting the capabilities CAP_NET_RAW and CAP_NET_ADMIN to ei (e.g., sudo setcap 'CAP_NET_RAW=ei CAP_NET_ADMIN=ei' program). **The Problem:** So, I have done this for the java command on my system. Unfortunately, this has created a problem (which has been asked about by many in various forums) where, when java is invoked, the following message is displayed: >java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory This library does indeed exist and shows up in the list of libraries for the java command.

$ sudo find / -name libjli.so -print
/opt/jdk1.7.0_79/lib/amd64/jli/libjli.so
/opt/jdk1.7.0_79/jre/lib/amd64/jli/libjli.so
/usr/java/jdk1.7.0_79/lib/amd64/jli/libjli.so
/usr/java/jdk1.7.0_79/jre/lib/amd64/jli/libjli.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.35.x86_64/lib/amd64/jli/libjli.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.35.x86_64/jre/lib/amd64/jli/libjli.so

$ which java
/usr/bin/java

$ ls -l /usr/bin/java
lrwxrwxrwx. 1 root root 22 Jun 22  2015 /usr/bin/java -> /etc/alternatives/java

$ ls -l /etc/alternatives/java
lrwxrwxrwx. 1 root root 25 Jun 22  2015 /etc/alternatives/java -> /opt/jdk1.7.0_79/bin/java

$ ls -l /opt/jdk1.7.0_79/bin/java
-rwxr-xr-x. 1 uucp 143 7718 Apr 10  2015 /opt/jdk1.7.0_79/bin/java

$ ldd /usr/bin/java
	linux-vdso.so.1 =>  (0x00007fff3f3fa000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003150c00000)
	libjli.so => /usr/java/jdk1.7.0_79/lib/amd64/jli/libjli.so (0x00007ff56d563000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003151000000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003150800000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003150400000)

BTW, I am using the Java 7 JDK, not the OpenJDK. So, what's wrong here? Everything seems to be in place, yet it can't find what it needs. Does the fact that there are two versions of Java on the machine have anything to do it? Is there some other weird situation? Based on my searches, this problem has been encountered by many, but I couldn't seem to find a reason, nor a solution. Can anyone help with this? **UPDATE #1** Well, after a little more investigating, it appears that the problem is due to a "feature" in Java. The link below includes another link that gets to heart of the matter. Problem to launch java at Debian: “error while loading shared libraries: libjli.so” with the embedded link Why setuid java programs don't work . Based upon what I read in these, it would seem that running java with specific capabilities enabled is not allowed. Perhaps that will change at some point, with an improvement to Java security. If anyone knows about this, or more importantly, knows that a solution has been provided, please comment.

I need to get a list of capabilities available to the version of linux on which the program is executed. Just in order to give user possibility to choose what capability to grant to the file. Is there any chance to do this using some standard libraries? The only way I managed to do this is to look at the bounding set of cash --print, but 1. Somewhy it displayes ...,cap_audit_read,38,39, while /usr/include/linux/capability.h says that CAP_LAST_CAP is CAP_AUDIT_READ(37) 2. I would really use some descriptions to capabilities, if it is possible

This question is a follow up to this question: https://unix.stackexchange.com/questions/792580/can-a-non-zero-not-0-not-root-user-run-a-process-with-capabilities-pid-e And it is likely related to my other question here: https://unix.stackexchange.com/questions/792601/do-child-processes-inherit-capabilities-of-parent-processes IN the comments of the previous question, I thought maybe setcap all=eip gave a process all capabilities, and that it would have more capabilities than cap_sys_admin. But I think my comment is wrong. Here's what I tried First, I want to make a copy of the bash binary and give it the setcap all=eip, then run the newly created bash binary to see if I have capabilities similar to those of a root user.

bob@bob:~$ getpcaps $$ # confirm current bash has no capabilities
7210: =
bob@bob:~$ sudo setcap all=eip /usr/local/bin/testing_bash
bob@bob:~$ getcap /usr/local/bin/testing_bash
/usr/local/bin/testing_bash =eip
bob@bob:~$ /usr/local/bin/testing_bash
bob@bob:~$ getpcaps $$
7329: =ep

So at first, it seems that setcap all=eip can allow bob to run testing_bash as if he were root. But upon more investigation, it seems that setcap all=eip has **fewer capabilities** than setcap cap_sys_admin=eip. Here's a followup experiment I tried that led me to this observation:

# trying the all=eip
bob@bob:~$ mkdir dir1
bob@bob:~$ sudo cp /bin/mount /usr/local/bin/testing_mount
bob@bob:~$ sudo setcap all=eip /usr/local/bin/testing_mount
bob@bob:~$ getcap /usr/local/bin/testing_mount # confirmed all capabilities exists
/usr/local/bin/testing_mount =eip
bob@bob:~$ /usr/local/bin/testing_mount -t tmpfs temp dir1
testing_mount: drop permissions failed.

# remove the testing_mount and try with cap_sys_admin=eip
bob@bob:~$ sudo rm -f /usr/local/bin/testing_mount
bob@bob:~$ sudo cp /bin/mount /usr/local/bin/testing_mount
bob@bob:~$ sudo setcap cap_sys_admin=eip /usr/local/bin/testing_mount
bob@bob:~$ getcap /usr/local/bin/testing_mount # confirmed cap_sys_admin exists
/usr/local/bin/testing_mount cap_sys_admin=eip
bob@bob:~$ /usr/local/bin/testing_mount -t tmpfs temp dir1
bob@bob:~$ echo 'test' > dir1/test.txt
bob@bob:~$ cat dir1/test.txt
test
bob@bob:~$ sudo umount -l dir1
bob@bob:~$ ls dir1

So it seems the cap_sys_admin has more capabilities than all? I am confused by this. Can anyone help clear up my confusion?

I am learning about capabilities for the first time: https://man7.org/linux/man-pages/man7/capabilities.7.html As a frontend web developer, learning about this type of linux material feels like I jumped into the middle of a story and making a lot of incorrect assumptions...and I don't know what I don't know. At the moment, I'm trying to understand how to set file capabilities such that when a non-zero/non-root user runs the process, it has capabilities as if they were run by root. For example, here is a recent exercise I made for myself:

bob@bob:~$ ps auxf
...
bob    1286  0.0  0.0   9000  5852 pts/0    Ss   23:01   0:00          \_ -bash
bob@bob:~$ getpcaps $$
1286: =
bob@bob:~$ sudo su
root@bob:/home/bob# getpcaps $$
1311: =ep
root@bob:/home/bob# exit
exit
bob@bob:~$ sudo cp /bin/bash /usr/local/bin/testing_bash
bob@bob:~$ sudo setcap cap_sys_admin=eip /usr/local/bin/testing_bash
bob@bob:~$ /usr/local/bin/testing_bash
bob@bob:~$ getpcaps $$
1358: cap_sys_admin=ep
bob@bob:~$

I can see that bob is running process 1286 which has no capabilities. If I run the /bin/bash as a root user, i can see 1311: =ep means it has all capabilities. Out of curiosity, I was wondering if bob could achieve the same result of [pid]: =ep. I read there is something called setcap. So I made a copy of the /bin/bash as /usr/local/bin/testing_bash. Then I used setcap to try to assign cap_sys_admin to /usr/local/bin/testing_bash...cap_sys_admin is my best guess at giving the highest possible privileges. But when bob runs /usr/local/bin/testing_bash, the terminal doesn't show 1358: =ep, instead the terminal shows 1358: cap_sys_admin=ep Is there a way to let bob run /usr/local/bin/testing_bash and have [pid]: =ep? ------ Note1: It's possible I completely mis-understood how capabilities work. Just this morning, I was still operating under the assumption that capabilities are associated with USERs, i lost a lot of time before I understood capabilities are associated with files and processes, and have zero relevance to users. ------ Note2: I thought setcap all=eip might allow bob to run testing_bash with same capabilities as the root user. But I think I may have been wrong about this, and posted a follow up question here showing my investigation: https://unix.stackexchange.com/questions/792603/how-come-setcap-all-eip-has-fewer-capabilities-than-setcap-cap-sys-admin-eip

I want to bind to port 80 using cap_net_bind_service using normal user. I enabled cap_net_bind_service capability on the binary using sudo setcap cap_net_bind_service+ep server Inside the code, I make sure the correct cap is set by writing out what the current caps are

cap_t cap = cap_get_pid(pid);
    if (cap == NULL) {
      perror("cap_get_pid");
    }
    caps_text = cap_to_text(cap, NULL);
    if (caps_text) {
        printf("capturing: %s\n", caps_text);
    }

And I got the expected output capturing: cap_net_bind_service=ep. When checking the process cap by cat /proc/pid/status | grep Cap, I found

CapInh: 0000000000000000
CapPrm: 0000000000000400
CapEff: 0000000000000400
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

Questions: 1. But when I still got the error binding: Permission denied 2. How do know which bit correspond to which cap in such output 0000000000000400?

I have a systemd **user** service (not system service with a User=), But I need grant NET_ADMIN to this service, how to do it? I can use fcap, but I'm trying to find another way. Thanks.

I always assumed that /proc/[PID]/status shows capabilities that PID has in the user namesapce of the process that opens /proc/[PID]/status, not in the user namespace of PID, but it seems that I was wrong. Let's move one bash shell into a new user namespace and check that it see itself as root with all capabilities:

$ unshare -rU
# cat /proc/$$/status | grep Cap
CapInh:	0000000000000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000
# echo $$
965344

Let's open a second bash shell (in the parent user namespace) and check the capabilities of the first shell:

$ cat /proc/965344/status | grep Cap
CapInh:	0000000000000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000

It shows the same set of capabilities as seen from inside the user namespace! We can confirm that the first bash shell doesn't have real capabilities by trying to kill a process owned by other user.

$ sudo su test 
$ whoami
test
$ echo $$
978809

From the first shell:

# kill -s SIGKILL 978809
-bash: kill: (978809) - Operation not permitted

From a **real** root:

$ sudo kill -s SIGKILL 978809

-> Process got killed. Am I right in my conclusion that capabilities in /proc/PID/status are always shown in the user namespace of PID? If so, is it possible to see which set of capabilities process has in the user namespace of the opening process (or at least in the "root" user namespace)? Without it it's impossible to determine if a process really have privileges or not.

I am running a Linux Container (LXC) with (Hashicorp) vault installed that requires IPC_LOCK. Whenever I reboot or boot, it fails to start up vault with autostart. From what I can see in the logs it complains on a lack of IPC_LOCK. However, this is not an issue when I manually restart it. I have added different delays to try and remedy this, but it seems not to work. I want to ask if there is a systemd target or service that checks if such kernel capabilities are available before starting the LXC service, but maybe I am missing something more fundamental here?

When I increase fs.pipe-max-size like so:

bash
echo "fs.pipe-max-size = N" >> /etc/sysctl.conf
sysctl -p

*(N is ~4-10Mbytes)* And use F_SETPIPE_SZ to change named pipe sizes to N, sometimes it fails with "operation not permitted" error. The system has ~20 pipes and I set the same pipe buffer size on all of them. The question is: - is it because I hit some kind of a total kernel pipe buffer memory capacity (btw the system has 30G RAM)? - Or is it because I use N that isn't divisible by a page size so F_SETPIPE_SZ might set the size above the fs.pipe-max-size limit and it will fail as "operation not permitted"? Makes sense, I think I saw in logs values larger than I asked. - Or is it something totally else?

[Please, I don't want to know why I *shouldn't* edit it; I want to know why I *can't* edit it] # pwd /var/spool/cron/crontabs # ll sysadmin -rw------- 1 sysadmin crontab 210 Jun 17 16:05 sysadmin # getcap sysadmin # lsattr sysadmin --------------e------- sysadmin # filecap /var/spool/cron/crontabs/sysadmin Unable to get capabilities of /var/spool/cron/crontabs/sysadmin: No data available This is Ubuntu 22.04, ext4, LVM. I can delete the file, but I can't write to it. **EDIT** crontab -e successfully changes the file, as expected. However, editing the file with a text editor (in my case, emacs, while running as root) simply gives an error message ("Opening output file: Permission denied, /var/spool/cron/crontabs/sysadmin"). **EDIT 2** This question isn't about emacs, or any other editor - it appears that crontab -e has some magic which I can't duplicate as a root user, and that the magic is unrelated to file capabilities. If I try echoing to the file as suggested in a comment: root@vserver:/var/spool/cron/crontabs# echo "foo" >> sysadmin bash: sysadmin: Permission denied So what is it that's denying me permission?

I have a systemd-nspawn container in which I am trying to change the kernel parameter for msgmnb. When I try to change the kernel parameter by directly writing to the /proc filesystem or using sysctl inside the systemd-nspawn container, I get an error that the /proc file system is read only. [From the arch wiki I see this relevant documentation](https://wiki.archlinux.org/title/systemd-nspawn#:~:text=systemd%2Dnspawn%20limits%20access%20to,nodes%20may%20not%20be%20created.)

systemd-nspawn limits access to various kernel interfaces in the container to read-only, such as /sys, /proc/sys or /sys/fs/selinux. Network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and kernel modules may not be loaded from within the container.

I thought the container would inherit some properties of /proc from the host, including the kernel parameter value for msgmnb, but this does not appear to be the case as the host and container have different values for msgmnb. The kernel parameter value in the container:

cat /proc/sys/kernel/msgmnb
16384

Writing to the proc filesystem inside the container

$ bash -c 'echo 2621440 > /proc/sys/kernel/msgmnb'
bash: /proc/sys/kernel/msgmnb: Read-only file system

For completeness, I also tried sysctl in the container:

# sysctl -w kernel.msgmnb=2621440
sysctl: setting key "kernel.msgmnb": Read-only file system

I thought this value would be inherited from the host system. I set the value on the host, rebooted and re-created my container. The container (even new ones) maintains the value of 16384.

# On the host
$ cat /proc/sys/kernel/msgmnb
2621440

I've also tried using unprivileged the -U flag when booting the systemd-nspawn container but I get the same results. I've also tried to editted /etc/sysctl.conf in the container tree to include this line before booting the container:

kernel.msgmnb=2621440

I also looked into https://man7.org/linux/man-pages/man7/capabilities.7.html and noticed CAP_SYS_RESOURCE which has a line that reads:

CAP_SYS_RESOURCE
...
raise msg_qbytes limit for a System V message queue
                 above the limit in /proc/sys/kernel/msgmnb (see
                 msgop(2) and msgctl(2));

Using sudo systemd-nspawn --capability=CAP_SYS_RESOURCE -D /path/to/container, and then inside the container, when I use msgctl with IPC_SET and pass msqid_ds->msg_qbytes with a value that is higher than what is in /proc/sys/kernel/msgmnb, the syscall returns an error code. It seemed like passing the CAP_SYS_RESOURCE should work here? Nothing I've tried here has changed the value for msgmnb in the container. I can't seem to find documentation on how to achieve my goal. I'd appreciate any help - thank you! EDIT: Trying to determine if the process calling msgctl has the capability. Here is what I found:

$ cat /proc/6211/status | grep -i Cap
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000fdecafff
CapAmb: 0000000000000000
$ capsh --decode=00000000fdecafff
0x00000000fdecafff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_raw,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap

capsh --caps is documented in --help as, --caps=xxx set caps as per cap_from_text() What is the right syntax here? Can anyone demonstrate this working?

I'm trying to make my RPi3 to be a bluetooth sink. My problem is that when I'm trying to connect my Windows 7 Laptop to my RPi Bluetooth sink, it is displayed like that : Sorry, it's in french. It allows to create 3 connections : * one for the Rpi to be connected as a microphone * one for the Rpi to connected as headphone (option that I only want) * one the Rpi to be a audio file server **The info :** $ sudo bluetoothctl [bluetooth]# show Controller B8:27:EB:XX:XX:XX Name: Gertrude Alias: Gertrude Class: 0x20041c Powered: yes Discoverable: yes Pairable: yes UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d052B Discovering: no The Bluetooth config file: $ cat /etc/bluetooth/main.conf [General] # Default adapter name # Defaults to 'BlueZ X.YZ' #Name = BlueZ # Default device class. Only the major and minor device class bits are Name = # considered. Defaults to '0x000000'. #Class = 0x000100 Class = 0x20041c # How long to stay in discoverable mode before going back to non-discoverable # The value is in seconds. Default is 180, i.e. 3 minutes. # 0 = disable timer, i.e. stay discoverable forever DiscoverableTimeout = 0 # How long to stay in pairable mode before going back to non-discoverable # The value is in seconds. Default is 0. # 0 = disable timer, i.e. stay pairable forever #PairableTimeout = 0 # Automatic connection for bonded devices driven by platform/user events. # If a platform plugin uses this mechanism, automatic connections will be # enabled during the interval defined below. Initially, this feature # intends to be used to establish connections to ATT channels. Default is 60. #AutoConnectTimeout = 60 # Use vendor id source (assigner), vendor, product and version information for # DID profile support. The values are separated by ":" and assigner, VID, PID # and version. # Possible vendor id source values: bluetooth, usb (defaults to usb) #DeviceID = bluetooth:1234:5678:abcd # Do reverse service discovery for previously unknown devices that connect to # us. This option is really only needed for qualification since the BITE tester # doesn't like us doing reverse SDP for some test cases (though there could in # theory be other useful purposes for this too). Defaults to 'true'. #ReverseServiceDiscovery = true # Enable name resolving after inquiry. Set it to 'false' if you don't need # remote devices name and want shorter discovery cycle. Defaults to 'true'. #NameResolving = true # Enable runtime persistency of debug link keys. Default is false which # makes debug link keys valid only for the duration of the connection # that they were created for. #DebugKeys = false # Restricts all controllers to the specified transport. Default value # is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW). # Possible values: "dual", "bredr", "le" #ControllerMode = dual # Enables Multi Profile Specification support. This allows to specify if # system supports only Multiple Profiles Single Device (MPSD) configuration # or both Multiple Profiles Single Device (MPSD) and Multiple Profiles Multiple # Devices (MPMD) configurations. # Possible values: "off", "single", "multiple" #MultiProfile = off # Permanently enables the Fast Connectable setting for adapters that # support it. When enabled other devices can connect faster to us, # however the tradeoff is increased power consumptions. This feature # will fully work only on kernel version 4.1 and newer. Defaults to # 'false'. #FastConnectable = false # Default privacy setting. # Enables use of private address. # Possible values: "off", "device", "network" # "network" option not supported currently # Defaults to "off" # Privacy = off [Policy] # # The ReconnectUUIDs defines the set of remote services that should try # to be reconnected to in case of a link loss (link supervision # timeout). The policy plugin should contain a sane set of values by # default, but this list can be overridden here. By setting the list to # empty the reconnection feature gets disabled. #ReconnectUUIDs=00001112-0000-1000-8000-00805f9b34fb,0000111f-0000-1000-8000-00805f9b34fb,0000110a-0000-1000-8000-00805f9b34fb # ReconnectAttempts define the number of attempts to reconnect after a link # lost. Setting the value to 0 disables reconnecting feature. #ReconnectAttempts=7 # ReconnectIntervals define the set of intervals in seconds to use in between # attempts. # If the number of attempts defined in ReconnectAttempts is bigger than the # set of intervals the last interval is repeated until the last attempt. #ReconnectIntervals=1,2,4,8,16,32,64 # AutoEnable defines option to enable all controllers when they are found. # This includes adapters present on start as well as adapters that are plugged # in later on. Defaults to 'false'. AutoEnable=true I have changed the Bluetooth class thanks to : , remove and add again the "*Windows Bluetooth device*", but it has no effect. So I noticed that the bluetoothctl / show command shows UUID capabilities, corresponding to some features that I don't want. 0000110a-0000-1000-8000-00805f9b34fb : Audio Source 00001800-0000-1000-8000-00805f9b34fb : Generic Access 00001801-0000-1000-8000-00805f9b34fb : Generic Attribute But I have absolutely no idea how to disabled these features. Any ideas?

This command:

sudo chown -R root:root directory

will remove the SUID bit and reset all capabilities for *files*. I wonder why it's done silently and it's not mentioned in the man page. Weirdly the GUID bit is not removed. And it doesn't matter who the file or directory belonged to prior to running this command. Also SUID/GUID bits are *not* removed for *directories* (thought they are useless in this case). Presumably it's done in the name of security but to me it must not be done silently. This gets even worse:

$ setcap cap_sys_rawio,cap_sys_nice=+ep test
$ getcap -v test 
test cap_sys_rawio,cap_sys_nice=ep

$ chown -c -v -R 0:0 .
ownership of './test' retained as root:root
ownership of '.' retained as root:root

$  getcap -v test 
test

The SUID bit for the test file is removed completely silently. It's as if the command is doing a lot more than requested.

I am working on an embedded system device which basically has root user. I have a systemd service call.service which works fine with root access. The service basically creates a few sockets and then interacts with the network device. I want to launch this service with user UserA, and capabilities like net_raw and net_admin. I have written the following unit file:

file: /etc/systemd/system/multi-user.target.wants/call.service

[Unit]
Description=XXX call service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=userA
Group=userA
ExecStart=/opt/call/bin/call eth0 -P -1
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
ExecStartPre=/bin/mkdir -p /tmp/call
ExecStartPre=/bin/chmod -R 755 /tmp/call
ExecStopPost=/bin/rm -rf /tmp/call

[Install]
WantedBy=multi-user.target

However, when I launch this service, the service fails with an error stating that during socket creation "Operation Not Permitted".

$ systemctl restart call

Dec 01 17:56:10 xxxx call: ERROR    : CALL [17:56:10:682] socket creation failed: Operation not permitted

Corresponding src file for the error:

//file call.cpp
net_iface_l->sd_general = socket( PF_PACKET, SOCK_DGRAM, 0 );
	if( net_iface_l->sd_general == -1 ) {
		LOG_ERROR( "socket creation failed: %s", strerror(errno));
		return false;
	}

Can someone point out, if there is a mistake in the user creation or capabilities defined? May be something is missing in terms of the user permissions here, which I am unable to understand.

Is it at all possible to execute the iptables --list … command without being root? Running it as non-root prints this: $ iptables --list iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded. If you must be root to list iptables, what is the reasoning behind that?  Is there a security concern with viewing the rules?  Is there a resource or service used by iptables --list that requires root access? Obviously, modifying iptables firewall rules requires privileges.  I am asking about viewing them. ---------------- Instead of being root, is there a capability that could permit listing the rules?  Does iptables use netlink to interface with the kernel?  Because netlink(7) mentions that > Only processes with an effective UID of 0 or the **CAP_NET_ADMIN** > capability may send or listen to a netlink multicast group. Maybe that does not apply to iptables. I am not sure whether this is the right way of doing it, but adding a capability to iptables does not let me list the rules, either: bash-4.1$ echo $UID 2000 bash-4.1$ getcap /sbin/iptables-multi-1.4.7 /sbin/iptables-multi-1.4.7 = cap_net_admin+ep bash-4.1$ /sbin/iptables-multi-1.4.7 main --list FATAL: Could not load /lib/modules/3.10.0-514.21.1.el7.x86_64/modules.dep: No such file or directory iptables v1.4.7: can't initialize iptables table `filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded. ------------ Here are some relevant questions: - iptables – add rules not as root     (Super User) - Using iptables without root privileges  (Server Fault) Both provide workarounds, in my opinion, and do not discuss the fundamental reason behind the restriction.

### Question I'm doing my internship, working on container security and recently I need to build a container which has security problem to do some tests. Here is my dockerfile FROM dockerfiles/centos-lamp WORKDIR /var/www/html RUN wget https://github.com/RandomStorm/DVWA/archive/v1.0.8.tar.gz -O- | tar xvz --strip-components=1 RUN service mysqld start && mysqladmin -uroot password p@ssw0rd && service mysqld stop EXPOSE 80 USER root COPY ./Centos-vault-6.10.repo /home COPY ./here_u_r.txt /root WORKDIR /home RUN rm -rf /etc/yum.repos.d/* RUN cp -r ./Centos-vault-6.10.repo /etc/yum.repos.d/CentOS-Base.repo RUN yum clean all RUN yum makecache RUN cp /bin/tar . WORKDIR /var/www/html RUN rpm --rebuilddb && yum install -y sudo && yum install -y gcc RUN usermod -aG wheel apache && \ chmod u+s $(which find) && \ chmod 700 $(which getcap) && \ setcap 'cap_dac_read_search=ep' /home/tar CMD ["supervisord", "-n"] You can see, in the penultimate line, I want to give the tar executable in the /home directory the capability in order to read files. But I got an error when I used the tar file to zip something. Can someone give me a hand? PS: I don't understand why when I check the capability of this file, I get **cap_dac_read_search+ep**, either. I didn't use setcap 'cap_dac_read_search+ep' /home/tar, but setcap **'cap_dac_read_search=ep'** /home/tar. ### Actions in my shell + returned results bash-4.1$ ls -la /home/tar ls -la /home/tar -rwxr-xr-x. 1 root root 390616 Aug 24 22:56 /home/tar bash-4.1$ find 1 -exec getcap /home/tar \; find 1 -exec getcap /home/tar \; /home/tar = cap_dac_read_search+ep bash-4.1$ pwd pwd /home bash-4.1$ ./tar -cvf /tmp/my.tar /tmp/1 /tmp/pip-build-root ./tar -cvf /tmp/my.tar /tmp/1 /tmp/pip-build-root bash: ./tar: Operation not permitted

I'm trying understand AppArmor capabilities at the moment. I found an example which had me make a copy of /bin/ping and generate AppArmor profile for it. First I made a copy of /bin/ping and set it's net_raw capability to permitted and effective per the instructions:

-shell
sudo cp /bin/ping /bin/fake_ping
sudo setcap cap_net_raw+ep  /bin/fake_ping

Then I generated an AppArmor profile:

-shell
sudo aa-genprof /bin/fake_ping

The AppArmor profile is saved in enforced - everything works. After that I unset net_raw capability:

-shell
sudo setcap cap_net_raw-ep  /bin/fake_ping

As expected, it doesn't work now due to this missing capability:

fake_ping: socktype: SOCK_RAW
fake_ping: socket: Operation not permitted
fake_ping: => missing cap_net_raw+p capability or setuid?

----------- **My question:** newly generated apparmor profile already contains capability net_raw, so why it doesn't work without cap_net_raw=ep set in extended attributes? How it's different?