From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3177 invoked from network); 13 Oct 2020 17:05:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2020 17:05:31 -0000 Received: (qmail 20022 invoked by uid 550); 13 Oct 2020 17:05:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20004 invoked from network); 13 Oct 2020 17:05:27 -0000 Date: Tue, 13 Oct 2020 13:05:15 -0400 From: Rich Felker To: Alexey Izbyshev Cc: musl@lists.openwall.com Message-ID: <20201013170515.GS17637@brightrain.aerifal.cx> References: <93cbaeffbc860a145843e0380058c50e@ispras.ru> <20201012145549.GG17637@brightrain.aerifal.cx> <422e80eccf76a8937d3528c3cfe52aa2@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422e80eccf76a8937d3528c3cfe52aa2@ispras.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Calling setxid() in a vfork()-child On Tue, Oct 13, 2020 at 07:52:28PM +0300, Alexey Izbyshev wrote: > On 2020-10-12 23:30, Alexey Izbyshev wrote: > >...However, thinking about it > >more, I see that dropping privileges could open the child to new ways > >of interaction from outside of the app in a window before execve(), > >so, if, say, another unprivileged process can ptrace it at the right > >moment, bad things could happen. > > > Alexander Monakov pointed out to me that this particular naive > attack is not possible (unless "/proc/sys/fs/suid_dumpable" is > changed or the application resets "dumpable" bit via prctl() after > setxid()): > https://elixir.bootlin.com/linux/v5.9/source/kernel/cred.c#L466 Yes, the underlying idea here is that suid programs will often open a privileged resource to perform limited operations on it, and while the outcome of giving the user unrestricted access to that resource might not be catastrophic, it's likely at least disruptive (think ping and raw sockets). Also it may still have privileged data (like private keys or remnants thereof) in its memory. So the user is not allowed to debug/trace/seize control of such a process unless it explicitly opts in. Rich