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  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:   Sun, 7 Jun 2020 19:09:47 -0700
From:   Andrei Vagin <>
To:     Christian Brauner <>
Cc:     Nicolas Viennot <>,
        Adrian Reber <>,
        "Eric W. Biederman" <>,
        Casey Schaufler <>,
        Pavel Emelyanov <>,
        Oleg Nesterov <>,
        Dmitry Safonov <>,
        Michał Cłapiński <>,
        Kamil Yurtsever <>,
        Dirk Petersen <>,
        Christine Flood <>,
        Mike Rapoport <>,
        Radostin Stoyanov <>,
        Cyrill Gorcunov <>,
        Serge Hallyn <>,
        Stephen Smalley <>,
        Sargun Dhillon <>,
        Arnd Bergmann <>,
        "" <>,
        "" <>,
        Eric Paris <>,
        Jann Horn <>
Subject: Re: [PATCH] capabilities: Introduce CAP_RESTORE

> >
> > I would argue that setting the current process exe file check should just be reduced to a "can you ptrace a children" check.
> > Here's why: any process can masquerade into another executable with ptrace.
> > One can fork a child, ptrace it, have the child execve("target_exe"), then replace its memory content with an arbitrary program.
> Then it should probably be relaxed to CAP_SYS_PTRACE in the user
> namespace and not CAP_CHECKPOINT_RESTORE. (But apparently you also have
> a way of achieving what you want anyway. Imho, it's not necessarily
> wrong to require a bit more work when you want something like fully
> unprivileged c/r that's a rather special interest group.)
> > With CRIU's libcompel parasite mechanism ( this is fairly easy to implement.
> > In fact, we could modify CRIU to do just that (but with a fair amount of efforts due to the way CRIU is written),
> > and not rely on being able to SET_MM_EXE_FILE via prctl(). In turn, that would give an easy way to masquerade any process
> > into another one, provided that one can ptrace a child.
> >

I think you misunderstand this. In the case of malicious processes,
when only one or two processes must be hidden, they can use this trick
with execve+ptrace and this is relatively simple. But in the case of
CRIU, where we need to restore a process tree with cow memory
mappings, shared mappings, file descriptors and etc, this trick with
execve+ptrace doesn't work at all. We are in a weird situation when
malicious processes can do some operations, but useful tools like CRIU
needed to be running with extra capabilities that actually reduces the
security of the entire system.

Powered by blists - more mailing lists