Re: [RFC][PATCH] Unprivileged: Disable acquisition of privileges

[ebiederm@xmission.com (Eric W. Biederman)]

Bryan Donlan <bdonlan@gmail.com> writes:

> On Tue, Dec 29, 2009 at 11:33 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Bryan Donlan <bdonlan@gmail.com> writes:
>>
>>> Is this sufficient for other security models such as selinux or
>>> TOMOYO? Can processes in these models gain privileges through means
>>> not restricted here?
>>
>> The LSM is primarily about returning -EPERM more often.
>> Except for the prctl and the capability hooks I am not aware
>> of anywhere a LSM can increase a processes capabilities.
>
> I'm more concerned about a case where a privilege that the LSM
> currently denies is lifted by execing some executable - this is still
> an increase in privilege, even though the LSM only adds additional
> restrictions. That is:
>
> 1) Initial state: LSM denies access to /somefile (although normal
> POSIX permissions would permit access)
> 2) Disable capability-gaining
> 3) Disable network access with proposed API
> 4) Exec some application, which is labeled in a way that permits
> access to /somefile
> 5) Application fails to access the network, then does something to /somefile
>
> I'm not entirely sure if step 4) can happen in any of the currently
> existing LSMs - if it's not possible to gain privileges in them via a
> suid-like mechanism, this isn't a problem, but it's something that
> needs to be checked for.

A reasonable concern.  When the glitches get worked out of this patch
I intend to allow much more dangerous things like unprivileged unsharing
of all of the namespaces, and unprivileged mounts.

It appears I missed a place where MNT_NOSUID was handled in selinux.
So I will be adding a bprm->nosuid field so I don't have to duplicate
the MNT_NOSUID check everywhere it is used.

I don't understand TOMOYO  I think it is file based access control,
which suggests there is not a suid like mechanism.

Smack and selinux are label based.  Selinux at least can switch labels
on exec, but it handles NOSUID already.

Looking a little farther if I assume that lsm implementations that
implement the set_creds hook need attention.  Only selinux has
an interesting set_creds implementation and it handles nosuid already.

So I think we are ok.

Eric