lkml.org 
[lkml]   [2009]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] remove CONFIG_SECURITY_FILE_CAPABILITIES compile option
Quoting Serge E. Hallyn (serue@us.ibm.com):
> As far as I know, all distros currently ship kernels with default
> CONFIG_SECURITY_FILE_CAPABILITIES=y. Since having the option on
> leaves a 'no_file_caps' option to boot without file capabilities,
> the main reason to keep the option is that turning it off saves
> you (on my s390x partition) 5k. In particular, vmlinux sizes
> came to:
>
> without patch fscaps=n: 53598392
> without patch fscaps=y: 53603406
> with this patch applied: 53603342
>
> with the security-next tree.
>
> Against this we must weigh the fact that there is no simple way for
> userspace to figure out whether file capabilities are supported,
> while things like per-process securebits, capability bounding
> sets, and adding bits to pI if CAP_SETPCAP is in pE are not supported
> with SECURITY_FILE_CAPABILITIES=n, leaving a bit of a problem for
> applications wanting to know whether they can use them and/or why
> something failed.
>
> It also adds another subtly different set of semantics which we must
> maintain at the risk of severe security regressions.
>
> So this patch removes the SECURITY_FILE_CAPABILITIES compile
> option. It drops the kernel size by about 50k over the stock

As Andrew points out, not 50k! Try about 50 bytes :) Sorry about that.

-serge


\
 
 \ /
  Last update: 2009-11-24 00:17    [W:0.063 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site