private-bin and custom user shells

[kmk3]

(Continued from #4783 (comment))

@rusty-snake on Dec 19:

IIRC this is because firejail hardcodes bash as the default shell.

It don't, read the issues title in your comment:

• Default shell is guessed from $SHELL, despite manpage specifying
  /bin/bash

On Artix it fails, but I'm not sure why:

If I get you right (sh->dash; getent passwd $USER | cut -d: -f7: bash), you
try to start a program (bash) which isn't inside the sandbox.

IMHO --shell=none should be the default (if you specify a program).

So in my case it does require private-bin bash, even though /bin/sh is
/bin/dash.

Because you still run bash inside the sandbox and it isn't present (as a
side-effect).

Ah, indeed /bin/sh is dash, while bash is the user shell.

@rusty-snake on Dec 19:

What I want to tell is that private-bin=sh will copy/bind-mount sh and
the program it points to (e.g. bash or dash). No matter if you list
bash/dash or not.

I don't care about /bin/sh pointing to somewhere else (e.g.
/mnt/extra-program/mysh).

Nice, I didn't know firejail did that. That (and also a lot of testing)
explains a lot, thanks.

Interestingly, while testing this, I noticed that I still cannot execute
anything in /bin even if /bin/sh and the shell it points to are in private-bin:

$ readlink /bin/sh
dash
$ getent passwd "$USER" | cut -f 7 -d :
/bin/bash
$ firejail --quiet --noprofile --private-bin=ls ls /bin
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=dash,ls,sh ls /bin
Cannot start application: No such file or directory

In fact, /bin/sh and the shell it points to appear to make no difference. It
only works if the user shell is added to private-bin:

$ readlink /bin/sh
dash
$ getent passwd "$USER" | cut -f 7 -d :
/bin/bash
$ firejail --quiet --noprofile --private-bin=bash,ls ls /bin
bash  ls

This is rather surprising behavior and it seems to have been reported before:

@heinrich5991 commented on Jun 3, 2020:

It's unexpected for me that firejail calls the shell btw.

Just to rule out this being related to dynamic linking, I also tried with
busybox, which is supposed to be statically linked (and so should not depend on
anything on /bin), with the same results:

$ readlink /bin/sh
dash
$ getent passwd "$USER" | cut -f 7 -d :
/bin/bash
$ pacman -Qo /bin/busybox
/usr/bin/busybox is owned by busybox 1.34.1-1
$ file /bin/busybox
/bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
$ firejail --quiet --noprofile --private-bin=busybox \
  busybox --help | head -n 1
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=dash,busybox,sh \
  busybox --help | head -n 1
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=bash,busybox \
  busybox --help | head -n 1
BusyBox v1.34.1 () multi-call binary.

This means that if /bin/sh and the user shell are the same, then
private-bin sh should be enough. Example with both pointing to /bin/dash:

# readlink /bin/sh
dash
# getent passwd fjtest | cut -f 7 -d :
/bin/dash
# su - fjtest
su: warning: cannot change directory to /home/fjtest: No such file or directory
$ firejail --quiet --noprofile --private-bin=sh sh -c 'echo yes'
yes

---

Misc: Other examples using dash for both for completeness:

# readlink /bin/sh
dash
# getent passwd fjtest | cut -f 7 -d :
/bin/dash
# su - fjtest
su: warning: cannot change directory to /home/fjtest: No such file or directory
$ firejail --quiet --noprofile --private-bin=ls ls /bin
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=ls,sh ls /bin
dash  ls  sh
$ firejail --quiet --noprofile --private-bin=ls,dash ls /bin
dash  ls
$ firejail --quiet --noprofile --private-bin=busybox \
  busybox --help | head -n 1
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=dash,busybox \
  busybox --help | head -n 1
BusyBox v1.34.1 () multi-call binary.

---

But if the following are true:

• /bin/sh and the user shell are different (say, dash and bash)
• private-bin only includes sh, but not the user shell

