From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 9DFA03857735; Sat, 15 Apr 2023 06:41:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9DFA03857735 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1681540886; bh=2n9h7cK1rXs4zCZ9BiKXd4fpcR9JTWNWXaiAFibvZYc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=cPJ6hDNgOHbyFJvkebRwFc5FEWcQ5sGkYKioJtzIELwIzRUtcEd/Q87I3mo/RMmyd wgZmS7mNvQ7AIOCeN1KkddjquHBY7paU3BpiANwLkErlAIpxXMYFy2crIeIJtV2VI1 vwhN/LotatmVwYjDywL1e5cbPrj9BEAEm75Z//AM= Received: from [IPv6:240e:358:11d3:1100:dc73:854d:832e:5] (unknown [IPv6:240e:358:11d3:1100:dc73:854d:832e:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 7308565C2A; Sat, 15 Apr 2023 02:41:24 -0400 (EDT) Message-ID: <463988a9ddeb985307af5dd8bae1e008b7f31195.camel@xry111.site> Subject: Re: RFC: Adding a SECURITY.md document to the Binutils From: Xi Ruoyao To: Ian Lance Taylor , DJ Delorie Cc: binutils@sourceware.org, gdb@sourceware.org Date: Sat, 15 Apr 2023 14:41:19 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.0 MIME-Version: 1.0 X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,MEDICAL_SUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 2023-04-14 at 13:49 -0700, Ian Lance Taylor via Binutils wrote: > On Fri, Apr 14, 2023 at 12:45=E2=80=AFPM DJ Delorie wrote= : > >=20 > > Ian Lance Taylor via Gdb writes: > > > Compilers and linkers must behave in a reasonable manner when given > > > untrusted input. > >=20 > > Are we confusing trusted with well-behaved?=C2=A0 I mean, if I download= a > > source tree from the FSF's git server, I trust it, but it may still be > > ill-behaved.=C2=A0 Meanwhile, sources from a public mailing list may be > > well-behaved but not trusted. > >=20 > > I'm only posting this because Carlos and I had long discussions about > > this before we set up the glibc pre-commit CI.=C2=A0 This process takes > > random patches from the public glibc mailing list, and builds them. > > WHOA!=C2=A0 That's dangerous!=C2=A0 Yes.=C2=A0 The patches may produce = well-defined > > code, but are not trusted.=C2=A0 Those builds run in a tight sandbox to > > mitigate any attack attempts.=C2=A0 Security here is outside the scope = of the > > build tools.=C2=A0 I don't expect gcc to scan for viruses or prevent pe= ople > > from doing "#include ". >=20 > I agree that GCC does not have to scan for viruses or strange #include > statements. >=20 > I am saying that you should not need to set up a sandbox merely to > build code.=C2=A0 Clearly if you want to execute untrusted code, some sor= t > of sandbox is a minimal requirement.=C2=A0 I'm only talking about buildin= g > code (and, for objdump and friends, inspecting code). In practice: 1. At least we need a resource limit on the building process or a simple "int x[1 << 30] =3D {1,};" may blow up the server. We cannot just make GCC reject "int x[1 << 30] =3D {1,};" because it may be perfectly legal (though bad) in other use cases. 2. For "#include ", the risk is the passwd entries may be contained in the error message outputted by the compiler. It happens at build time, not runtime. It does not make too much sense to make GCC "don't output any error message if the error is in some sensitive file" because GCC cannot know a list of sensitive files on the system. And it also does not make too much sense to set an automatic build job w/o providing the compiler error message. So sandboxing is the only viable solution for the automatic build jobs even if these jobs won't run any produced binaries. If you are building normally (manually), things may be different though. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University