Date: Mon, 2 Dec 2013 14:29:14 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Dubiousjim <dubiousjim@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] a few abuild oddities
Message-ID: <20131202142914.4438af81@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20131201235659.GD29236@zen>
References: <20131201174554.GB29236@zen>
	<20131201235659.GD29236@zen>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sun, 1 Dec 2013 18:56:59 -0500
Dubiousjim <dubiousjim@gmail.com> wrote:

> 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.

Correct.
 
> 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".

Correct. This also means that if you are in abuild-apk group you in
practice has full sudo access. So you should never put anyone in this
group unless you would also give full sudo (without asking for
password) access to this user.
 
> 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.

Agree, this is debatable and I am definitively open for ideas here.

What I wanted to achieve with this was to make it easier to set up a
build env. You now can just apk alpine-sdk and add the user to the
abuild group and you are basically set. This is also easier/cleaner
than editing sudoers from script. (think: set up a temp build
environment for a chroot build)

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.

Other ideas is welcome too.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---