Re: usrmerge breaks POSIX

[Thorsten Glaser]

reopen 1063905
severity 1063905 wishlist
retitle 1063905 mksh: add /usr/bin/mksh{,-static} to /etc/shells
tags 1063905 + pending
found 1063905 59c-23
# well /usr/bin/mksh, /usr/bin/mksh-static is not, see below
notfound 1063905 59c-22
thanks

Russ Allbery dixit:

>After some research with git blame, it appears that pkexec checks SHELL
>against /etc/shells because pkexec passes SHELL to the program that it
>executes (possibly in a different security context) and was worried about
>users being able to manipulate and potentially compromise programs across
>that security boundary by setting SHELL to some attacker-controlled value.

Ah okay, that makes sense.

>It is using /etc/shells as a list of possible valid values for that
>variable that are safe to pass on.

That… is probably not a bad guess, yes…

Thank you for going into this kind of extra research.
So I guess I’ll explicitly add this on the next sid upload
and I guess also have to ask about a fix in stable-p-u as
bookworm also requires this filesystem layout. The package
in bullseye used add-shell which (on merged-usr) introduced…

/bin/mksh
/usr/bin/mksh
/bin/mksh-static
/usr/lib/klibc/bin/mksh-static

… hmm. These. The forth one is the bogus one which caused
piuparts failure and was what got me to add code to work
around this add-shell misbehaviour in the first place. Is
this (I’m handling this as a feature request for inter‐
operability with some unrelated software in the presence
of the UsrMove filesystem layout) relevant enough to also
get this changed (by cherry-picking the maintainer script
change) to o-p-u? (Any SRMs reading this, feel free to say,
otherwise I’ll just use the normal reportbug way.)

If so, I’m thinking of checking whether the /usr/bin/ paths
exist and resolve to the same files as the /bin/ paths, so
the /usr/bin/ ones wouldn’t get added to FHS/FSSTND systems.
This runs in postinst, so dpkg-reconfigure would suffice to
update it, but AIUI the usrmerge package also adds shells.

(Note that, unlike add-shell and the newer update-shells, my
maintainer script code handles the local admin commenting out
lines and will not reintroduce them. This would count these
paths as distinct though, but I guess that one migrates the
filesystem layout only once anyway.)

There is also /bin/rmksh but that is deliberately not added
to /etc/shells so far. I’ve no idea why bash and ksh93 differ.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 16:30:25 -0800, Russ Allbery wrote:
> I was only able to find this discussion of why pkexec checks $SHELL, and
> it doesn't support my assumption that it was an intentional security
> measure, so I may well be wrong in that part of my analysis.  Apologies
> for that; I clearly should have done more research.  git blame points to a
> commit that only references this thread:
> 
> https://lists.freedesktop.org/archives/polkit-devel/2009-December/000282.html
> 
> which seems to imply that this was done to match sudo behavior and because
> the author believed this was the right way to validate the SHELL setting.

This is the kind of information that should have been put as a comment
in the source code. But the pkexec code seems to be buggy because sudo
does *not* check that the $SHELL value is in /etc/shells?

In the sudo(8) man page:

  -s, --shell
 Run the shell specified by the SHELL environment variable if it
 is set or the shell specified by the invoking  user's  password
 database entry. [...]
[...]
  SHELLUsed to determine shell to run with -s option.

and there is no mention of /etc/shells.

/etc/shells is mentioned in sudoers(5):

  runas_check_shell
If enabled, sudo will only run  commands  as  a  user
whose  shell appears in the /etc/shells file, even if
the invoking user's Runas_List would otherwise permit
it. [...]

So this concerns the login shell of the target user, not the $SHELL
value. This is confirmed by the sudo source:

/*
 * Returns true if the user's shell is considered to be valid.
 */
bool
user_shell_valid(const struct passwd *pw)
{
debug_decl(user_shell_valid, SUDOERS_DEBUG_NSS);

if (!def_runas_check_shell)
debug_return_bool(true);

debug_return_bool(valid_shell(pw->pw_shell));
}

where valid_shell() does

