search

netblue30 / firejail

Linux namespaces and seccomp-bpf sandbox
https://firejail.wordpress.com
GNU General Public License v2.0
5.83k stars 568 forks source link

ssh: errors accessing shell file from /usr/share when using fish and mosh #5721

Open skrat opened 1 year ago

skrat commented 1 year ago

Description

I'm using mosh , it's running ssh and doing UDP mumbo jumbo, that's beyond this report. I'm also using fish shell (set in /etc/passwd). Now mosh is running ssh to do its thing. This is where firejail is invoked to run ssh. Somehow it needs to run user's shell in that process, but suddenly the files that need to be loaded from /usr/share/fish are not accessible because of some firejail rules. This results in fish spewing errors locally. I'm not sure what to do about it, what to whitelist, etc.

Related:

https://github.com/mobile-shell/mosh/issues/1262

Steps to Reproduce

Steps to reproduce the behavior

  1. do some basic edits in ~/.config/fish/config.fish such as calls to fish_add_path or just add some alias ll=ls -l
  2. try connecting with mosh to a remote server (needs to have mosh installed and UDP ports accessible, see https://github.com/mobile-shell/mosh#how-it-works)

Expected behavior

It would just connect, not complaining about unknown functions called in ~/.config/fish/config.fish

Actual behavior

Spews errors because functions are not loaded from /usr/share/fish

Behavior without a profile

_What changed calling LC_ALL=C firejail --noprofile /path/to/program in a terminal?_

~ $ env LC_ALL=C firejail --noprofile /usr/bin/mosh myserver
Parent pid 3060020, child pid 3060021
Child process initialized in 3.72 ms
Warning: an existing sandbox was detected. /usr/bin/ssh will run without any additional sandboxing features

mosh-client needs a UTF-8 native locale to run.

Unfortunately, the client's environment (LC_ALL=C) specifies
the character set "US-ASCII".

LANG=en_US.UTF-8
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

Parent is shutting down, bye...

Additional context

...

Environment

Checklist

kmk3 commented 1 year ago

Basic debugging information is missing; please follow the bug report template:

skrat commented 1 year ago

@kmk3 updated description according to template, left out the last part (logs) as I don't find it relevant

kmk3 commented 1 year ago

@skrat on Mar 8:

suddenly the files that need to be loaded from /usr/share/fish are not accessible because of some firejail rules. This results in fish spewing errors locally.

@skrat on Mar 8:

left out the last part (logs) as I don't find it relevant

What are the errors?

Do they happen when invoking just ssh with firejail?

Example:

firejail /usr/bin/ssh <server>

@skrat on Mar 8:

~ $ env LC_ALL=C firejail --noprofile /usr/bin/mosh myserver
# [...]

mosh-client needs a UTF-8 native locale to run.

What is the output with LC_ALL=en_US.UTF-8?

skrat commented 1 year ago

@kmk3

The errors are about missing functions (alias and fish_add_path) which are defined in files under /usr/share/fish.

No it does not happen when using ssh (firejailed) directly. So yes, this is probably a mosh thing (there is no profile yet).

Yes it works as expected when I invoke mosh with firejail --noprofile.

kmk3 commented 1 year ago

ssh.profile has whitelist-usr-share-common.inc, so the following workaround might fix the errors:

~/.config/firejail/ssh.local:

whitelist /usr/share/fish

Though I think that ideally this would be fixed in mosh (why does it source local auto-completion files when connecting to a server?) or maybe in a new mosh.profile.

glitsj16 commented 1 year ago

Spews errors because functions are not loaded from /usr/share/fish

The ssh profile includes whitelist-usr-share-common.inc:

https://github.com/netblue30/firejail/blob/0c006166347ceee63c7e5e944d58f10ee888d6d2/etc/profile-m-z/ssh.profile#L23

But that included file doesn't whitelist /usr/share/fish, so you'll need at least that. What happens when you add whitelist /usr/share/fish to ssh.local? You might have to create that file, either in ~/.config/firejail or /etc/firejail.

Also, due to mosh not having a separate firejail profile there might be additional things going awry (include logic or otherwise) that we can't see wihout logs. I can understand that you don't find those relevant, but at least double-check everything on your side if the above doesn't fix things.

skrat commented 1 year ago

Those are not just auto-completion functions, they are fairly core functions that are typically called from user's config.fish such as alias. But this is getting weird, it doesn't make sense to whitelist user's shell specific /usr/share resources in (not yet existing) mosh.profile? How about all the other shells?

skrat commented 1 year ago

Here's what's happening https://asciinema.org/a/4AitlLYB2xuA9qsYdNHoABBbI

~ $ mosh myserver
~/.config/fish/config.fish (line 15): Unknown command: fish_add_path
fish_add_path $HOME/.local/bin
^~~~~~~~~~~~^
from sourcing file ~/.config/fish/config.fish
    called during startup
~/.config/fish/config.fish (line 16): Unknown command: fish_add_path
fish_add_path $HOME/.pub-cache/bin
^~~~~~~~~~~~^
from sourcing file ~/.config/fish/config.fish
    called during startup
~/.config/fish/config.fish (line 17): Unknown command: fish_add_path
fish_add_path $HOME/.ebcli-virtual-env/executables
^~~~~~~~~~~~^
from sourcing file ~/.config/fish/config.fish
    called during startup
~/.config/fish/config.fish (line 24): Unknown command: alias
alias vim=nvim
^~~~^
from sourcing file ~/.config/fish/config.fish
    called during startup

[mosh is exiting.]
~ 4s $
glitsj16 commented 1 year ago

FWIW, I actually did create firejail profiles for mosh, mosh-client and mosh-server a long time ago when I was using mosh myself. If there's interest I could recover/dust those of and add them to the project. But that will take some time because I would at least have to re-test everything involved. That being said, basically they are simple redirects for ssh.profile. Not hard to create them yourself.

skrat commented 1 year ago

I think we need to find what exactly is running user's shell (fish in this case) and under what conditions. It seems it's not ssh, then it must be mosh, but why is it getting ssh.profile restrictions? When I whitelist /usr/share/fish in .config/firejail/ssh.local, the errors go away.

kmk3 commented 1 year ago

@skrat on Mar 8:

Those are not just auto-completion functions, they are fairly core functions that are typically called from user's config.fish such as alias.

But why would it (re-)source them locally? Does it re-spawn the user shell?

Presumably these files would already have been sourced by the current shell locally and the remote shell would be sourcing things on the remote host.

But this is getting weird, it doesn't make sense to whitelist user's shell specific /usr/share resources in (not yet existing) mosh.profile? How about all the other shells?

This seems to be a quirk of mosh, so such whitelisting (including any other shells) would be a workaround for it in mosh.profile.

But ideally we would first understand why it tries to do the sourcing.

It could also be added to whitelist-usr-share-common.inc, but it seems unnecessary if only a single program would use it.

kmk3 commented 1 year ago

@skrat on Mar 8:

but why is it getting ssh.profile restrictions? When I whitelist /usr/share/fish in .config/firejail/ssh.local, the errors go away.

/usr/local/bin usually takes precedence over /usr/bin in $PATH and /usr/local/bin/ssh points to firejail, so ssh -> /usr/local/bin/ssh -> firejail /usr/bin/ssh (see firecfg(1)).

glitsj16 commented 1 year ago

But this is getting weird, it doesn't make sense to whitelist user's shell specific /usr/share resources in (not yet existing) mosh.profile? How about all the other shells?

Here are my mosh profiles:

glitsj16 commented 1 year ago

I actually don't see anything that 'weird' here. The ssh profile that's being called simply doesn't whitelist /usr/share/fish. A local override can fix that without doing anything else IMO. But let's wait and see what happens when @skrat uses these referenced mosh profiles.

skrat commented 1 year ago

Nothing happens with those profile, same error. There's still no explanation why locally spawned user shell is getting ssh.profile restrictions.

eminence commented 1 year ago

I know nothing about fish or about firejail, but when you mosh into a remote server, the mosh-server process is initially launched by the sshd, and then mosh-server will to the usual fork/daemonize dance and then spawn the user's default shell as a subprocess

glitsj16 commented 1 year ago

@skrat

When I whitelist /usr/share/fish in .config/firejail/ssh.local, the errors go away.

Good.

Nothing happens with those profile, same error.

Seems to contradict the above. If whitelist /usr/share/fish fixed the errors, it will/should do the same, whether you've placed that option in ssh.local or in mosh.profile.

There's still no explanation why locally spawned user shell is getting ssh.profile restrictions.

But there is an explanation:

(1) According to your opening post you've set your user to use fish shell in /etc/passwd. (2) You're using firejail (probably also firecfg for desktop intehration). (2) See https://github.com/netblue30/firejail/issues/5721#issuecomment-1460805718.

Please, I'm not intending to dispute what you're seeing, nor am I trying to be snug here. Based on what you've showed in this thread it all seems pretty straightforward. And fixable.