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.
Not sure why you all point to adduser?!
Can you all try to understand the problem and not try to avoid the 
explanations and saying all is fine like it is?!
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.

This is all quite exhausting to discuss a problem like there is no 
problem and need to explain things not being part of.
This is no help.

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 
> >> 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.
> 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 
> 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 
> 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 
> problem and need to explain things not being part of.
> This is no help.

On Tue, 21 Jun 2022 10:59:53 +0200
Markus Kolb <alpinelinux+develml@tower-net.de> 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.
> Not sure why you all point to adduser?!

Where/how is passwd used in apk-executed scripts?

-nc

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