while ((entry = CALL(getusershell)()) != NULL) {
if (strcmp(entry, shell) == 0)
debug_return_bool(true);
}

But chsh will set the login shell to a pathname from /etc/shells,
so that there are no issues with aliases pathnames in this case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 16:17:58 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
> 
> >> and pkexec is essentially a type of sudo and should be unavailable to
> >> anyone who is using a restricted shell.
> 
> > The pkexec source doesn't say that the goal is to check whether
> > the user is in a restricted shell.
> 
> So far as I am aware, the only purpose served by /etc/shells historically
> and currently is to (a) prevent users from shooting themselves in the foot
> by using chsh to change their shell to something that isn't a shell, and
> (b) detect users who are not "normal users" and therefore should have
> restricted access to system services.  See shells(5), for example:
> 
> Be aware that there are programs which consult this file to find out
> if a user is a normal user; for example, FTP daemons traditionally
> disallow access to users with shells not included in this file.

But note that checking the login shell of the user in /etc/shells
(which seems OK for me) is different from checking the value of
$SHELL.

> > Also note than even in a restricted shell, the user may set $SHELL to a
> > non-restricted shell.
> 
> This is generally not the case; see, for example, rbash(1):
> 
> It behaves identically to bash with the exception that the following
> are disallowed or not performed:
> 
> [...]
> 
> * setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or
>   BASH_ENV

Well, SHELL is read-only. But a restricted shell can be started
with a $SHELL value that doesn't point to a restricted shell:

$ echo $SHELL
/bin/sh
$ rbash -l
vinc17@qaa:~$ echo $SHELL
/bin/sh

So, making decisions based on the $SHELL value is prone to
security issues, and I think that it would be better to look
at the login shell in /etc/shells.

> > Moreover, /etc/shells also contains restricted shells.
> 
> That definitely should not be the case and any restricted shell that adds
> itself to /etc/shells is buggy.  See chsh(1):
> 
> The only restriction placed on the login shell is that the command
> name must be listed in /etc/shells, unless the invoker is the
> superuser, and then any value may be added. An account with a
> restricted login shell may not change her login shell. For this
> reason, placing /bin/rsh in /etc/shells is discouraged since
> accidentally changing to a restricted shell would prevent the user
> from ever changing her login shell back to its original value.

On my machine, both rbash and rksh93 are in /etc/shells.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Russ Allbery]

Russ Allbery  writes:
> Thorsten Glaser  writes:

>> Right… and why does pkexec check against /etc/shells?

> pkexec checks against /etc/shells because this is the traditional way to
> determine whether the user is in a restricted shell, and pkexec is
> essentially a type of sudo and should be unavailable to anyone who is
> using a restricted shell.

Apologies, this turns out to be incorrect.  I assumed this based on my
prior experience with other programs that tested /etc/shells without doing
my research properly.  I should have been less certain here.

After some research with git blame, it appears that pkexec checks SHELL
against /etc/shells because pkexec passes SHELL to the program that it
executes (possibly in a different security context) and was worried about
users being able to manipulate and potentially compromise programs across
that security boundary by setting SHELL to some attacker-controlled value.
It is using /etc/shells as a list of possible valid values for that
variable that are safe to pass on.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Russ Allbery]

Russ Allbery  writes:

> That definitely should not be the case and any restricted shell that adds
> itself to /etc/shells is buggy.  See chsh(1):

> The only restriction placed on the login shell is that the command
> name must be listed in /etc/shells, unless the invoker is the
> superuser, and then any value may be added. An account with a
> restricted login shell may not change her login shell. For this
> reason, placing /bin/rsh in /etc/shells is discouraged since
> accidentally changing to a restricted shell would prevent the user
> from ever changing her login shell back to its original value.

To follow up on this, currently rbash is added to /etc/shells, which is
surprising to me and which I assume is what you were referring to.  This
seems directly contrary to the chsh advice.  I can't find a reference to
this in bash's changelog and am not sure the reasons for this, though, so
presumably I'm missing something.

