Eduard Bloch wrote (28 Dec 2013 10:55:59 GMT) :
> Well, I just realized that the code around this behaves wrong in corner
> cases, I will make a minor revision anyhow. Please apply the patch from
> the attachment to your postinst file.
I confirm that this patch does workaround the problem for me, thanks!
> PRINTCFGVAR=CacheDir strace /usr/sbin/apt-cacher-ng -c /etc/apt-cacher-ng
It ends like this:
open("/etc/apt-cacher-ng/security.conf", O_RDONLY) = -1 EACCES (Permission
denied)
write(2, "Error opening file", 18Error opening file) = 18
write(2, ", terminating.", 14, terminating.) = 14
write(2, "\n", 1
) = 1
exit_group(1) = ?
# ls -l /etc/apt-cacher-ng/security.conf
-rw------- 1 apt-cacher-ng apt-cacher-ng 401 Jul 27 2008
/etc/apt-cacher-ng/security.conf
# ls -ld /etc/apt-cacher-ng/
drwxr-xr-x 2 root root 4096 Dec 20 13:06 /etc/apt-cacher-ng/
... and then I realized that my AppArmor policy caused the problem:
apparmor="DENIED" operation="capable" parent=29220
profile="/usr/sbin/apt-cacher-ng" pid=29221 comm="apt-cacher-ng"
pid=29221 comm="apt-cacher-ng" capability=1 capname="dac_override"
... and the problem vanishes if I disable the relevant AppArmor
profile.
But, the underlying problem discovered by AppArmor is still there:
a root process loads a file writable by another user; if it then
parses this file, it had better do it in a *very* defensive way, as
any bug in the parser might lead to root escalation for the
apt-cacher-ng user.
Making security.conf permissions stricter (root:apt-cacher-ng,
640) makes my AppArmor profile happy again.
Does the apt-cacher-ng user actually need write access to this file?
If it doesn't, I think a bit of security in depth would be in
order there. What do you think?
Regards,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
