Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc

[intrigeri <intrigeri@debian.org>]

Hi,

(+ AppArmor upstream mailing list as I don't feel sufficiently
knowledgeable to provide authoritative answers or guidance)

Didier 'OdyX' Raboud:
> Le jeudi, 22 novembre 2018, 19.05:19 h CET debbug@dbwats.plus.com a écrit :
>> The AppArmor profile supplied with cupsd isn't much use against local
>> attackers, as it allows cupsd to create setuid binaries at paths it
>> can write to (e.g. under /etc/cups).  Since cupsd is run as root by
>> default, these binaries can be setuid root.
>> 
>> (…)
>> 
>> In default installations /etc is not on a nosuid mount, so provided
>> that they have a suitable exploit, local attackers who are unconfined
>> but non-root can use cupsd to create a setuid binary, then run the
>> binary themselves to gain unconfined root privileges.

Right. AppArmor does a decent job at sandboxing individual processes
but it offers little protection against a group of processes, running
under different policies, that cooperate to escape their sandbox or
otherwise escalate their privileges. The shared bits of a Linux system
that various processes can access are simply too many to write
AppArmor policy that successfully protects against such attacks
without using other isolation techniques. This bug report exemplifies
this, one of these cooperating processes here being mostly unconfined
(local user with arbitrary code execution as non-root) while the other
runs as root under a rather loose AppArmor policy.

> @Intri: any insight in how to address this?

First, sorry for the delay, I've had less time than usual for Debian
recently. Thankfully I'm now back! :)

tl;dr: AFAICT this is a known AppArmor limitation and there's nothing
we can do about it as long as cupsd runs as root (I assume we would
already be running it under a non-privileged user if that was easily
doable).

There's no fine-grained enough Linux capability to fix this and
there's nothing in the AppArmor policy language to express "not
allowed to give files the setuid/setgid bits". I don't know if the
existing LSM hooks are sufficient for AppArmor to add such support
both in the kernel and in the policy language. But even if that
specific instance of the "groups of processes can cooperate to
escalate privileges" was fixed, the broader problem would remain.
AppArmor folks, can you confirm and maybe shed some light upon what
options we have here, both short and long term?

Cheers,
-- 
intrigeri