Bug#980974: apparmor blocks cups backend outgoing network connections

[Chris Bainbridge]

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?

[Brian Potkin]

user pkg-appa...@lists.alioth.debian.org
usertags #980974 help-needed
thanks

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/

[intrigeri]

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!

[Paul Rubin]

My printer wouldn't work and I eventually found the aacomplain
workaround in the ubuntu printer debugging docs:

https://wiki.ubuntu.com/DebuggingPrintingProblems#AppArmor_Protection_of_the_printing_system

It really should be fixed.  I looked at /etc/apparmor.d/cupsd and there
is quite a lot of stuff in there about cups-pdf that looked confusing to
mess with.  Aacomplain at least allowed me to print, so I would say if
nobody has a fix then apparmor for cups should be disabled by default
until a proper fix is worked out. Otherwise it's a big regression,
suddenly becoming unable to print stuff.  It ended up causing me
significant inconvenience because I needed the printout for something
that I wanted to do today, that will now have to wait til tomorrow. 
Fortunately this wasn't last-minute tax forms or I'd be in trouble :(

[Brian Potkin]

On Mon 25 Jan 2021 at 23:21:20 +0000, 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.

[Christian Boltz]

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]

[Brian Potkin]

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.

[Christian Göttsche]

auditd shows the capability check is caused by setsockopt(2) with
option SO_SNDBUFFORCE:

type=AVC msg=audit(1662998083.773:76): apparmor="DENIED"
operation="capable" profile="/usr/sbin/cupsd" pid=955 comm="cupsd"
capability=12 capname="net_admin"
type=SYSCALL msg=audit(1662998083.773:76): arch=c000003e syscall=54
success=no exit=-1 a0=c a1=1 a2=20 a3=7ffffab6b404 items=0 ppid=1
pid=955 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cupsd"
exe="/usr/sbin/cu
psd" subj=/usr/sbin/cupsd (enforce) key=(null) ARCH=x86_64
SYSCALL=setsockopt AUID="unset" UID="root" GID="root" EUID="root"
SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=PROCTITLE msg=audit(1662998083.773:76):
proctitle=2F7573722F7362696E2F6375707364002D6C

Possible cause might be a call to libsystemd (see fd_inc_sndbuf()).

[Jörg Sommer]

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<socket:[1138186]>, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) <0.000020>
> /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)

[Ivan Golović]

Same problem here on Debian 11, will try the workaround and hope for the best. Huge time waste and disappointment though.. :/