Bug#980974: apparmor blocks cups backend outgoing network connections

[intrigeri <intrigeri@debian.org>]

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!