Ssh: Profile Breaks -f Functionality

by ADMIN 37 views

Description

The firejail ssh -N -f -L ... command will exit after successful authentication, rather than backgrounding itself and waiting. This is a problem when trying to establish a persistent listener process.

Steps to Reproduce

To reproduce this issue, follow these steps:

  1. Start without a listener:

t1 $ netstat -antp 2>/dev/null | egrep 1111

2. Run a regular `ssh` command without Firejail, which works as expected and backgrounds with a persistent listener process:
   ```bash
t1 $ /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost
t1 $ netstat -antp 2>/dev/null | egrep 1111
tcp        0      0 127.0.0.1:1111          0.0.0.0:*               LISTEN      1913/ssh                      
tcp6       0      0 ::1:1111                :::*                    LISTEN      1913/ssh                      
t1 $ kill 1913
  1. Run firejail with the -f option, which exits successfully but without a listener:

t1 $ firejail /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost t1 $ echo $? 0 t1 $ netstat -antp 2>/dev/null | egrep 1111

4. Run `firejail` without the `-f` option, which works but doesn't background:
   ```bash
t1 $ firejail /usr/bin/ssh -N -L 1111:127.0.0.1:1112 localhost
t2 $ netstat -antp 2>/dev/null | egrep 1111
tcp        0      0 127.0.0.1:1111          0.0.0.0:*               LISTEN      2154/ssh                      
tcp6       0      0 ::1:1111                :::*                    LISTEN      2154/ssh

Expected Behavior

The expected behavior is that firejail ssh -N -f -L ... should connect, establish a listener, and background itself.

Actual Behavior

The actual behavior is that the ssh connection exits after successful authentication, rather than backgrounding itself.

Behavior without a Profile

When calling LC_ALL=C firejail --noprofile /path/to/program in a terminal, the ssh connection establishes a listener, but does not exit - behaves the same as when no -f was specified.

Additional Context

No changes in ssh.profile changed the behavior except for commenting out deterministic-shutdown: once I did that, it behaves like the no--f or --noprofile cases: the listener is set up, but the ssh does not background itself.

Environment

  • Name/version/arch of the Linux kernel (uname -srm): Linux 6.6.83-gentoo x86_64
  • Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Gentoo Linux
  • Name/version of the relevant program(s)/package(s) (e.g. "firefox 134.0-1, mesa 1:24.3.3-2"): openssh-10.0_p1
  • Version of Firejail (firejail --version): 0.9.74
  • If you use a development version of firejail, also the commit from which it was compiled (git rev-parse HEAD):

Checklist

  • [x] The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
  • [x] I can reproduce the issue without custom modifications (e.g. globals.local).
  • [x] The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
  • [x] The profile (and redirect profile if exists) hasn't already been fixed upstream.
  • [x] I have performed a short search for similar issues (to avoid opening a duplicate).
    • [x] I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
  • [n/a] I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program 

$ LC_ALL=C firejail /usr/bin/ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address]
           [-c cipher_spec] [-D [bind_address:]port] [-E log_file]
           [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file]
           [-J destination] [-L address] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-P tag] [-p port] [-R address]
           [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
           destination [command [argument ...]]
       ssh [-Q query_option]

Output of LC_ALL=C firejail --debug /path/to/program 

output goes here

Conclusion

Q: What is the issue with firejail ssh -N -f -L ...?

A: The firejail ssh -N -f -L ... command will exit after successful authentication, rather than backgrounding itself and waiting. This is a problem when trying to establish a persistent listener process.

Q: What is the expected behavior of firejail ssh -N -f -L ...?

A: The expected behavior is that firejail ssh -N -f -L ... should connect, establish a listener, and background itself.

Q: What is the actual behavior of firejail ssh -N -f -L ...?

A: The actual behavior is that the ssh connection exits after successful authentication, rather than backgrounding itself.

Q: Why does this issue occur?

A: This issue occurs because of a problem with the ssh.profile file. When firejail is used with the -f option, it does not properly background the ssh process, causing it to exit after successful authentication.

Q: How can I reproduce this issue?

A: To reproduce this issue, follow these steps:

  1. Start without a listener:

t1 $ netstat -antp 2>/dev/null | egrep 1111

2. Run a regular `ssh` command without Firejail, which works as expected and backgrounds with a persistent listener process:
   ```bash
t1 $ /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost
t1 $ netstat -antp 2>/dev/null | egrep 1111
tcp        0      0 127.0.0.1:1111          0.0.0.0:*               LISTEN      1913/ssh                      
tcp6       0      0 ::1:1111                :::*                    LISTEN      1913/ssh                      
t1 $ kill 1913
  1. Run firejail with the -f option, which exits successfully but without a listener:

t1 $ firejail /usr/bin/ssh -N -f -L 1111:127.0.0.1:1112 localhost t1 $ echo $? 0 t1 $ netstat -antp 2>/dev/null | egrep 1111

4. Run `firejail` without the `-f` option, which works but doesn't background:
   ```bash
t1 $ firejail /usr/bin/ssh -N -L 1111:127.0.0.1:1112 localhost
t2 $ netstat -antp 2>/dev/null | egrep 1111
tcp        0      0 127.0.0.1:1111          0.0.0.0:*               LISTEN      2154/ssh                      
tcp6       0      0 ::1:1111                :::*                    LISTEN      2154/ssh

Q: What can I do to fix this issue?

A: To fix this issue, you can try the following:

  1. Check the ssh.profile file for any issues or problems.
  2. Try commenting out the deterministic-shutdown line in the ssh.profile file.
  3. Run firejail with the --noprofile option to disable the profile.
  4. Check the Firejail documentation for any known issues or workarounds.

Q: Is this issue specific to Firejail?

A: No, this issue is not specific to Firejail. It can occur with any program that uses a profile file.

Q: Can I get help with this issue?

A: Yes, you can get help with this issue by:

  1. Checking the Firejail documentation and forums for any known issues or workarounds.
  2. Posting a question on the Firejail subreddit or forum.
  3. Contacting the Firejail developers directly for assistance.