lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-09-25 01:53    [W:0.056 / U:1.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site