I was only able to find this discussion of why pkexec checks $SHELL, and
it doesn't support my assumption that it was an intentional security
measure, so I may well be wrong in that part of my analysis.  Apologies
for that; I clearly should have done more research.  git blame points to a
commit that only references this thread:

https://lists.freedesktop.org/archives/polkit-devel/2009-December/000282.html

which seems to imply that this was done to match sudo behavior and because
the author believed this was the right way to validate the SHELL setting.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Russ Allbery]

Vincent Lefevre  writes:
> On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:

>> and pkexec is essentially a type of sudo and should be unavailable to
>> anyone who is using a restricted shell.

> The pkexec source doesn't say that the goal is to check whether
> the user is in a restricted shell.

So far as I am aware, the only purpose served by /etc/shells historically
and currently is to (a) prevent users from shooting themselves in the foot
by using chsh to change their shell to something that isn't a shell, and
(b) detect users who are not "normal users" and therefore should have
restricted access to system services.  See shells(5), for example:

Be aware that there are programs which consult this file to find out
if a user is a normal user; for example, FTP daemons traditionally
disallow access to users with shells not included in this file.

> Also note than even in a restricted shell, the user may set $SHELL to a
> non-restricted shell.

This is generally not the case; see, for example, rbash(1):

It behaves identically to bash with the exception that the following
are disallowed or not performed:

[...]

* setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or
  BASH_ENV

> Moreover, /etc/shells also contains restricted shells.

That definitely should not be the case and any restricted shell that adds
itself to /etc/shells is buggy.  See chsh(1):

The only restriction placed on the login shell is that the command
name must be listed in /etc/shells, unless the invoker is the
superuser, and then any value may be added. An account with a
restricted login shell may not change her login shell. For this
reason, placing /bin/rsh in /etc/shells is discouraged since
accidentally changing to a restricted shell would prevent the user
from ever changing her login shell back to its original value.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
> Thorsten Glaser  writes:
> 
> > Right… and why does pkexec check against /etc/shells?
> 
> pkexec checks against /etc/shells because this is the traditional way to
> determine whether the user is in a restricted shell,

Could you explain? This seems an orthogonal problem.

> and pkexec is essentially a type of sudo and should be unavailable
> to anyone who is using a restricted shell.

The pkexec source doesn't say that the goal is to check whether
the user is in a restricted shell. Also note than even in a
restricted shell, the user may set $SHELL to a non-restricted
shell. Moreover, /etc/shells also contains restricted shells.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Peter Pentchev]

On Thu, Feb 15, 2024 at 10:34:32PM +, Thorsten Glaser wrote:
> Russ Allbery dixit:
> 
> >Thorsten Glaser  writes:
> >
> >> Right… and why does pkexec check against /etc/shells?
> >
> >pkexec checks against /etc/shells because this is the traditional way to
> >determine whether the user is in a restricted shell, and pkexec is
> >essentially a type of sudo and should be unavailable to anyone who is
> >using a restricted shell.
> 
> Ah okay, makes sense…ish (sudo does not check this).

It does if one configures it to by setting runas_check_shell to true.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: usrmerge breaks POSIX

[Thorsten Glaser]

Russ Allbery dixit:

>Thorsten Glaser  writes:
>
>> Right… and why does pkexec check against /etc/shells?
>
>pkexec checks against /etc/shells because this is the traditional way to
>determine whether the user is in a restricted shell, and pkexec is
>essentially a type of sudo and should be unavailable to anyone who is
>using a restricted shell.

Ah okay, makes sense…ish (sudo does not check this).

So maybe extend that check by comparing realpath(2)s, to support
usrmerge? Or… no, wait, that won’t work when the restricted shell
is a symlink to the normal one.

Yeah, I can a little see why this wouldn’t work :/

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Re: usrmerge breaks POSIX

[Russ Allbery]

Thorsten Glaser  writes:

> Right… and why does pkexec check against /etc/shells?

pkexec checks against /etc/shells because this is the traditional way to
determine whether the user is in a restricted shell, and pkexec is
essentially a type of sudo and should be unavailable to anyone who is
using a restricted shell.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Thorsten Glaser]

Russ Allbery dixit:

