(reference grsecurity post) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 41: | Line 41: | ||
--[[User:Mattdm|Mattdm]] 14:25, 5 January 2011 (UTC) | --[[User:Mattdm|Mattdm]] 14:25, 5 January 2011 (UTC) | ||
: Also some interesting discussion of this same paper here: http://lwn.net/Articles/421671/ <br> [[User:Rjones|Rjones]] 12:19, 7 January 2011 (UTC) | |||
---- | ---- | ||
== 100% done? == | |||
We still seem to be missing: | |||
* updated administrative documentation on how to monitor/backup/restore/manage/verify formerly-setuid programs | |||
* what to do if the filesystem lacks attribute support | |||
* description of any new related rpm behaviours | |||
* packager documentation to spell out needed code & testing-process changes | |||
* any other points raised in the talk pages | |||
[[User:Fche|Fche]] 15:19, 24 April 2011 (UTC) | |||
Latest revision as of 15:19, 24 April 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)
- Also some interesting discussion of this same paper here: http://lwn.net/Articles/421671/
Rjones 12:19, 7 January 2011 (UTC)
100% done?
We still seem to be missing:
- updated administrative documentation on how to monitor/backup/restore/manage/verify formerly-setuid programs
- what to do if the filesystem lacks attribute support
- description of any new related rpm behaviours
- packager documentation to spell out needed code & testing-process changes
- any other points raised in the talk pages
Fche 15:19, 24 April 2011 (UTC)