linux-kernel - Re: [PATCH] Fix race condition when exec'ing setuid files

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:   Wed, 5 Oct 2022 13:09:36 -0300
From:   Jorge Merlino <jorge.merlino@...onical.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Eric Biederman <ebiederm@...ssion.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix race condition when exec'ing setuid files

On 13/9/22 19:03, Kees Cook wrote:
> I'll want to spend some more time studying this race, but yes, it looks
> like it should get fixed. I'm curious, though, how did you find this
> problem? It seems quite unusual to have a high-load heavily threaded
> process decide to exec.

I just got a response from our customer regarding the situation where 
this race condition occurs:

Our application is a Rust-based CLI tool that acts as a frontend to 
cloud-based testing infrastructure. In one mode of operation it uploads 
a large number of test artifacts to cloud storage, spawns compute 
instances, and then starts a VPN connection to those instances. The 
application creates the VPN connection by executing another setuid-root 
tool as a subprocess. We see that this subprocess sometimes fails to 
setuid. The "high-load heavily threaded" aspect comes from the fact that 
we're using the Tokio runtime. Each upload to cloud storage is a 
separate Tokio task (i.e. "green thread") and these are scheduled onto 
"N" OS-level threads, where N = nproc. In a large run we may upload a 
couple thousand artifacts but limit to 50 concurrent uploads. Once these 
artifact uploads complete, we typically spawn the setuid subprocess 
within 1-2 seconds.

Have you been able to look at this issue?

Thanks
	Jorge