Bug#914370: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
On 12/16/18 6:05 AM, intrigeri wrote:
> 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.
This is a known issue with unconfined. I can say there are some changes
coming that will help. With the setuid issue, and also with creating
the setuid binaries.
1. profile attachments are going to gain additional ability around
setuid. So it will be possible to create policy that can trap these
type of execs.
2. policy will be picking up extended permission allowing it to control
the creation of setuid/setguid files etc, so the cups profile will be
able to block the creation of these files.
I can't give a time line for when these will land but I can say they
won't make 4.21
>
> 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.
>
Indeed. AppArmor in its current form is not well suited to total system
confinement. It can be done but there are limitations. Instead policy
has focused on application confinement/sandboxing.
If a local user is not trusted they should not be unconfined,
unconfined was designed specifically so that apparmor would not alter
standard system behavior for the unconfined application. It is
possible to confine users (though harder than it should be atm) and
still have application confinement
However as intrigeri points out sharing at wrietable locations is
currently problematic and one of the missing pieces that we need to
land before apparmor can be effectively used
>> @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).
>
Policy can be adjusted to include trap profiles that will attach
to binaries executed out of these directories. The trap profile
can grant limited to no permissions.
> 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?
>
short term: confine users & a trap profile(s) on the /etc/cups dir
long term: apparmor will pickup permissions to control setuid/setguid
both at the file creation level and at the profile
attachment level.
Reply to: