MIME-Version: 1.0
References: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de>
In-Reply-To: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de>
From: Konstantin Kulikov <k.kulikov2@gmail.com>
Date: Sat, 18 Jun 2022 14:43:02 +0300
Message-ID: <CAD+eXGR0gJH5UbrgE=5qvXaNgsRD+17tueooGdSY1NKPLcVrKw@mail.gmail.com>
Subject: Re: Security problem in how you manage users in package installations
To: Markus Kolb <alpinelinux+develml@tower-net.de>
Cc: Alpine Linux devel ML <~alpine/devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"

How would you improve this situation? Fail package installation if
user exists and is non-system (id >= 1000)?
How do other distros solve conflicts between admin's usernames and
service's usernames?

On Sat, Jun 18, 2022 at 1:00 PM Markus Kolb
<alpinelinux+develml@tower-net.de> wrote:
>
> 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