Then it seems that the user shell has to be present on every private-bin
entry or else private-bin would have to be disabled to avoid breakage, such
as by e.g.: adding ignore private-bin to globals.local.

So going back to the original review comment:

@rusty-snake on Dec 19:

 shell none
 
 disable-mnt
-private-bin telegram,Telegram,telegram-desktop
+private-bin bash,sh,telegram,Telegram,telegram-desktop,xdg-open

Why bash?

xdg-open is a shell-script, consider
sed,xdg-mime,which,mimeopen,grep,egrep,printf,cut,uname,dbus-send,xprop,dirname,cat,…,
exo-open,gio,gvfs-open,mate-open,enlightenment_open,gnome-open,dde-open,kde-open,kde-open\*,kfmclient,cygstart,kde-config,gnome-default-applications-properties,…
or just drop private-bin.

It seems that currently it would be better to use private-bin bash,dash,sh
rather than just private-bin sh to prevent breakage. I don't know of any
distro that uses something other than dash or bash as /bin/sh and as the
default user shell, so this should at least cover the cases where the user
changes neither /bin/sh or the user shell to something other than those two
shells.

But note the two shells are not enough, as /bin/sh may point to any POSIX shell
and the user shell can be anything from ksh, to zsh, to even a non-POSIX shell
like fish. See #2934 for a previous discussion.

So I have a few questions:

• Why is it that when the user shell is not in the sandbox, executing anything
  in (/usr)/bin fails?
• Is that intended behavior?

If it is intended behavior (or if it would take a lot to fix), then how about
doing something like this:

If private-bin sh is found, add the user shell to private-bin (similarly to
how what /bin/sh points to is also added to private-bin).

Relates to:

• join fails with private-bin and an alternate (non-bash/sh) shell as default #2934
• Default shell is guessed from $SHELL, despite manpage specifying /bin/bash #3434
• --private-bin=something does not seem to work #3448

Possibly relevant:

• join: add fexecve fallback for shells #3850

