Re: Fixing setfsuid/setfsgid

[Florian Weimer <fweimer@redhat.com>]

On 01/22/2014 02:56 PM, Jeff Layton wrote:
> On Wed, 22 Jan 2014 13:40:46 +0100
> Florian Weimer <fweimer@redhat.com> wrote:
>
>> At present, setfsuid and setfsgid return the same value on success and
>> on error, so it is rather difficult to check for errors.  Since the
>> userns changes at least, failure can not only be caused by lack of the
>> CAP_SETUID capability, but also by an out-of-memory situation.
>>
>
> It is awkward, but how is it ambiguous? If you get back the same value
> you passed in, then you know that nothing changed.

It returns the old value, not the new value, just like umask.

>> * Introduce new system calls setfsuid1, fetfsgid1 which have the usual
>> "return -errno on failure, 0 on success" semantics.
>>
>> * Introduce getfsuid, getfsgid, so that applications can check for
>> failure by noting that the fs?id did not change.  These system calls
>> might have other uses as well.  Emulation in glibc by parsing
>> /proc/self/status is possible.
>>
>
> #2 sounds quite reasonable. It's simple, and having a setfsuid()
> without a way to definitively fetch the current value is dumb.

Yes, it's certainly simple, and we can try to do some magic in glibc to 
deprecate looking at the return value of setfsuid.  getumask seems to 
missing as well.

>> * Don't bother with fs?id at all anymore and attach effective security
>> information to descriptors, which are then inherited by the *at
>> functions.  This is far more invasive, but would solve the
>> multi-threading ambiguity and could be reasonably extended to umask and
>> security contexts.  This would need new system calls fsetuid, fsetgid,
>> and probably socketat (for bind/connect) and perhaps socketpairat.
>>
>
> (cc'ing Jim Lieb)
>
> I know that Jim had been working on something along these lines, but I
> don't know the current state of that work...

Interesting, thanks.

-- 
Florian Weimer / Red Hat Product Security Team