No edit summary |
(reference grsecurity post) |
||
| Line 24: | Line 24: | ||
It would be nice to have a clarification about the case where a machine has SELinux disabled or it uses some filesystem that does not support capabilities.--[[User:Amcnabb|Amcnabb]] 17:33, 1 November 2010 (UTC) | It would be nice to have a clarification about the case where a machine has SELinux disabled or it uses some filesystem that does not support capabilities.--[[User:Amcnabb|Amcnabb]] 17:33, 1 November 2010 (UTC) | ||
---- | |||
There are a number of points raised about this feature mentioned here: http://permalink.gmane.org/gmane.comp.security.oss.general/3719 --[[User:davej|davej]] 22:28, 8 Nov 2010 (UTC) | There are a number of points raised about this feature mentioned here: http://permalink.gmane.org/gmane.comp.security.oss.general/3719 --[[User:davej|davej]] 22:28, 8 Nov 2010 (UTC) | ||
| Line 33: | Line 33: | ||
*Does this remove our ability to disable SELinux? If so, this is a problem. --[[User:Improv|Improv]] 22:08, 30 December 2010 (UTC) | *Does this remove our ability to disable SELinux? If so, this is a problem. --[[User:Improv|Improv]] 22:08, 30 December 2010 (UTC) | ||
---- | |||
See [http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 False Boundaries and Arbitrary Code Execution] by Linux security expert Brad Spengler. In summary, 20 of the 35 capabilities bits allow actions that can result in root privileges from an exploitable program. | |||
I propose that we modify this feature to remove setuid only from binaries requiring only capabilities that are on the remaining list of 15. | |||
The remaining binaries should be left setuid, which is more transparent to admins (improving security through obviousness!). | |||
--[[User:Mattdm|Mattdm]] 14:25, 5 January 2011 (UTC) | |||
---- | |||
Revision as of 14:25, 5 January 2011
It would be good to add some documentation here about the existing capabilities, and how to find out which ones are needed for a concrete binary. Also, how do we deal with random runtime breakage if packagers get it wrong ? Is there some testplan ? --mclasen 19:26, 27 October 2010 (UTC)
- I also would like to see the HOWTO on determining required capabilities. Peter Lemenkov 16:38, 29 October 2010 (UTC)
I dispute the comment that "user experience" would stay the same with this feature. "ls -l" does not show the capabilities, so auditing this becomes more complicated. Because of this, a sysadmin may disable capabilities entirely, leaving these no-longer-setuid programs dead.
Similarly, administrative documentation needs to be updated. Shipped tools that deal with file copy/backup/restore/verification need to be tested for capability to deal with capabilities.
A larger blurb about how this makes Fedora "more secure" would be useful. Fche 16:29, 30 October 2010 (UTC)
- It's not completely true that ls -l doesn't show it:
- [root@helmholtz ~]# chmod u+s ./bash.suid; setcap cap_net_bind_service+eip bash.cap
- [root@helmholtz ~]# ls -l bash.*
- -rwxr-xr-x. 1 root root 943360 Oct 31 13:23 bash.cap
- -rwsr-xr-x. 1 root root 943360 Oct 31 13:22 bash.suid
- Though that does require color-ls. I fully agree that some good scripts, utilities, and/or tutorials for auditing need to be provided. --Gmaxwell 17:37, 31 October 2010 (UTC)
It would be nice to have a clarification about the case where a machine has SELinux disabled or it uses some filesystem that does not support capabilities.--Amcnabb 17:33, 1 November 2010 (UTC)
There are a number of points raised about this feature mentioned here: http://permalink.gmane.org/gmane.comp.security.oss.general/3719 --davej 22:28, 8 Nov 2010 (UTC)
As tmpfs does not support capabilities, mock cannot use tmpfs for its buildroots any longer. This change causes a full FTBFS rebuild of all 10k packages to go from about 24 hours to 4 days. mdomsch
- Does this remove our ability to disable SELinux? If so, this is a problem. --Improv 22:08, 30 December 2010 (UTC)
See False Boundaries and Arbitrary Code Execution by Linux security expert Brad Spengler. In summary, 20 of the 35 capabilities bits allow actions that can result in root privileges from an exploitable program.
I propose that we modify this feature to remove setuid only from binaries requiring only capabilities that are on the remaining list of 15.
The remaining binaries should be left setuid, which is more transparent to admins (improving security through obviousness!).
--Mattdm 14:25, 5 January 2011 (UTC)