Subject: Re: [RFC][PATCH v2] Unprivileged: Disable raising of privileges

From: [email-masked] (Eric W. Biederman)
Date: Wed, 30 Dec 2009 12:45:41 -0800

"Serge E. Hallyn" <[email-masked]> writes:

>> @@ -869,6 +869,18 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,
>>  			new->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
>>  		goto changed;
>> 
>> +	case PR_SET_NOSUID:
>> +	{
>> +		const struct cred *cred = current->cred;
>> +		error = -EINVAL;
>
> Should this be -EPERM?  not sure...

I intended -EINVAL to say it is simply a set of initial conditions
that are not supported today.  But could be supported if someone
does the audit, and found there are no security issues.

>> +		/* Perform the capabilities checks */
>> +		if (!cap_isclear(cred->cap_permitted) ||
>> +		    !cap_isclear(cred->cap_effective))
>
> No need to check cap_effective, as no bits can be there which are not
> in cap_permitted.
>
> To be honest, I don't think there is much reason to not have this
> check done in the main sys_prctl(0 - capabilities themselves are not
> optional in the kernel, while cap_task_prctl() is.  So you are setting
> us up to have cases where say an apparmor user can call this with uid
> 0 and/or active capabilities.

Sounds fine to me.  I had noticed all of the capabilities checks were
off in their own file, so I had tried to maintain that.  But you are
right we can't remove capabilities so splitting the code like this only
obfuscates it.

>> @@ -2147,7 +2147,7 @@ static int selinux_bprm_set_creds(struct linux_binprm *bprm)
>>  	COMMON_AUDIT_DATA_INIT(&ad, FS);
>>  	ad.u.fs.path = bprm->file->f_path;
>> 
>> -	if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
>> +	if (bprm->nosid)
>
> typo - nosuid?

Yep.

Eric