linux-kernel - Re: Potentially undesirable interactions between vfork() and time namespaces

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]

Message-ID: <YxjRx3+MipdFOudw@gmail.com>
Date:   Wed, 7 Sep 2022 10:15:51 -0700
From:   Andrei Vagin <avagin@...il.com>
To:     Alexey Izbyshev <izbyshev@...ras.ru>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Florian Weimer <fweimer@...hat.com>,
        Christian Brauner <brauner@...nel.org>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Kees Cook <keescook@...omium.org>
Subject: Re: Potentially undesirable interactions between vfork() and time
 namespaces

On Wed, Sep 07, 2022 at 08:33:20AM +0300, Alexey Izbyshev wrote:
> > 
> > That is something to be double checked.
> > 
> > I can't see where it would make sense to unshare a time namespace and
> > then call exec, instead of calling exit.  So I suspect we can just
> > change this behavior and no one will notice.
> > 
> One can imagine a helper binary that calls unshare, forks some children in
> new namespaces, and then calls exec to hand off actual work to another
> binary (which might not expect being in the new time namespace). I'm purely
> theorizing here, however. Keeping a special case for vfork() based only on
> FUD is likely a net negative, so it'd be nice to hear actual time namespace
> users speak up, and switch to the solution you suggested if they don't care.

I can speak for one tool that uses time namespaces for the right
reasons. It is CRIU.  When a process is restored, the monotonic and
boottime clocks have to be adjusted to match old values. It is for what
the timens was designed for. These changes doesn't affect CRIU.

Honestly, I haven't heard about other users of timens yet. I don't take
into account tools like unshare.

> 
> The "unshare" tool from util-linux will also change behavior if called
> without "--fork" (e.g. "unshare --user --time"), but that would be unusual
> usage (just as for "--pid"), so most people probably don't do that (or don't
> care about the time namespace of the exec'ed process, but care only about
> its children).