Message-Id: <1386000265.25324.54500989.5FF25FA8@webmail.messagingengine.com>
From: Jim Pryor <dubiousjim@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: Alpine <alpine-devel@lists.alpinelinux.org>
Precedence: list
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
In-Reply-To: <20131202142914.4438af81@ncopa-desktop.alpinelinux.org>
References: <20131201174554.GB29236@zen> <20131201235659.GD29236@zen>
 <20131202142914.4438af81@ncopa-desktop.alpinelinux.org>
Subject: Re: [alpine-devel] a few abuild oddities
Date: Mon, 02 Dec 2013 11:04:25 -0500

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.

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.

-- 
dubiousjim@gmail.com



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---