Re: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
Control: severity -1 minor
Guten Abend Christian, hi again everyone!
(some AppArmor stuff first, then a question for the CUPS folks)
Christian Boltz:
> My guess is that John meant something like that:
> /etc/cups/** Cx -> trap,
> profile trap {
> # intentionally left empty
> }
Ah, got it now, thanks!
If this can somehow be combined with the rule we already have:
/etc/cups/** rw
… then I think this would be a suitable short-term workaround.
Jamie, IIRC you're one of the people regularly working on this
profile, how does this sound?
Finally, I would like to question the need for cupsd to have write
access to a world-readable directory, which is, as I understand it,
the root cause of the problem (once you assume it has to run as root
in the first place). I guess cupsd needs write access because it saves
config files there when one uses the web interface, and then by Debian
convention /etc/cups is world-readable. But perhaps one of these could
change, e.g. does /etc/cups really have to be world-readable?
Cheers,
--
intrigeri
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
Hello,
Am Sonntag, 27. Januar 2019, 15:01:40 CET schrieb intrigeri:
> John Johansen:
> > 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.
> > [...]
> > short term: confine users & a trap profile(s) on the /etc/cups dir
>
> I was not able to find any reference to the "trap profile" idea
> in our documentation. Could you please point me in the right
> direction? Thanks in advance!
My guess is that John meant something like that:
/etc/cups/** Cx -> trap,
profile trap {
# intentionally left empty
}
Regards,
Christian Boltz
--
Seriously? If you accused me of verbally abusing the _feature_
(or rather its implementation), I would understand. But I'm not
aware of verbally abusing _people_ (or at least not here, but I
hope you don't really have a microphone near my desk).
[Michal Kubecek in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
Hi John & others, John Johansen: > 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. > [...] > short term: confine users & a trap profile(s) on the /etc/cups dir I was not able to find any reference to the "trap profile" idea in our documentation. Could you please point me in the right direction? Thanks in advance! Cheers, -- intrigeri -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [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 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. 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. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
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
