X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from dal-a2.localdomain (unknown [74.117.189.115]) by mail.alpinelinux.org (Postfix) with ESMTP id 9ECFADC0958 for ; Tue, 3 Dec 2013 15:34:14 +0000 (UTC) Received: from ncopa-desktop.alpinelinux.org (3.203.202.84.customer.cdi.no [84.202.203.3]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ncopa@tanael.org) by dal-a2.localdomain (Postfix) with ESMTPSA id C1A78BC3D68; Tue, 3 Dec 2013 15:34:13 +0000 (UTC) Date: Tue, 3 Dec 2013 16:34:09 +0100 From: Natanael Copa To: Jim Pryor Cc: Alpine Subject: Re: [alpine-devel] a few abuild oddities Message-ID: <20131203163409.2bfaef86@ncopa-desktop.alpinelinux.org> In-Reply-To: <1386000265.25324.54500989.5FF25FA8@webmail.messagingengine.com> References: <20131201174554.GB29236@zen> <20131201235659.GD29236@zen> <20131202142914.4438af81@ncopa-desktop.alpinelinux.org> <1386000265.25324.54500989.5FF25FA8@webmail.messagingengine.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-alpine-linux-uclibc) 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 On Mon, 02 Dec 2013 11:04:25 -0500 Jim Pryor wrote: > On Mon, Dec 2, 2013, at 08:29 AM, Natanael Copa wrote: > > One thing we could do to improve the security a bit is to ban the > > --allow-untrusted option with the suid abuild-apk. That would allow the > > users in abuild group to install signed packages only. Adding the user > > to 'abuild' group and the users key to /etc/apk/keys would then be > > equivalent as give full root access. > > I do think this would be a good improvement, if only for people who put > users in the abuild group without fully understanding the consequences. > In practice, though, anyone who knows what they're doing is going to > also put a key in /etc/apk/keys, and then any vulnerabilities in that > account will give full root access. Ok. I will look into this. > Is it possible to use abuild for the full range of activities without > being in the abuild group? Do we just prompt with sudo or su in those > cases when needed? In that case the security-conscious solution will > just be don't add your users to the "abuild" group. The costs and > benefits of this would just need to be more clearly documented. You need either be in abuild group or have sudo permissions to use abuild -r for letting abuild install the deps for you. To use sudo instead of abuild-apk you can set SUDO_APK="sudo apk" in /etc/abuild.conf (or just export SUDO_APK="sudo apk"). You can still build packages with abuild without needing sudo but then all the dependencies needs to be installed already: SUDO_APK=apk abuild The motivation behind abuild group was to make it convenient to set up a build server. Might be we want change the default back to sudo. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---