Re: [2.6 patch] remove securebits

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Andrew Morgan (morgan@kernel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Serge E. Hallyn wrote:
> > To summarize more clearly, I think that so long as we support
> > process trees with a sort of !SECURE_NOROOT support, that
> > support should include the ability to use prctl(KEEP_CAPS) the
> > way one uses it now.
> 
> > When a process tree is in strict capability mode,
> > prctl(PR_{G,S}ET_KEEP_CAPS) should return -EINVAL.
> 
> I agree. I'll try to code it up in a way that its clear how to delete
> this functionality when folk realize they no longer need it...
> 
> - -static inline int get_file_caps(struct linux_binprm *bprm)
> +int cap_bprm_set_security(struct linux_binprm *bprm)
>  {
>  	bprm_clear_caps(bprm);
> +	bprm_force_uid0_caps(bprm);
> +	current->keep_capabilities = 0;
> 
> > This is being moved from bprm_apply to bprm_set, which moves it
> > earlier.  If exec fails later on, keep_capabilities might be set
> > to 0 even though exec failed.
> 
> I'll look at it again, but I had thought I had preserved the previous
> behavior with this condensed version of the code. Are you suggesting an
> improvement to what was there, or pointing out I'm inadvertently
> breaking the old behavior?

Well it's just 'breaking' old behavior in certain error cases.  I.e. if
audit fails, or no handler is found for the binary, we never reach
compute_creds (which is called from within the binary loader), so in 
the past keep_capabilities would have remained 1 until something was
actually executed.  Now in all likelyhood the process would try to
exec something else, but if it should happen to decide to setuid()
instead, with your patch keep_capabilities will have been unexpectedly
set to 0 during the failed exec attempt.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/