Skip to content
  • Serge E. Hallyn's avatar
    remove CONFIG_SECURITY_FILE_CAPABILITIES compile option · b3a222e5
    Serge E. Hallyn authored
    
    
    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
    SECURITY_FILE_CAPABILITIES=y kernel, by removing the
    cap_limit_ptraced_target() function.
    
    Changelog:
    	Nov 20: remove cap_limit_ptraced_target() as it's logic
    		was ifndef'ed.
    
    Signed-off-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
    Acked-by: default avatarAndrew G. Morgan" <morgan@kernel.org>
    Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    b3a222e5