linux-kernel - Re: [PATCH 1/2] kernel/sys.c: return the current gid when error occurs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 08 Aug 2013 15:52:36 +0200
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Chen Gang <gang.chen@...anux.com>
CC:	Andy Lutomirski <luto@...capital.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Kees Cook <keescook@...omium.org>,
	Al Viro <viro@...iv.linux.org.uk>, holt@....com,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] kernel/sys.c: return the current gid when error occurs

On 08/08/13 03:48, Chen Gang wrote:
> On 08/08/2013 09:35 AM, Andy Lutomirski wrote:
>> On Wed, Aug 7, 2013 at 6:30 PM, Chen Gang <gang.chen@...anux.com> wrote:
>>> On 08/08/2013 12:58 AM, Andy Lutomirski wrote:
>>>> On Wed, Aug 7, 2013 at 9:21 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>>>>> On 08/06, Andy Lutomirski wrote:
>>>>>>
>>>>>> I assume that what the man page means is that the return value is
>>>>>> whatever fsgid was prior to the call.  On error, fsgid isn't changed, so
>>>>>> the return value is still "current".
>>>>>
>>>>> Probably... Still
>>>>>
>>>>>         On success, the previous value of fsuid is returned.
>>>>>         On error, the current value of fsuid is returned.
>>>>>
>>>>> looks confusing. sys_setfsuid() always returns the old value.
>>>>>
>>>>>> (FWIW, this behavior is awful and is probably the cause of a security
>>>>>> bug or three, since success and failure are indistinguishable.
>>>>>
>>>>> At least this all looks strange.
>>>>>
>>>>> I dunno if we can change this old behaviour. I won't be surprized
>>>>> if someone already uses setfsuid(-1) as getfsuid().
>>>>
>>>
>>> Oh, really it is.
>>>
>>> Hmm... as a pair function, we need add getfsuid() too, if we do not add
>>> it, it will make negative effect with setfsuid().
>>>
>>> Since it is a system call, we have to keep compitable.
>>>
>>> So in my opinion, better add getfsuid2()/setfsuid2() instead of current
>>> setfsuid()
>>
>> How about getfsuid() and setfsuid2()?
>>
> 
> Hmm... I have 2 reasons, please check.
> 
> 1st reason: I checked history (just like Kees Cook suggested),
> getfsuid() is mentioned before (you can google to find it), so need use
> getfsuid2() to bypass the history complex.
> 
> And 2nd reason: getfsuid() seems more like the pair of setfsuid(), not
> for setfsuid2().

Time to apply the brakes... *Why* add new system calls here? I don't 
think there is any good reason. Yes, the existing APIs are rubbish,
but, as far as I can tell, they are also obsolete and unneeded.
The fsuid/fsgid mechanism was a bizarre Linuxism whose only purpose
was (as far as I know), to allow for the fact that Linux long ago
applied nonstandard rules when determining when one process could 
send signals to another. Quoting some book on the subject:

    Why does Linux provide the file-system IDs and in what 
    circumstances would we want the effective and file-system 
    IDs to differ? The reasons are primarily historical.
    The file-system IDs first appeared in Linux 1.2. In 
    that kernel version, one process could send a signal to 
    another if the effective user ID of the sender matched
    the real or effective user ID of the target process. 
    This affected certain programs such as the Linux NFS 
    (Network File System) server program, which needed to be
    able to access files as though it had the effective IDs 
    of the corresponding client process. However, if the NFS 
    server changed its effective user ID, it would be 
    vulnerable to signals from unprivileged user processes. 
    To prevent this possibility, the separate file-system user
    and group IDs were devised. By leaving its effective IDs
    unchanged, but changing its file-system IDs, the NFS 
    server could masquerade as another user for the purpose of 
    accessing files without being vulnerable to signals from
    user processes.

    From kernel 2.0 onward, Linux adopted the SUSv3-mandated 
    rules regarding permission for sending signals, and these 
    rules don't involve the effective user ID of the target
    process. Thus, the file-system ID feature is no longer 
    strictly necessary (a process can nowadays achieve the 
    desired results by making judicious use of the system
    calls described later in this chapter to change
    the value of the effective user ID to and from an
    unprivileged value, as required), but it remains for
    compatibility with existing software.

So, I don't think anything needs fixing: there should be no 
new users of these system calls anyway.

Cheers,

Michael


-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

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