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!