>It does check whether $SHELL is found in /etc/shells.  So your question
>about what is setting the $SHELL variable is a good one, although I think
>I would still argue that it's not the most effective way to solve the
>issue.

Right… and why does pkexec check against /etc/shells?

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 17:18:43 +, Thorsten Glaser wrote:
> Russ Allbery dixit:
> 
> >3. Something else that I don't yet understand happened that caused pkexec
> >   to detect the shell as /usr/bin/mksh instead of /bin/mksh.  I'm not
> 
> What sets $SHELL for the reporter’s case? Fix that instead.

$SHELL is meant to be set by the user. To set $SHELL to the
current shell, for instance, the result with mksh:

$ SHELL=$(readlink /proc/$$/exe)
$ echo $SHELL
/usr/bin/mksh

And I suppose that /usr/bin/mksh comes from the "real path".

> login(1) sets it to the path from passwd(5), which hopefully
> is from shells(5).

login(1) is not the only way to start a shell.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Russ Allbery]

Thorsten Glaser  writes:
> Dixi quod…
>> Russ Allbery dixit:

>>> My guess is that pkexec is calling realpath to canonicalize the path
>>> before checking for it in /etc/shells, although I have not confirmed
>>> this.

>> Now that would be weird and should be fixed…

> Another question that probably should be answered first is that why
> pkexec (whatever that is) checks against /etc/shells and if that’s
> correct.

Okay, I have done more research.  My speculation that pkexec might use
realpath was wrong.  It does only check the contents of the SHELL
environment variable.  See:

https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/programs/pkexec.c?ref_type=heads#L343
https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/programs/pkexec.c?ref_type=heads#L405

It does check whether $SHELL is found in /etc/shells.  So your question
about what is setting the $SHELL variable is a good one, although I think
I would still argue that it's not the most effective way to solve the
issue.

> I’d be really appreciative if I did not have to add extra nōn-canonical
> paths to /etc/shells for bugs in unrelated software.

I understand the appeal of that stance, but the problem with it is that
there is no enforcement of this definition of canonical.  I know that you
consider /bin/mksh to be the correct path, but /usr/bin/mksh is also
present and works exactly the same.  chsh will prevent unprivileged users
from changing their shell to the /usr/bin path because of /etc/shells, but
not if someone makes that change as root.  Also, I'm not sure useradd
cares, or possibly other ways of adding a user with a shell (Puppet, for
instance).  Or, for that matter, just editing /etc/passwd as root, which I
admit is how I usually set the shells of users because I've been using
UNIX for too long.

Having only the /bin paths is fragile because it creates an expectation
that every user who sets the shell is going to know that /bin/mksh is the
correct path and /usr/bin/mksh is the wrong path and will not use the
latter.  I'm not sure how they're supposed to receive this information; I
don't think it's going to be obvious to everyone who may be involved in
setting the shell.  We can tell everyone who ends up with /usr/bin/mksh
that they need to change it to /bin/mksh, but this seems kind of tedious
and annoying, and I'm not seeing the downside to registering both paths.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Thorsten Glaser]

Dixi quod…

>Russ Allbery dixit:
>
>>> What sets $SHELL for the reporter’s case? Fix that instead.  login(1)
>>> sets it to the path from passwd(5), which hopefully is from shells(5).
>>
>>My guess is that pkexec is calling realpath to canonicalize the path
>>before checking for it in /etc/shells, although I have not confirmed this.
>
>Now that would be weird and should be fixed…

Another question that probably should be answered first is
that why pkexec (whatever that is) checks against /etc/shells
and if that’s correct.

On systems where I don’t have root, I tend to install things
including a shell into ~/.etc/bin/ and then ofc also put it
in $SHELL… for GNU screen.

I’d be really appreciative if I did not have to add extra
nōn-canonical paths to /etc/shells for bugs in unrelated
software.

Thanks,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Re: usrmerge breaks POSIX

[Thorsten Glaser]

Russ Allbery dixit:

>> What sets $SHELL for the reporter’s case? Fix that instead.  login(1)
>> sets it to the path from passwd(5), which hopefully is from shells(5).
>
>My guess is that pkexec is calling realpath to canonicalize the path
>before checking for it in /etc/shells, although I have not confirmed this.

Now that would be weird and should be fixed…

>Regardless, I think we should list both paths in /etc/shells because both
>paths are valid and there are various benign reasons why one might see the
>other path.

For the record, I don’t agree with this, and /bin/mksh{,-static} are
the canonical paths.

I might add them in the next upload to keep peace, though… *sigh*

bye,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D

Re: usrmerge breaks POSIX

[Bill Allombert]

Le Thu, Feb 15, 2024 at 05:18:43PM +, Thorsten Glaser a écrit :
> Russ Allbery dixit:
> 
> >3. Something else that I don't yet understand happened that caused pkexec
> >   to detect the shell as /usr/bin/mksh instead of /bin/mksh.  I'm not
> 
> What sets $SHELL for the reporter’s case? Fix that instead.
> login(1) sets it to the path from passwd(5), which hopefully
> is from shells(5).

I assume Vincent set $SHELL manually, which ought to be supported ?
Not sure I see why programs need to check /etc/shells in the first
place.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: usrmerge breaks POSIX

[Russ Allbery]

Thorsten Glaser  writes:
> Russ Allbery dixit:

>> 3. Something else that I don't yet understand happened that caused pkexec
>>to detect the shell as /usr/bin/mksh instead of /bin/mksh.  I'm not

> What sets $SHELL for the reporter’s case? Fix that instead.  login(1)
> sets it to the path from passwd(5), which hopefully is from shells(5).

My guess is that pkexec is calling realpath to canonicalize the path
before checking for it in /etc/shells, although I have not confirmed this.

Regardless, I think we should list both paths in /etc/shells because both
paths are valid and there are various benign reasons why one might see the
other path.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Thorsten Glaser]

Russ Allbery dixit:

>3. Something else that I don't yet understand happened that caused pkexec
>   to detect the shell as /usr/bin/mksh instead of /bin/mksh.  I'm not

What sets $SHELL for the reporter’s case? Fix that instead.
login(1) sets it to the path from passwd(5), which hopefully
is from shells(5).

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 09:00:57 -0800, Russ Allbery wrote:
> I think the obvious solution is to ensure that both the /bin and /usr/bin
> paths for mksh are registered in /etc/shells.  In other words, I think we
> have a missing usrmerge-related transition here that we should just fix.
> I'm copying Thorsten on this message in case he hasn't noticed this
> thread, but if I were you I'd just file a bug against mksh asking for the
> /usr/bin paths to also be added to /etc/shells to match the new behavior
> of add-shell.

I had reported a bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063905

but Thorsten closed it because

|The OP’s $SHELL should not be set to /usr/bin/bash as that
|value is not in /etc/shells and not its canonical path in
|the first place.

(The issue was initially detected with bash, which gave bug 817168.)

But having a requirement on what pathnames $SHELL may contain (in the
case a same shell can be referenced by several pathnames, e.g. due to
the /bin -> /usr/bin symbolic link) is not acceptable. Hence my post
about this.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 16:59:28 +, Holger Levsen wrote:
> On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> > Not for mksh.
>  
> so the subject should be "mksh is broken with usrmerge"?

No, because my bug report about mksh was closed because it is
not regarded as a bug in mksh.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Russ Allbery]

Vincent Lefevre  writes:
> On 2024-02-14 17:16:23 -0800, Russ Allbery wrote:

> Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

> | with usrmerge, some programs - such as pkexec, or LEAP's bitmask
> | on top of that- fails to run. Specifically, the error I get is:
> |
> | The value for the SHELL variable was not found the /etc/shells file

>> You mentioned /etc/shells in your previous message, but /etc/shells on my
>> system contains both the /usr/bin and the /bin paths, so I'm still at a
>> complete loss.

> Not for mksh.

Okay, thank you.  I think I understand now.  The problem is:

1. mksh uses custom postinst code to add itself to /etc/shells that does
   not add the /usr/bin versions of the mksh paths, only the /bin
   versions.

