X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 192835C6313 for ; Mon, 24 Sep 2018 12:24:12 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 837CB9E20B0; Mon, 24 Sep 2018 12:24:11 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alpine@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id D22949E1F5F; Mon, 24 Sep 2018 12:24:10 +0000 (GMT) Date: Mon, 24 Sep 2018 14:24:05 +0200 From: Natanael Copa To: Michael Wyraz Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] Build security - run as root, drop privileges during compile Message-ID: <20180924142405.71b8a828@ncopa-desktop.copa.dup.pw> In-Reply-To: <9a302990-8762-9572-b363-8b0c5710741e@wyraz.de> References: <9a302990-8762-9572-b363-8b0c5710741e@wyraz.de> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Yes, I think you are right. The current approach is hackish and could been done better. Changing this will require some refactoring of aports-build too, which would need to run as root and drop privileges for all everything except calling abuild. We have been talking about refactor the building infra for a while and this is one of the things I'd like to fix. Not sure when I'll get to that though. We can probably fix abuild to not bail out if you run it as root and make it drop privileges instead, and deal with the build server scripts later. Thanks! -nc On Sun, 23 Sep 2018 19:50:43 +0200 Michael Wyraz wrote: > Hello devs, > > the current abuild refuses to run as root and requires a user in the > "abuild" group to run builds "for security reasons". IMO this does not > improve security and probably should be done exactly the other way > round: Run abuild as root and drop privileges at any place where > untrusted code is executed. > > APK builds usually run as unprivileged user which is in the "abuild" > group. Abuild allows to specify a lot of things in the APKBUILD file > that requires root privileges (e.g. installing of packages, creation of > system users and groups). To allow this for the unprivileged abuild > user, a SUID executable "abuild-sudo" is provided which is a sudo > wrapper for several system tools (e.g. abuild-apk which wraps apk). > Since the compiling step also runs as that user, it has full access to > the SUIDed executables which is basically the same as granting full > system access. > > Example: If a Makefile (which is run in the abuild context) downloads an > arbitrary APK and installs it via "abuild-apk --allow-untrusted", the > packages post install scripts are executed as root. > > To improve build security and hardening build systems against malicious > compiling steps, abouid should perform tasks like installing of packages > and adding system users and groups as root and drop all privileges > during execution of the compiling steps (e.g. by su-ing to an > unprivileged user that has _no_ access to the SUID abuild applications). > > Kind regards, > > Michael. > > > > > --- > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > Help: alpine-devel+help@lists.alpinelinux.org > --- > --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---