Re: RFC: disablenetwork facility. (v4)

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

Bryan Donlan <bdonlan@gmail.com> writes:

> On Tue, Dec 29, 2009 at 11:39 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
>> Quoting Bryan Donlan (bdonlan@gmail.com):
>>> On Tue, Dec 29, 2009 at 10:11 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
>>> > Eric, let me specifically point out a 'disable setuid-root'
>>> > problem on linux: root still owns most of the system even when
>>> > it's not privileged.  So does "disable setuid-root" mean
>>> > we don't allow exec of setuid-root binaries at all, or that
>>> > we don't setuid to root, or that we just don't raise privileges
>>> > for setuid-root?
>>>
>>> I, for one, think it would be best to handle it exactly like the
>>> nosuid mount option - that is, pretend the file doesn't have any
>>> setuid bits set. There's no reason to deny execution; if the process
>>> would otherwise be able to execute it, it can also copy the file to
>>> make a non-suid version and execute that instead. And some programs
>>> can operate with reduced function without setuid. For example, screen
>>> comes to mind; it needs root to share screen sessions between multiple
>>> users, but can operate for a single user just fine without root, and
>>> indeed the latter is usually the default configuration.
>>
>> That's fine with me, seems safe for a fully unprivileged program to
>> use, and would make sense to do through one of the securebits set
>> with prctl(PR_SET_SECUREBITS).
>>
>> In addition, I assume we would also refuse to honor file capabilities?
>
> Yes - essentially a one-time switch saying "never allow me to gain
> capabilities again".

That is what I was thinking.  Does setresuid case problems?  Assuming
the application that drop permissions could have successfully
called setresuid?

Ignoring the bits instead of honoring them when execing an executable
makes sense as that is the existing precedent.

If it works prctl appears to be a fine interface.

Eric