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: <20220908081003.sjuerd5wiyge4jos@wittgenstein>
Date:   Thu, 8 Sep 2022 10:10:03 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Andrei Vagin <avagin@...il.com>
Cc:     Alexey Izbyshev <izbyshev@...ras.ru>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Florian Weimer <fweimer@...hat.com>,
        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 10:15:51AM -0700, Andrei Vagin wrote:
> 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.

LXC/LXD does

unshare(CLONE_NEWTIME)
// write offsets to /proc/self/timens_offsets
timens_fd = open("/proc/self/ns/time_for_children", O_RDONLY | O_CLOEXEC)
setns(timens_fd, CLONE_NEWTIME)
exec(payload)

so I agree don't change the uapi, please.

But as you can see what we do is basically emulating changing time
namespace during exec via the setns() prior to the exec call.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