Cc: @smitsohu (from #2934/#3850)

[rusty-snake]

If private-bin sh is found, add the user shell to private-bin (similarly to
how what /bin/sh points to is also added to private-bin).

Instead of hard-coding stuff like that I always prefer to add features to profiles. Here for example private-bin sh,${SHELL},foo,bar.

Why is it that when the user shell is not in the sandbox, executing anything
in (/usr)/bin fails?

Because $SHELL -c "<COMMAND>" fails if $SHELL does not exist. You need to add $SHELL to the sandbox or start it with shell none (which should be the default IMHO).

Then it seems that the user shell has to be present on every private-bin
entry or else private-bin would have to be disabled to avoid breakage, such
as by e.g.: adding ignore private-bin to globals.local.

If the program starts subprograms like $SHELL -c "foobar" then yes, otherwise I wouldn't say it is a problem.

[kmk3]

@rusty-snake on Dec 23:

If private-bin sh is found, add the user shell to private-bin (similarly to
how what /bin/sh points to is also added to private-bin).

Instead of hard-coding stuff like that I always prefer to add features to
profiles. Here for example private-bin sh,${SHELL},foo,bar.

I like the simplicity of environment variables, but I have a few concerns:

Would ${SHELL} refer to the environment variable or to the user shell? If
the former, then the env var and the shell currently being used may differ from
the user shell. If the latter, then it's kind of confusing because it looks
like it would refer to the environment variable.

Anyway, I suggested hardcoding mainly because the current behavior does not
make sense to me (see below) and either way I'd like to understand why it
happens.

Why is it that when the user shell is not in the sandbox, executing
anything in (/usr)/bin fails?

Because $SHELL -c "<COMMAND>" fails if $SHELL does not exist. You need to
add $SHELL to the sandbox or start it with shell none (which should be
the default IMHO).

I can see why it would fail for that invocation, but as I mentioned in the OP,
what is puzzling is that it fails when trying to directly execute any program
in (/usr)/bin (i.e.: without going through a shell):

$ readlink /bin/sh
dash
$ getent passwd "$USER" | cut -f 7 -d :
/bin/bash
$ firejail --quiet --noprofile --private-bin=ls ls /bin
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=dash,ls,sh ls /bin
Cannot start application: No such file or directory

---

Then it seems that the user shell has to be present on every private-bin
entry or else private-bin would have to be disabled to avoid breakage, such
as by e.g.: adding ignore private-bin to globals.local.

If the program starts subprograms like $SHELL -c "foobar" then yes,
otherwise I wouldn't say it is a problem.

The main point is that firejail does not work at all if private-bin is used
and it does not include the user shell:

$ firejail --quiet --noprofile --private --private-bin=firefox firefox
Cannot start application: No such file or directory
$ cat /usr/bin/firefox
#!/bin/sh
exec /usr/lib/firefox/firefox "$@"
$ file /usr/lib/firefox/firefox
/usr/lib/firefox/firefox: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.0, BuildID[sha1]=96714e39953a76667c94be352a14f38f52876c4f, stripped
$ firejail --quiet --noprofile --private --private-bin=firefox /usr/lib/firefox/firefox
Cannot start application: No such file or directory

It doesn't matter if you pass $SHELL -c program to firejail or if you pass
just program, the results are the same. It also doesn't matter if the
program itself would eventually call a shell or not, as the program does not
even get executed.

So why does the above fail?

Note: I assume that firejail invokes the program directly through something
like execve(3p) (rather than e.g.: system(3p)) and that the exec family of
functions do not depend on any shell being present.

[rusty-snake]

If the latter, then it's kind of confusing because it looks
like it would refer to the environment variable.

Yes the latter.

Our current macros (${HOME}, ${PATH}, ${DOWNLOADS}, ...) work exactly the same as ${SHELL} would work. ${HOME} does not use a getenv like function, it uses getpwuid like function:

HOME=/root firejail --noprofile --blacklist='${HOME}/Downloads' ls -ld "$(getent passwd $USER | cut -d: -f6)/Downloads"
dr--------. 2 root root 40 15. Dez 22:54 /home/rusty-snake/Downloads

[rusty-snake]

without going through a shell

$ readlink /bin/sh
dash
$ getent passwd "$USER" | cut -f 7 -d :
/bin/bash
$ firejail --quiet --noprofile --private-bin=ls ls /bin
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --private-bin=dash,ls,sh ls /bin
Cannot start application: No such file or directory

All your examples go through a shell (the user shell).

[rusty-snake]

Note: I assume that firejail invokes the program directly through something
like execve(3p) (rather than e.g.: system(3p)) and that the exec family of
functions do not depend on any shell being present.

That's only the case if you use shell=none (which should be the default IMHO). If you do not use shell=... at all or shell=/bin/dash,shell=/bin/mysh,... it will do {arg_shell:-$SHELL} -c {argv}.

$ firejail --quiet --noprofile --private --private-bin=ls /usr/bin/ls /
Cannot start application: No such file or directory
$ firejail --quiet --noprofile --shell=none --private --private-bin=ls /usr/bin/ls /
bin  boot  dev	etc  home  lib	lib64  lost+found  media  mnt  opt  proc  root	run  sbin  srv	sys  tmp  usr  var

$ firejail --debug --noprofile --private --private-bin=ls /usr/bin/ls /
[...]
Running '/usr/bin/ls' '/'  command through /bin/bash
execvp argument 0: /bin/bash
execvp argument 1: -c
execvp argument 2: '/usr/bin/ls' '/'
[...]
$ firejail --debug --noprofile --shell=none --private --private-bin=ls /usr/bin/ls /
[...]
execvp argument 0: /usr/bin/ls
execvp argument 1: /
[...]

[kmk3]

Related discussion:

• f347e88#r67230165

[crocket]

If /bin/sh is a symlink, private-bin sh adds /bin/sh and the actual shell behind /bin/sh.