Date: Sun, 1 Dec 2013 18:56:59 -0500
From: Dubiousjim <dubiousjim@gmail.com>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] a few abuild oddities
Message-ID: <20131201235659.GD29236@zen>
Mail-Followup-To: alpine-devel@lists.alpinelinux.org
References: <20131201174554.GB29236@zen>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131201174554.GB29236@zen>
User-Agent: Mutt/1.5.22 (2013-10-16)

On Sun, Dec 01, 2013 at 12:45:54PM -0500, Dubiousjim wrote:

> Second, I don't understand how abuild is acquiring sufficient
> permissions to do what it seems to be doing in these cases.
> 
> My user belongs to the "abuild" group, but normally isn't able to even
> acquire a lock on the apk database, much less add or del packages,
> without raising privileges via sudo or su. Also, my /etc/apk/world file
> lists as:
> 
> -rw-r--r--    1 root     root           885 Dec  1 11:58 /etc/apk/world
> 
> However, I can be sure that sudo hasn't cached any privileges (sudo -k)
> and go into an aports directory and type `abuild -r -i pkg1` (supplying
> an appropriate package name), and then WITHOUT EVER ASKING FOR A
> PASSWORD, abuild will:
> 
> * download and install the necessary dependencies: I assume it shouldn't
>   be able to do this without privileges, although possibly the packages
>   are getting installed in an overlay or some-such ... I know that
>   didn't use to be the case, but I haven't kept close tabs on how the
>   code has developed over the past year or so. Even if the packages
>   weren't really getting installed to /, where the user running abuild
>   lacks sufficient privileges, still how can abuild update
>   /etc/apk/world? which one can see it does because the .makedepends-foo
>   virtual package never gets deleted (see first issue above)
> 
> * if the build completes successfully, then install the relevant local
>   package, again which it shouldn't be able to do without prompting for
>   a password
> 
> Perhaps the issue here isn't with abuild, but rather with one or the
> other of fakeroot and sudo?

I've figured out the answer to this question. The answer is that we have
a binary abuild-sudo, which is installed suid, and can be invoked by
anyone in the "abuild" group (via the symlinks abuild-apk,
abuild-addgroup, and abuild-adduser) to run the corresponding commands
as root, without needing any sudo/su authentication.

Thus if your user belongs to the "abuild" group, then you can always do
all your apk-ing, with full permissions, just by invoking apk as
"abuild-apk" instead of just bare "apk".

The merits of this design may be debatable, but I'm at least relieved
that this *is* by design, and that I can now understand where and why
it's happening, and what the limits to this security opening are.
 
-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---