Date: Tue, 21 Jun 2022 13:18:39 -0500 (CDT)
From: Ariadne Conill <ariadne@dereferenced.org>
To: Markus Kolb <alpinelinux+develml@tower-net.de>
cc: Jakub Jirutka <jakub@jirutka.cz>, 
    Alpine Linux users ML <~alpine/users@lists.alpinelinux.org>
Subject: Re: Security problem in how you manage users in package
 installations
In-Reply-To: <b1c1278d4461aaf940aea2d24c0e05d6@tower-net.de>
Message-ID: <aeb543df-bba4-15d8-7f2b-649e3b8eeec@dereferenced.org>
References: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de> <cf311040-21f2-ad8b-4b9c-363f7ad0c9f5@jirutka.cz> <b1c1278d4461aaf940aea2d24c0e05d6@tower-net.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hi,

On Tue, 21 Jun 2022, Markus Kolb wrote:

> Am 19.06.2022 19:23, schrieb Jakub Jirutka:
>>> There is the possibility to allow an unintended (remote) login or local 
>>> privilege expansion by unlocking users in apk-executed scripts.
>> 
>> No, if the user already exists, then adduser(8) does nothing.
>> 
>
> But passwd does. Unlocking is happening with passwd and not adduser.

In the case of Gogs and Gitea, this is necessary to enable the package to 
work as intended.  The user accounts are restricted to running the Gogs / 
Gitea shell helper and cannot by default run a normal /bin/sh.

> Not sure why you all point to adduser?!

The typical pattern is to use adduser to add users in post-install 
scripts, this is admittedly sub-optimal design but requires the package 
manager to be aware of what account mutations need to occur.

> Can you all try to understand the problem and not try to avoid the 
> explanations and saying all is fine like it is?!

Speaking with authority as Alpine's designated security officer, I do not 
see the problem with the Gogs / Gitea packages.

> It is not, you have a package in your repository, where you can get for sure 
> a CVE entry for because of how it is installed by apk.

Speaking with authority as Alpine's designated security officer, we will 
vehemently dispute any CVE entries filed for this issue.

> This is all quite exhausting to discuss a problem like there is no problem 
> and need to explain things not being part of.

Speaking with authority as Alpine's designated security officer, multiple 
members of the Alpine security team have explicitly told you that we do 
not believe there is a problem in this case.

The Alpine security team does, however, believe that `passwd -u` should be 
avoided as a best practice unless it is justifiable.  In this case, it is 
justifiable -- the accounts in question must be unlocked for the package 
to function as intended.

> This is no help.

Demanding we do what you want is also not helpful.  If you believe this is 
a real problem, then show us a real exploit.  At present, all I am seeing 
is that a user must:

1. Add a `gogs` or `gitea` account to their system.
2. Lock that account.
3. Install `gogs` or `gitea` which results in it being unlocked.

If you go to a doctor and say "it hurts when I do this," the doctor will 
tell you "don't do that."  Same principle here.

Ariadne