Hardening the "file" utility for Debian

Posted Aug 15, 2019 17:01 UTC (Thu) by rwmj (subscriber, #5474)
In reply to: Hardening the "file" utility for Debian by zblaxell
Parent article: Hardening the "file" utility for Debian

I'm also inclined to think fakeroot is the root cause of the problem here, rather than file or seccomp. Other distros manage to package broadly the same set of packages as Debian and they don't use fakeroot. Instead the package builder uses a combination of DESTDIR and added metadata marking the desired ownership and permission on installed files.

Hardening the "file" utility for Debian

Posted Aug 15, 2019 18:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Indeed. How do Go programs (which don't call libc) expect to be affected by `fakeroot`?

Hardening the "file" utility for Debian

Posted Aug 16, 2019 7:06 UTC (Fri) by smcv (subscriber, #53363) [Link]

Yes, fakeroot is the problem here, and Debian is moving away from it. Packages with the "Rules-Requires-Root: no" field are built without fakeroot or similar tricks, which works for packages where every file in the .deb is owned by root:root (including those that use dpkg-statoverride to chown a file during installation, like dbus). This is opt-in because it's potentially a backwards-incompatible change.

My understanding is that for the minority of packages that contain files with different ownership (for example audit and shadow), there are plans for some sort of declarative file-ownership metadata (analogous to RPM does it), but that isn't available yet.