2. pkexec uses /etc/shells as an authorization mechanism to not allow
   access from people who use restricted shells, so if it detects your
   shell as /usr/bin/mksh instead of the (expected by /etc/shells)
   /bin/mksh path, it will deny access.

3. Something else that I don't yet understand happened that caused pkexec
   to detect the shell as /usr/bin/mksh instead of /bin/mksh.  I'm not
   sure what this is, but I can guess at a few things that could cause
   this, so it's not surprising to me that it happened.

That pkexec uses /etc/shells in this way is a bit surprising, but I
understand the goal.  The intent is to keep people who are using
restricted shells from accessing pkexec.  I'm not sure this is the best
way to achieve that security goal, but I can also see the potential for
introducing security vulnerabilities in existing systems if we relaxed
them now.

I think the obvious solution is to ensure that both the /bin and /usr/bin
paths for mksh are registered in /etc/shells.  In other words, I think we
have a missing usrmerge-related transition here that we should just fix.
I'm copying Thorsten on this message in case he hasn't noticed this
thread, but if I were you I'd just file a bug against mksh asking for the
/usr/bin paths to also be added to /etc/shells to match the new behavior
of add-shell.

Hopefully most shells are using add-shell, and thus won't have this
problem, but any other shell package in Debian that is intended to provide
a non-restricted shell but is not using add-shell to manipulate
/etc/shells will need a similar fix.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Holger Levsen]

On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> Not for mksh.
 
so the subject should be "mksh is broken with usrmerge"?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„Never argue with an idiot. They will drag you down to their level and beat
 you with experience.“ (Mark Twain)


signature.asc
Description: PGP signature

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 09:39:51 +0100, Marc Haber wrote:
> On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre
>  wrote:
> >This is invalid. See
> >
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
> 
> That doesnt answer the question asked, it is a bug from 2016 that was
> fixed since then, and I am one of those who fails to see the
> connection between the subject of this thread and the nebulous claims
> you make in the messages AND obviously refuse to explain your
> reasoning if asked.

There's no indication that the bug in pkexec has been fixed.
Bug 817168 just implemented a workaround in add-shell, which
is not used by mksh.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 17:16:23 -0800, Russ Allbery wrote:
> I have literally no idea what you're talking about.  It would be really
> helpful if you would describe what program rejected your setting and what
> you expected to happen instead.

Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

| with usrmerge, some programs - such as pkexec, or LEAP's bitmask
| on top of that- fails to run. Specifically, the error I get is:
|
| The value for the SHELL variable was not found the /etc/shells file

> You mentioned /etc/shells in your previous message, but /etc/shells on my
> system contains both the /usr/bin and the /bin paths, so I'm still at a
> complete loss.

Not for mksh.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Marc Haber]

On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre
 wrote:
>This is invalid. See
>
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

That doesnt answer the question asked, it is a bug from 2016 that was
fixed since then, and I am one of those who fails to see the
connection between the subject of this thread and the nebulous claims
you make in the messages AND obviously refuse to explain your
reasoning if asked.

Russ and Ansgar are among the brightest people in Debian, so if they
don't understand what you mean, I suggest answering their question
instead of throwing more fog.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: usrmerge breaks POSIX

[Russ Allbery]

Vincent Lefevre  writes:
> On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:

>> I'm sorry, this is probably a really obvious question, but could you
>> explain the connection between the subject of your mail message and the
>> body of your mail message?  I can't see any relationship, so I guess I
>> need it spelled out for me in small words.

>> (I believe /etc/shells enforcement is done via PAM or in specific
>> programs that impose this as an additional non-POSIX restriction.  This
>> is outside the scope of POSIX.)

> What's the point of having a standard if programs are allowed to
> reject user settings for arbitrary and undocumented reasons?

I have literally no idea what you're talking about.  It would be really
helpful if you would describe what program rejected your setting and what
you expected to happen instead.

You mentioned /etc/shells in your previous message, but /etc/shells on my
system contains both the /usr/bin and the /bin paths, so I'm still at a
complete loss.

