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