Autocomplete doesn't work in bash (when firejailed)

[denizakcal]

Hello. :)

To reproduce the issue, do

1. mkdir -p $HOME/fake_home

2. firejail --noprofile --private=$HOME/fake_home bash

3. Type "whoam" (without the quotes) (where the final character is missing on purpose) (for example) and then press tab on the keyboard. It should autocomplete to "whoami" (without the quotes).

Explanation of why I think the bug is in Firejail and not my operating system(s):
I'm 99% sure that the problem is with Firejail because I tried on various versions of (throwaway, virtual) Ubuntu systems, and if I recall correctly, versions 20.04, 20.10, 22.04 (which was using Firejail 0.9.66-2), and the in-development release of 22.10 (which was also using Firejail 0.9.66-2), did have autocomplete working in all of those (with Firejail from their respective repositories).

When I installed 0.9.70-1 from sourceforge, the bug (of autocomplete not working) was present (in more than one system).

In Debian, version 0.9.64.4-2 of Firejail in Debian stable / bullseye has autocomplete working, but versions 0.9.68-3 (if I remember correctly) and 0.9.70-1 of Firejail in Debian testing / bookworm don't have autocomplete working properly.

I would appreciate it if someone could look into this.

Let me know if more information is needed.

[glitsj16]

It's not a bug but a feature. Firejail 0.9.70 introduced a new --tab option for autocompletion support: e6c5024. It's in the release notes. You can put it in your globals.local (as tab) if you always want it.

[denizakcal]

It's not a bug but a feature. Firejail 0.9.70 introduced a new --tab option for autocompletion support: e6c5024. It's in the release notes. You can put it in your globals.local (as tab) if you always want it.

Thanks for your response, but the --tab argument seems to only fix the autocompletion with --private and not with --private=/path/to/some/directory/of/choice.

Could you please verify if that is also the behaviour exhibited on your system(s)?

[rusty-snake]

Thanks for your response, but the --tab argument seems to only fix the autocompletion with --private and not with --private=/path/to/some/directory/of/choice.

If there is a existing $HOME/.inputrc ($HOME is your private home, $real_HOME/fake_home is your case. Firejail will not remove set disable-completion on from it. You need to remove it manually.

--tab skips the creation of a .inputrc with set disable-completion on. With --private this makes tab completion working. But with --private=foo one run w/o --tab creates inputrc which then persists in the private home.

[rusty-snake]

Related to #5190, why do we have this "feature" at all?

[glitsj16]

Could you please verify if that is also the behaviour exhibited on your system(s)?

Here are some observations... which confirm @rusty-snake's contribution above.

[A] You're correct (--tab only works for --private, as advertised in the man page)

$ mkdir -p $HOME/fake_home

$ firejail --quiet --noprofile --private cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private --tab cat .inputrc
cat: .inputrc: No such file or directory
$ firejail --quiet --noprofile --private --tab bash
Type "whoam" and press tab. It DOES autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]

[B] Let's try something for fun:

$ rm -rf $HOME/fake_home
$ mkdir -p $HOME/fake_home
$ firejail --quiet --noprofile --private=$HOME/fake_home echo > .inputrc

$ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]

[C] Even more fun:

$ rm -rf $HOME/fake_home
$ mkdir -p $HOME/fake_home
$ echo > ~/fake_home/.inputrc

$ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc
--- no output --- [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc
--- no output --- [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home bash
Type "whoam" and press tab. It DOES autocomplete to "whoami". [NOW IT WORKS]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
Type "whoam" and press tab. It DOES autocomplete to "whoami". [NOW IT WORKS]

Additional testing confirmed that:

• you cannot change autocompletion status of a running sandbox (with or without using options from the transfer files man page section);
• if you really want/need autocompletion with --private=foo, put an empty .inputrc in the new $HOME prior to accessing it via firejail through 'regular' file system handling.

Related to #5190, why do we have this "feature" at all?

Fair question.

[rusty-snake]

[D]

$ rm -rf $HOME/fake_home
$ mkdir -p $HOME/fake_home
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
auto-complete works

[denizakcal]

Thanks! I removed the .inputrc file and used the --tab feature, and the autocomplete now works!

And, I think the feature of disabling the autocomplete by default was probably done since the autocomplete can be a security risk, as shown in this (old) Bash security bug description ( https://www.cvedetails.com/cve/CVE-2017-5932/ ), so it's probably a good thing that it is as it is, but for this particular use case of mine, I'm okay with enabling it since I have nonewprivs (and noroot) anyways*.

*I said what I said about nonewprivs (and noroot) because that bug description that I linked to was about gaining privileges, which is something that nonewprivs should prevent anyways. But, even if it were not, I feel that relying on Debian stable (for example) to have security bugs like that old Bash security bug fixed is not that big of a risk either.

To try to further justify that --tab feature, maybe a certain app would need root privileges to run, so noroot and nonewprivs would not be useful there, and one would therefore want to reduce the risk by not allowing the autocompletion in such a situation?

[rusty-snake]

I'm okay with enabling it since I have nonewprivs (and noroot) anyways*.

This does not protect you against CVE-2017-5932. See 4 Impact in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf.

I feel that relying on Debian stable (for example) to have security bugs [..] fixed is not that big of a risk either.

In Debian stable you only get fixes for security bugs with a CVE

[denizakcal]

This does not protect you against CVE-2017-5932. See 4 Impact in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf.

Sorry, but I'm not sure I understand.

The PDF you linked to says the following.:

Assuming an attacker has unprivileged account on a system, dropping a single file with the crafted name into a directory and asking an admin to investigate will elevate his privilege.

It seems to me like, assuming that that bug still existed and that I'm not using Firejail (because of not being able to be root within a Firejail sandbox with --noroot and --nonewprivs, which I'm using in this situation), if I never try to autocomplete with Bash in that directory as a root user, at worst, it would successfully download and run the malicious script, but it would not succeed at getting the non-root user's privileges elevated.

In order for the malicious actor to successfully elevate the non-root user's privileges, I, the only person with the root password, would need to (i) be in the directory with the maliciously-crafted file, (ii) be root (which would mean not using a Firejail sandbox having --noroot and --nonewprivs) and (iii) try to autocomplete (with Bash), right?

In Debian stable you only get fixes for security bugs with a CVE

Can't all serious security bugs "that can be fixed independently of any other problems" be filed as CVEs?

[rusty-snake]

1. You can be root in a --noroot --nonewprivs configured sandbox.
2. Privileged escalation is more than user-to-root, it is less-privileged-to-more-privileged. So sandboxed-user-process-to-unsandboxed-user-process is privileged escalation too.
3. Firejail can not protect you because the vulnerable code runs outside of the firejail sandbox (unless you run every (interactive) bash in firejail. But even then it can not because such a sandbox would be very weak).

Can't all serious security bugs "that can be fixed independently of any other problems" be filed as CVEs?

Of course they can ... but it does not happen.
If a security vulnerability is discovered by a security researched it gets a CVE in 99.9% but if it gets discovered by upstream this is not always the case. Furthermore it can get fixed without being note during refactoring, hardening or fixing a non-security bug with actually is one. Or there is a upstream policy that bug with allow things you usually would count as a security vulnerabilities are not counted as security vulnerability if it can be done on a legal way too (e.g. keylogging in X11).

[denizakcal]

1.1. How so? For --nonewprivs, I guess it can be because one can find a way to acquire privileges without using execve (which is what the Firejail manual says --nonewprivs is supposed to prevent). But, for --noroot, the Firejail manual says that it is used to "install a user namespace with a single user - the current user" and that the "root user does not exist in the new namespace."

1.2. Oh, yes, I had forgotten about that. Thanks.

1.3. If the directory of the maliciously-crafted file (the fake home, in my case) is never accessed by anyone (whether a regular user or the root user) (directly or indirectly, such as from the PATH environment variable) from a non-Firejailed Bash process, then wouldn't all Bash processes (including the non-Firejailed ones) be safe from that bug? (My logic is that if a malicious actor tries to change something like the PATH environment variable from the Firejailed Bash processes (which would always be accessed via Firejail), it would only be the file(s) in the fake home directory that would be modified, which if I'm correct, shouldn't affect the real environment variables loaded in a regular Bash instance from the real home directory.)

2. Oh, thanks for the information.

[rusty-snake]

1.1. sudo firejail
1.3. The hole exploit is based on an more privileged bash process performs autocomplete in a directory with a malicious file.

[denizakcal]

Oh, I see. Well, since I wouldn't be running the Firejailed Bash as root and that I wouldn't be accessing the fake home without Firejailing Bash, then it seems that my way of doing things is safe after all! :D

Thanks for the information!