Messages in this thread | | | Date | Wed, 24 Sep 2008 16:49:03 -0700 | From | Chris Wright <> | Subject | Re: [PATCH 2/2] file capabilities: remove CONFIG_SECURITY_FILE_CAPABILITIES |
| |
* Serge E. Hallyn (serue@us.ibm.com) wrote: > Remove the option to compile the kernel without file capabilities. Not > compiling file capabilities actually makes the kernel less safe, as it > includes the possibility for a task changing another task's capabilities. > > Some are concerned that userspace tools (and user education) are not > up to the task of properly configuring file capabilities on a system. > For those cases, there is now the ability to boot with the no_file_caps > boot option. This will prevent file capabilities from being used in > the capabilities recalculation at exec, but will not change the rest > of the kernel behavior which used to be switchable using the > CONFIG_SECURITY_FILE_CAPABILITIES option.
(note: defconfig has CONFIG_SECURITY_FILE_CAPABILITIES=y) text data bss dec hex filename 6805157 1018344 671900 8495401 81a129 obj64-defconfig/vmlinux 6805151 1018368 671900 8495419 81a13b obj64-defconfig-patch1/vmlinux 6805151 1018368 671900 8495419 81a13b obj64-defconfig-patch2/vmlinux 6804605 1018344 671900 8494849 819f01 obj64-nofcap/vmlinux 6804604 1018344 671900 8494848 819f00 obj64-nofcap-patch1/vmlinux 6805150 1018368 671900 8495418 81a13a obj64-nofcap-patch2/vmlinux
The last 2 show the real diff now, add 570 bytes by effectively forcing CONFIG_SECURITY_FILE_CAPABILITIES on.
What is being done to enable userspace in distros to make those 570 bytes generally useful?
thanks, -chris
| |