Messages in this thread | | | Date | Wed, 24 Sep 2008 20:02:33 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH 2/2] file capabilities: remove CONFIG_SECURITY_FILE_CAPABILITIES |
| |
Quoting Chris Wright (chrisw@sous-sol.org): > * 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
(what are you using to get these numbers?)
> The last 2 show the real diff now, add 570 bytes by effectively forcing > CONFIG_SECURITY_FILE_CAPABILITIES on.
That surprises me - I thought a reasonable amount of code was cut as well. Sounds like it may be worth it to refactor some of the code.
> What is being done to enable userspace in distros to make those 570 > bytes generally useful?
Fedora 9 and ubuntu intrepid already have full capabilities support and modern libcap. Sles is set to ship with a modern libcap, and according to what Andreas is saying, if we can provide them with the no_file_caps boot option then suse is willing to have a kernel with capabilities turned on. I think gentoo still comes with libcap-1. Need to look into changing that.
I suppose the next baby-step will be to do get rid of setuid on little things like ping. Actually using inheritable caps for pseudo-admin 'roles' may be a bit farther off, and a particularly interesting problem will be to take huge pieces of cross-os software like ssh which make assumptions about setuid behavior, and find ways to make them work correctly with capabilities, with capabilities in SECURE_NOROOT|SECURE_NOSETUIDFIXUP, and with non-linux oses.
-serge
| |