Message-ID: <5df607d9-8eb4-9ccb-4dc2-02bec9323659@h6g.de>
Date: Wed, 22 Jun 2022 14:14:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Security problem in how you manage users in package installations
Content-Language: en-US
To: Markus Kolb <alpinelinux+develml@tower-net.de>,
 Alpine Linux devel ML <~alpine/devel@lists.alpinelinux.org>
References: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de>
From: Paul Zillmann <p.zillmann@h6g.de>
In-Reply-To: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Markus,

I've read thru the entire conversation - the problem you are drawing 
isn't one.

1. The passwd calls have an adduser call right above them, creating a 
system user with that name.
That fails if the user already exists and would return a non-zero return 
code. Thereby the package installation fails.

2. When you would create those users yourself it would fail too.
So the only reason your procedure would work is when an administrator 
decides to give you access to a system user and change the shell wrapper 
for that user.

3. This could also occur when you change the running user of gitea / 
gogs in their respective config.

All of this is the responsibility of the system administrator.
This is NOT an exploit the same way "I can change my root password to 
123456" is not an exploit.

Am I missing something here?
- Paul

Am 18.06.22 um 12:00 schrieb Markus Kolb:
> Hello,
>
> I'm trying to maintain 2 packages I'm using with Alpine and would not 
> like to see being removed from the repositories from future releases.
> But I could see that there is some basic problem.
> Currently you are unlocking users in pre-install of packages without 
> any further checks of the existing system environment.
> There is assumed the user is not existing, there is no username clash, 
> the user has not set a password, the user is used only for this 
> package and so on.
> In short... this is a no-go to circumvent any administrative security 
> related restrictions by package installations.
> There is the possibility to allow an unintended (remote) login or 
> local privilege expansion by unlocking users in apk-executed scripts.
> And there is no sensitivity for this problem, because it is the 
> recommended way of providing packages. (Quote: "see the <...apk> 
> .pre-install, which is how all of them are done").
>
> I'm negatively surprised how careless the basic system permissions are 
> used.
>
> Are you aware of this situation in Alpine and happy with it?
>
> Markus