.deb packages do not support capabilties(7)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
debhelper (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
There are strong reasons to not run processes with full root privileges, and much work has been done to eliminate setuid executables from the distros.
One tool in the toolbox for more secure processes is capabilities(7), which was defined in the (now withdrawn) POSIX 1003.1e draft standard (http://
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://
deb packages should similarly support a way to specify that capabilities be set on delivered files, to encourage the adoption of more secure practices on Debian systems.
Most daemons currently running as root do not require full root privileges, and would be more secure running at low privilege with specifically-
information type: | Private Security → Public |
description: | updated |
affects: | software-center (Ubuntu) → dh-make |
affects: | dh-make → dh-make (Ubuntu) |
affects: | dh-make (Ubuntu) → debhelper (Ubuntu) |
description: | updated |
description: | updated |
Changed in debhelper (Ubuntu): | |
status: | New → Confirmed |
This is likely better done in Debian.
That said, dpkg-statoverride seems like a possible layer to extend. It is responsible for updating the owner and permission of files installed by packages, after all. Extending it to deal with capabilities, or for that matter POSIX ACLs and Linux extended attributes would make sense.
One could then extend debhelper to make its usage more packager-friendly, if a dh_statoverride module doesn't exit already.
Until we get that, most packages will do it like iputils-ping does (refer to its postinst script).