| 2014-09-19 16:52:41 |
BobD |
bug |
|
|
added bug |
| 2014-09-19 16:53:03 |
BobD |
information type |
Private Security |
Public |
|
| 2014-09-19 16:56:54 |
BobD |
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 quiver for more secure processes is capabilities(7), which was defined in the (now withdrawn) POSIX 1e draft standard (http://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
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-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also enhance security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices. |
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 1e draft standard (http://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
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-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also enhance security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices. |
|
| 2014-09-19 17:00:20 |
BobD |
affects |
software-center (Ubuntu) |
dh-make |
|
| 2014-09-19 17:06:14 |
BobD |
affects |
dh-make |
dh-make (Ubuntu) |
|
| 2014-09-19 17:45:19 |
Filip Sohajek |
affects |
dh-make (Ubuntu) |
debhelper (Ubuntu) |
|
| 2014-09-19 19:33:55 |
BobD |
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 1e draft standard (http://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
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-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also enhance security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices. |
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://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
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-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also enhance security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices. |
|
| 2014-09-19 19:35:03 |
BobD |
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://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
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-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also enhance security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices. |
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://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
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-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also ease security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices. |
|
| 2014-09-20 19:06:43 |
Filip Sohajek |
debhelper (Ubuntu): status |
New |
Confirmed |
|
