search

USBGuard / usbguard

USBGuard is a software framework for implementing USB device authorization policies (what kind of USB devices are authorized) as well as method of use policies (how a USB device may interact with the system)
https://usbguard.github.io/
GNU General Public License v2.0
1.11k stars 134 forks source link

ERROR: IPC connect: service=usbguard: Permission denied since kernel 5.0.9 #287

Open morfikov opened 5 years ago

morfikov commented 5 years ago

I just upgraded my kernel to the latest stable (5.0.7->5.0.9) and I notticed that usbguard-applet-qt has a gray icon. In it's log I can see the following messages:

[Sat Apr 20 14:55:21 2019] Connection failed: IPC connect: service=usbguard: Permission denied
[Sat Apr 20 14:55:22 2019] Connection failed: IPC connect: service=usbguard: Permission denied
[Sat Apr 20 14:55:23 2019] Connection failed: IPC connect: service=usbguard: Permission denied

Also I'm using AppArmor profiles for all the usbguard execs, and I had to add to usr.sbin.usbguard-daemon and usr.sbin.usbguard-dbus profiles the following rules:

 /dev/shm/ r,
 /dev/shm/qb-[0-9]*-[0-9]*-[0-9]*-*/ rw,
 /dev/shm/qb-[0-9]*-[0-9]*-[0-9]*-*/qb-{request,response,event}-usbguard-{header,data} rw,

There was similar rule to the last one:

/dev/shm/qb-usbguard-{request,response,event}-[0-9]*-[0-9]*-[0-9]*-{header,data} rw,

and probably the change causes the problem.

morfikov commented 5 years ago

It looks like the systemd service causes the problem.

When I commented out the following line: CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER It works well now. It's weird...

morfikov commented 5 years ago

I had to add two extra CAPs:

CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE.

Now it works well.

tweksteen commented 4 years ago

Re-opening this issue as the necessary changes may not have been committed. This was pulled in the Debian package (https://salsa.debian.org/bisco-guest/usbguard/commit/492e3a38ae0bce192fca926e1eedc0e71dbdb5a2), but I'm not sure these are necessary (and potentially dangerous).

Any chance you could share the version of systemd that you were using? Thanks.

morfikov commented 4 years ago

See #289 . 

#  systemd --version
systemd 242 (242)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
+PCRE2 default-hierarchy=hybrid

I'm using Debian Sid.

drGrove commented 4 years ago

Seeing the same thing in Linux Kernel 5.3.8 (Arch Linux) with Systemd 242

cyrinux commented 4 years ago

I think there is some more capabilities missing to be able to write on the /etc/usbguard/rules.conf

aagor commented 4 years ago

@cyrinux yes, you must allow writing to your rules.conf file.

A quick fix is to place this file at /etc/systemd/system/usbguard.service.d/override.conf:

[Service]
CapabilityBoundingSet=CAP_DAC_OVERRIDE
ReadWritePaths=-/etc/usbguard/rules.conf

But ideally, this should be fixed upstream.

genodeftest commented 4 years ago

@alcros wrote:

[Service]
CapabilityBoundingSet=CAP_DAC_OVERRIDE
ReadWritePaths=-/etc/usbguard/rules.conf

The latter is already in the usbguard.service file: https://github.com/USBGuard/usbguard/blob/master/usbguard.service.in#L24 (fffd3d3fc16ff3426e95350b061a44f0ce02d3c7)

diabonas commented 4 years ago

Regarding the necessary CAP_DAC_OVERRIDE capability, see #289 for more information and an alternative to adding this potentially dangerous capability.