Bug#977813: Bug#980974: apparmor blocks cups backend outgoing network connections
Christian Boltz schrieb am Wed 17. Aug, 20:47 (+0200): > Hello, > > denials for capabilty net_admin are often a sign that a service uses > systemd libraries on startup, and these systemd libraries do funny[tm] > things. In these cases the net_admin capability is not really needed. Hi, yes, you are right. Systemd is the culprit. This is the call leading to the audit message: ``` text 81641 09:05:48.607647 setsockopt(12, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) <0.20> > /usr/lib/x86_64-linux-gnu/libc.so.6(setsockopt+0xa) [0x10b59a] > /usr/lib/x86_64-linux-gnu/libsystemd.so.0.34.0(sd_machine_get_ifindices+0x104c1) > [0x90ec1] > /usr/lib/x86_64-linux-gnu/libsystemd.so.0.34.0(sd_pid_notify_with_fds+0x1ae) > [0x6ebfe] > /usr/lib/x86_64-linux-gnu/libsystemd.so.0.34.0(sd_notifyf+0xd8) [0x6f328] > /usr/sbin/cupsd() [0xc130] > /usr/lib/x86_64-linux-gnu/libc.so.6(__libc_init_first+0x8a) [0x2920a] > /usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x7c) [0x292bc] > /usr/sbin/cupsd() [0xd5c1] ``` Hence, it should be okay to deny the access. I've added the line `deny capability net_admin,` and cups works and the audit message is gone. Regards Jörg -- „Gesundheit ist dasjenige Maß an Krankheit, das es mir noch erlaubt, meinen wesentlichen Beschäftigungen nachzugehen.“ (Friedrich Nietzsche) signature.asc Description: PGP signature
Bug#980974: apparmor blocks cups backend outgoing network connections
On Wed 17 Aug 2022 at 20:47:24 +0200, Christian Boltz wrote: > Hello, > > denials for capabilty net_admin are often a sign that a service uses > systemd libraries on startup, and these systemd libraries do funny[tm] > things. In these cases the net_admin capability is not really needed. > > See https://bugzilla.opensuse.org/show_bug.cgi?id=1196850#c3 for the > technical details. (Yes, I'm aware that this bugreport is for Samba, not > cups - but I'm somewhat sure that cups uses the same systemd libraries > on startup.) > > I have to admit that I'm only a cups user, but I'd be surprised if it > really needs capability net_admin. In capabilities(7) network-related operations for CAP_NET_ADMIN include bind to any address for transparent proxying; enabling multicasting; I am not sue these are the relevant operations in this case but I am suue that Debian 11 introduced ipp-usb as a recommended package for cups-daemon. ipp-usb effectively implements a HTTP reverse proxy: https://github.com/OpenPrinting/ipp-usb Twp clues? Putting them together I purged ipp-usb and the deniel for capabilty net_admin disappears from the journal when cups is restarted. Perhaps this could be tested by others? > To find out if it's really needed or just "systemd noise", can you please > explicitely deny net_admin and test if printing still works? To do this, > add > deny capability net_admin, > to /etc/apparmor.d/local/usr.sbin.cupsd This will a) deny it and b) > silence the logging. Then reload the profile with > systemctl reload apparmor > > I'd also recommend to > aa-enforce cupsd > (in theory deny rules get enforced even in complain mode, but better > safe than sorry) > > > If printing doesn't work with the deny rule added, please try if it > works if you allow the capability: > capability net_admin, > (and remove the deny rule). I don't notice any degradation in printing to printers over the network. USB printing (using IPP-over-USB) wasn't tested, but has always worked for me in the past. My tentative conclusion is that cupsd's desire to access capabilty net_admin is legitimate. OTOH, denying it doesn't appear to affect my printing here, but more testing is needed Cheers, Brian.
Bug#980974: apparmor blocks cups backend outgoing network connections
Hello, denials for capabilty net_admin are often a sign that a service uses systemd libraries on startup, and these systemd libraries do funny[tm] things. In these cases the net_admin capability is not really needed. See https://bugzilla.opensuse.org/show_bug.cgi?id=1196850#c3 for the technical details. (Yes, I'm aware that this bugreport is for Samba, not cups - but I'm somewhat sure that cups uses the same systemd libraries on startup.) I have to admit that I'm only a cups user, but I'd be surprised if it really needs capability net_admin. To find out if it's really needed or just "systemd noise", can you please explicitely deny net_admin and test if printing still works? To do this, add deny capability net_admin, to /etc/apparmor.d/local/usr.sbin.cupsd This will a) deny it and b) silence the logging. Then reload the profile with systemctl reload apparmor I'd also recommend to aa-enforce cupsd (in theory deny rules get enforced even in complain mode, but better safe than sorry) If printing doesn't work with the deny rule added, please try if it works if you allow the capability: capability net_admin, (and remove the deny rule). Note, since this bug includes two different AppArmor denials: capability sys_nice, for cups-browsed is unrelated to what I wrote above. Please don't change your cups-browsed profile (= keep it in complain mode) while testing the deny rule in the cupsd profile. Regards, Christian Boltz -- > check up on dusted up coolers / vents etc. That is the first thing that I did, but I can't imagine that the amount of dust is automatically changing with the kernel ? [> David Haller and Raymond Wooninck in opensuse-factory]
Bug#980974: apparmor blocks cups backend outgoing network connections
On Mon 25 Jan 2021 at 23:21:20 +, Brian Potkin wrote: [...] > Triaging this report, Chris, but my knowledge of apparmor is very > limited. However, I have a minimal unstable installation (base > system plus only cups) and can reproduce this behaviour. The last > line (but not the first) disappears when cups-browsed is purged. JFTR. Regarding the apparmor profile and cups-browsed, there is Ubuntu bug #1897369: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1897369 Till Kamppeter (the author of cups-browsed) says I did not have anything to control the priority in the source code of cups-browsed, I also did not find anything in the packaging of cups-filters. I also do not see any security risk in priority changing, it can only make the system faster or slower. Then there is Debian bug #1016622: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016622 which basically says - don't worry about it. Perhaps it could be the same situation for cupsd. Cheers, Brian.
Bug#980974: apparmor blocks cups backend outgoing network connections
Hi, Brian Potkin (2021-01-25): >> Jan 23 23:39:29 debian kernel: audit: type=1400 audit(1611445169.589:22): >> apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172 >> comm="cupsd" capability=12> If cupsd legitimately needs to use the CAP_NET_ADMIN Linux [capability], then adding this line to /etc/apparmor.d/usr.sbin.cupsd should fix it: capability net_admin, >> Jan 23 23:39:29 debian audit[2174]: AVC apparmor="DENIED" >> operation="capable" profile="/usr/sbin/cups-browsed" pid=2174 >> comm="cups-browsed" capability=23 capname="sys_nice" If cups-browsed legitimately needs to use the CAP_SYS_NICE Linux [capability], then adding this line to /etc/apparmor.d/usr.sbin.cups-browsed should fix it: capability sys_nice, In both cases, I don't know enough about how the CUPS software works to evaluate whether accepting this by default is desirable. In particular, I have never heard of "TCP connections from cupsd to backend driver" before :) It's a usability/security trade-off and I suppose it depends on how common the affected use case is: quite often, AppArmor policy can't reasonably support every single uncommon use case, as doing so would result in a mostly useless policy, while the vast majority of users would benefit from a stricter policy. If it feels like a safer default config to block such connections by default, then either we can keep things as-is, or silence the denial in the logs by adding the same lines prefixed with "deny "… at the cost of making it harder to debug and customize for folks who really need this. [capability] capabilities(7) Hoping it helps, cheers!
Bug#980974: apparmor blocks cups backend outgoing network connections
user pkg-apparmor-t...@lists.alioth.debian.org usertags #980974 help-needed thanks On Sun 24 Jan 2021 at 22:53:00 +, Chris Bainbridge wrote: > Package: cups > Version: 2.3.3op1-7 > > After upgrading to bullseye, TCP connections from cupsd to localhost > appeared to be blocked: > > Jan 23 23:39:29 debian audit[2172]: AVC apparmor="DENIED" > operation="capable" profile="/usr/sbin/cupsd" pid=2172 comm="cupsd" > capability=12 capname="net_admin" > Jan 23 23:39:29 debian systemd[1]: Started CUPS Scheduler. > Jan 23 23:39:29 debian kernel: kauditd_printk_skb: 10 callbacks suppressed > Jan 23 23:39:29 debian kernel: audit: type=1400 audit(1611445169.589:22): > apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172 > comm="cupsd" capability=12> > Jan 23 23:39:29 debian systemd[1]: Started Make remote CUPS printers > available locally. > Jan 23 23:39:29 debian audit[2174]: AVC apparmor="DENIED" > operation="capable" profile="/usr/sbin/cups-browsed" pid=2174 > comm="cups-browsed" capability=23 capname="sys_nice" > > I worked around this with `aa-complain cupsd`, `aa-complain cups-browsed`, > but I would guess that this should work without modifications, unless this > (TCP connections from cupsd to backend driver) is considered non-standard > usage? Triaging this report, Chris, but my knowledge of apparmor is very limited. However, I have a minimal unstable installation (base system plus only cups) and can reproduce this behaviour. The last line (but not the first) disappears when cups-browsed is purged. Regards, Brian/
Bug#980974: apparmor blocks cups backend outgoing network connections
Package: cups Version: 2.3.3op1-7 After upgrading to bullseye, TCP connections from cupsd to localhost appeared to be blocked: Jan 23 23:39:29 debian audit[2172]: AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172 comm="cupsd" capability=12 capname="net_admin" Jan 23 23:39:29 debian systemd[1]: Started CUPS Scheduler. Jan 23 23:39:29 debian kernel: kauditd_printk_skb: 10 callbacks suppressed Jan 23 23:39:29 debian kernel: audit: type=1400 audit(1611445169.589:22): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172 comm="cupsd" capability=12> Jan 23 23:39:29 debian systemd[1]: Started Make remote CUPS printers available locally. Jan 23 23:39:29 debian audit[2174]: AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=2174 comm="cups-browsed" capability=23 capname="sys_nice" I worked around this with `aa-complain cupsd`, `aa-complain cups-browsed`, but I would guess that this should work without modifications, unless this (TCP connections from cupsd to backend driver) is considered non-standard usage?
