MIME-Version: 1.0
Date: Sun, 19 Jun 2022 00:17:39 +0200
From: Markus Kolb <alpinelinux+develml@tower-net.de>
To: Alpine Linux devel ML <~alpine/devel@lists.alpinelinux.org>
Subject: Re: Security problem in how you manage users in package installations
In-Reply-To: <CAD+eXGR0gJH5UbrgE=5qvXaNgsRD+17tueooGdSY1NKPLcVrKw@mail.gmail.com>
References: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de>
 <CAD+eXGR0gJH5UbrgE=5qvXaNgsRD+17tueooGdSY1NKPLcVrKw@mail.gmail.com>
Message-ID: <49d7456930f237457bf7f3f5c50f96e4@tower-net.de>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

Am 18.06.2022 13:43, schrieb Konstantin Kulikov:
> 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?

Hi Konstantin,

this is not the direction I'd like to think about.
You can't rely on configurable settings (uid for users starting with 
1000 or the area where sys uids/gids are requested).

Some distros create system users only with predefined uid/gid. So if you 
want to create a user or group during package installation you request a 
fix uid/gid for usage and need to use special commands to create the 
user during build, not the admin commands.
Installation of the built package, in restricted build environments for 
audit, finds misbehaving installation procedures.
So scripts of packages may work on the files and directories of the 
package they belong to. Anything else should be part of distro's base 
packages or the package build system.

A first effective improvement would be, not to lower/remove restrictions 
of _any_ existing user in a kind of black box (installation script from 
admin perspective) during package installation.
Same proceeding would be good for file/directory permissions.
For this there should be also taken care in e.g. checkpath of 
openrc-scripts. If the admin locks out users of a directory and during 
the next service start by a checkpath the directory becomes world 
accessible again, might be a problem. IMO openrc should not modify or 
create anything by checkpath but simply report about the undesired 
mismatch and abort. But there is no such option in checkpath to only 
check. The modification is implied, the name of the function is 
misleading. It is a "fixpath".

I don't see a requirement for adding users like gitea/gogs to a 
website-content-group www-data. The hook scripts of the code 
repositories might be allowed to read files (e.g. htpasswd) of webserver 
environments they don't need to. If www-data group is used in multi-user 
environments for editing the website content by multiple users, hook 
scripts could modify group-writable files below /var/www. Who is aware 
of this when installing one of these packages?
I've found a commit comment from 2021 saying 20 aports would add its 
users to the www-data group... are these all webservers owning content 
under /var/www for delivering and I stumbled over the only two black 
sheep named above?
Will they stay out of the group if the admin remove them manually or are 
they put back in during the next fresh installation/update?
What is happening below /var/log, /var/run in all the packages over time 
if there is no check what packages are doing?

Btw. is it intended that you add user to the same group it has as 
primary group, so that it has ineffectively the same group 2 times?

I really don't know what should be done now with a package like gogs, 
which has up to now a walking through directory structure in Alpine 
where at least every user on the system can read the database with 
registered users, emails and hashed passwords. And any of these users 
with membership of www-data group could have modified the config file of 
the service and with changing repository path the code in repository 
could have been untrustworthy modified.
Default installations need to be fixed here, but it is not foreseeable 
what configuration changes has been done on all the installations out 
there. Overwriting this more restrictive and safe can break 
installations using a different, custom configuration and directory 
structure.
There could be provided an output to the user during the installation 
about the changes. In other distributions there would be a confirmation 
dialog.
How this should be done in Alpine?