-- 
Russ Allbery (r...@debian.org)  

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > POSIX says:
> 
> >   SHELL   This variable shall represent a pathname of the user's
> >   preferred command language interpreter. If this interpreter
> >   does not conform to the Shell Command Language in XCU
> >   Chapter 2 (on page 2345), utilities may behave differently
> >   from those described in POSIX.1-2017.
> 
> > There is no requirement to match one of the /etc/shells pathnames.
> > The user or scripts should be free to use any arbitrary pathname to
> > the command language interpreter available on the system, and Debian
> > should ensure that this is allowed, in particular the one give by
> > the realpath command.
> 
> I'm sorry, this is probably a really obvious question, but could you
> explain the connection between the subject of your mail message and the
> body of your mail message?  I can't see any relationship, so I guess I
> need it spelled out for me in small words.
> 
> (I believe /etc/shells enforcement is done via PAM or in specific
> programs that impose this as an additional non-POSIX restriction.  This is
> outside the scope of POSIX.)

What's the point of having a standard if programs are allowed to
reject user settings for arbitrary and undocumented reasons?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 19:46:58 +0100, Ansgar  wrote:
> Hi Vincent,
> 
> On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> > POSIX says:
> > 
> >   SHELL   This variable shall represent a pathname of the user's
> >   preferred command language interpreter. If this interpreter
> >   does not conform to the Shell Command Language in XCU
> >   Chapter 2 (on page 2345), utilities may behave differently
> >   from those described in POSIX.1-2017.
> > 
> > There is no requirement to match one of the /etc/shells pathnames.
> 
> I have hopefully good news for you! You can set the SHELL variable
> yourself to your preferred value. For example:
> 
> export SHELL=/home/user/.bin/the-best-shell-of-all
> 
> (The details might vary depending on the shell you are currently in.)
> usrmerge does not affect this at all.

This is invalid. See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Ansgar ]

Hi Vincent,

On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> POSIX says:
> 
>   SHELL   This variable shall represent a pathname of the user's
>   preferred command language interpreter. If this interpreter
>   does not conform to the Shell Command Language in XCU
>   Chapter 2 (on page 2345), utilities may behave differently
>   from those described in POSIX.1-2017.
> 
> There is no requirement to match one of the /etc/shells pathnames.

I have hopefully good news for you! You can set the SHELL variable
yourself to your preferred value. For example:

export SHELL=/home/user/.bin/the-best-shell-of-all

(The details might vary depending on the shell you are currently in.)
usrmerge does not affect this at all.

Ansgar

Re: usrmerge breaks POSIX

[Russ Allbery]

Vincent Lefevre  writes:

> POSIX says:

>   SHELL   This variable shall represent a pathname of the user's
>   preferred command language interpreter. If this interpreter
>   does not conform to the Shell Command Language in XCU
>   Chapter 2 (on page 2345), utilities may behave differently
>   from those described in POSIX.1-2017.

> There is no requirement to match one of the /etc/shells pathnames.
> The user or scripts should be free to use any arbitrary pathname to
> the command language interpreter available on the system, and Debian
> should ensure that this is allowed, in particular the one give by
> the realpath command.

I'm sorry, this is probably a really obvious question, but could you
explain the connection between the subject of your mail message and the
body of your mail message?  I can't see any relationship, so I guess I
need it spelled out for me in small words.

(I believe /etc/shells enforcement is done via PAM or in specific
programs that impose this as an additional non-POSIX restriction.  This is
outside the scope of POSIX.)

-- 
Russ Allbery (r...@debian.org)  

usrmerge breaks POSIX

[Vincent Lefevre]

POSIX says:

  SHELL   This variable shall represent a pathname of the user's
  preferred command language interpreter. If this interpreter
  does not conform to the Shell Command Language in XCU
  Chapter 2 (on page 2345), utilities may behave differently
  from those described in POSIX.1-2017.

There is no requirement to match one of the /etc/shells pathnames.
The user or scripts should be free to use any arbitrary pathname to
the command language interpreter available on the system, and Debian
should ensure that this is allowed, in particular the one give by
the realpath command.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)