linux-kernel - Re: [RFC 1/2] fs,eventpoll: Add ability to install target file by its number

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 17 Feb 2017 09:20:34 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Cyrill Gorcunov <gorcunov@...il.com>
Cc:     Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Andrew Vagin <avagin@...tuozzo.com>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Kirill Kolyshkin <kir@...nvz.org>,
        Andrey Vagin <avagin@...nvz.org>
Subject: Re: [RFC 1/2] fs,eventpoll: Add ability to install target file by its number

On Fri, Feb 17, 2017 at 9:11 AM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Fri, Feb 17, 2017 at 08:52:59AM -0800, Andy Lutomirski wrote:
>> >
>> > To resolve this tie lets add EPOLL_CTL_DUP operation which simply takes
>> > target file descriptor number and installs it into a caller's file table,
>> > thus we can use kcmp() syscall and figure out which exactly file to be
>> > added into eventpoll on restore procedure.
>>
>> This is a scary thing to let an unprivileged process do.
>>
>> I'm wondering if there might be a nicer way to address this using a
>> better interface in /proc.
>
> Well, I tend to agree. Need to add security checking if the target
> file is accessable by a caller. As to better interface to procfs
> nothing comes to mind immediately. Another potential problem is that
> since it is never guaranteed that target file number listed in fdinfo
> matching existing /proc/pid/fd/N, so that I think we will have to
> use this dup functionality for every target file, which of course
> not that fast. Probably need to think more if I manage to invent
> some better and faster interface to find where exactly target file
> belong in the whole process tree of a container.

i was imagining some proc or proc-like interface that lets you inspect
an open file without needing to know what process has the fd.

What if you introduced a new type of fd that's an "fd reference".  You
could add a kcmp mode that tells you whether an fd reference refers to
the same thing as a real fd, but you'd arrange for fd references to be
otherwise useless.

Alternatively, you could simply have an interface like kcmp (maybe a
new kcmp mode) that lets you compare an epoll set entry to an actual
fd.  Then you could figure out what it is but only if you already have
the fd by some other means.  Of course, if there are no references
left, you still have a problem.  Hmm.

>
> Thanks for pointing about this security problem, Andy!



-- 
Andy Lutomirski
AMA Capital Management, LLC