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 deb...@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 -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor