MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 21 Jun 2022 11:40:01 +0200
Message-Id: <CKVPO8VS853R.RB6HLE7BCCNO@sumire>
Cc: 
Subject: Re: Security problem in how you manage users in package
 installations
From: "alice" <alice@ayaya.dev>
To: "Markus Kolb" <alpinelinux+develml@tower-net.de>, "Jakub Jirutka"
 <jakub@jirutka.cz>, "Alpine Linux users ML"
 <~alpine/users@lists.alpinelinux.org>
References: <22948c2fba2f4882ac4646501fd6ef3f@tower-net.de>
 <cf311040-21f2-ad8b-4b9c-363f7ad0c9f5@jirutka.cz>
 <b1c1278d4461aaf940aea2d24c0e05d6@tower-net.de>
In-Reply-To: <b1c1278d4461aaf940aea2d24c0e05d6@tower-net.de>

On Tue Jun 21, 2022 at 10:59 AM CEST, Markus Kolb wrote:
> Am 19.06.2022 19:23, schrieb Jakub Jirutka:
> >> There is the possibility to allow an unintended (remote) login or=20
> >> local privilege expansion by unlocking users in apk-executed scripts.
> >=20
> > No, if the user already exists, then adduser(8) does nothing.
> >=20
>
> But passwd does. Unlocking is happening with passwd and not adduser.
> Not sure why you all point to adduser?!
because this was but a small confusion on the part of all of use, i
think, starting with my initial statement of:
>>>> which is how all of them are done
which was not referring to `passwd -u`, but the mere creation of the
user, via addgroup -S + adduser -S. the passwd -u is present in only 2
aports that i can see, and that is gitea and gogs, in all of aports. so,
understandably, everyone got confused when you claimed there is a
security issue with package installation overriding users in aports,
because the common case is only to *add* a user, and that *fails* if the
user exists, and so on. so, everyone points to adduser, assuming that is
what you meant.

of course, the passwd -u can have a legitimate, separate, claim- i don't
think anyone in this thread analysed that specifically yet.

there is indeed an issue if someone made a user on their machine, that
it would suddenly be unlocked; but this is not an issue of packaging,
but of documentation, as Laurent has pointed out. it would be good to
have a fallback- a check if the user already exists, and if it does, to
abort the unlock/creation entirely, for only these two aports.

as for why it's even there, it's because by default a -S system user
does not have the ability to log in via sshd with ssh-key.. but
unlocking a system user gives them the ability to authorize with
~/.ssh/authorized_keys (or the AuthorizedKeysFile setting), which is how
these git daemons give people ssh-access to repositories- everyone's
public keys via the web interface get added into whatever storage they
use, and the 'git' or 'gitea' or whoever user runs invoked via ssh to
then check the these acls for the key for grant access (many ways of
doing this). but the user must be able to run at all (as git@host or
similar), for which it has to be unlocked. (or maybe there's better ways
now? but gogs/gitea/git.sr.ht all do this to my knowledge, unless i am
incredibly mistaken)

and while it's unlocked, nobody can actually log in as the user- the
password is still blank (not sure if this counts as NULL?). iirc this
was also the issue behind CVE-2019-5021, where the PAM configuration at
the same time allowed people to log into NULL-password users, exactly in
a case like this.. but this was a combination of a) bad pam
configuration (correct me if i'm wrong) and b) having pam installed at
all, and login(or su?) provided by something that implements pam; which
*has* to also be manually installed, either via shadow-login or
util-linux-login- nothing in all of aports pulls these in, you must
install them yourself to get PAM utilities and gain the additional layer
of configuration.

> Can you all try to understand the problem and not try to avoid the=20
> explanations and saying all is fine like it is?!
this is a combination of people not fully analysing what this discussion
is about, and simultaneously the fact that this is ultimately not
actually that serious for the most part; even the most grave of the
possible issue above (existing user, unlocked unintentionally) is
horrifically difficult to actually exploit; it's not something that just
backdoors random machines on demand or whatnot, and you can't "target"
someone with such an attack, it's a reduction in security once someone
happens to install a package that conflicts and can't really do much else.

> It is not, you have a package in your repository, where you can get for=
=20
> sure a CVE entry for because of how it is installed by apk.
if you say it is 'for sure', then i await you getting it. not as a dare,
or anything, (and not even related to anything in this discussion), but
if you are that sure, then you know exactly where to go to validate your
own statements, and you *should* do so; there are not enough cve's in
the world :)

> This is all quite exhausting to discuss a problem like there is no=20
> problem and need to explain things not being part of.
> This is no help.