github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #3534] How to use "passwd" in a firejail login shell? #2221

New issue

Closed

opened 2026-05-05 08:54:32 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:54:32 -06:00

Owner

Originally created by @jsquyres on GitHub (Jul 21, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3534

Greetings, and thanks for firejail!

Question
I'm trying to use Firejail as a restricted login shell, and in general, it works pretty great. On an Ubuntu 18.04 system with the distro-provided firejail v0.9.52, per firejail(1), I have /usr/bin/firejail as the shell for my user, and per firejail-login(5), I have /etc/firejail/login.users set with:

my_username: --writable-etc --private-opt=blah --disable-mnt --private-tmp --private-dev --private-bin=scp,rm,ls,rbash,passwd --shell=/bin/rbash

Outside the firejail, I see that /usr/bin/passwd is setuid and owned by root:root:

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 59640 Mar 22  2019 /usr/bin/passwd

However, I see that in the firejail, while the setuid bit /bin/passwd is visible, it is owned by nobody:nogroup:

$ ls -l /bin/passwd
-rwsr-xr-x 1 nobody nogroup 59640 Jul 21 21:03 /bin/passwd

This seems to prevent passwd from running properly, because /etc/shadow is owned by root and 0400, and therefore not readable by the nobody user.

Has anyone tried to use firejail as a login shell and also successfully allowed the user to use the passwd command?

Does --private-bin automatically copy files over as nobody:nogroup?

Reproduce
Steps to reproduce the behavior:

Set /etc/firejail/login.users as above
Set a user with /usr/bin/firejail as their shell
Login and try to run the passwd program
Enter your password when prompted by passwd
See passwd fail because it can't read /etc/shadow, and therefore can't validate your password

Environment

Ubuntu 18.04:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

Firejail version:

$ firejail --version
firejail version 0.9.52

Compile time support:
        - AppArmor support is enabled
        - AppImage support is enabled
        - bind support is enabled
        - chroot support is enabled
        - file and directory whitelisting support is enabled
        - file transfer support is enabled
        - git install support is disabled
        - networking support is enabled
        - overlayfs support is enabled
        - private-home support is enabled
        - seccomp-bpf support is enabled
        - user namespace support is enabled
        - X11 sandboxing support is enabled

Additional context
NA

Checklist

[NA] The upstream profile (and redirect profile if exists) have no changes fixing it.
[NA] The upstream profile exists (find / -name 'firejail' 2>/dev/null/fd firejail to locate profiles ie in /usr/local/etc/firejail/PROGRAM.profile)
[NA] Programs needed for interaction are listed.
[NA] Error was checked in search engine and on issue list without success.

debug output

Can't really supply the output of firejail --debug ... because this is a login shell.

Originally created by @jsquyres on GitHub (Jul 21, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3534 Greetings, and thanks for firejail! **Question** I'm trying to use Firejail as a restricted login shell, and in general, it works pretty great. On an Ubuntu 18.04 system with the distro-provided firejail v0.9.52, per firejail(1), I have `/usr/bin/firejail` as the shell for my user, and per firejail-login(5), I have `/etc/firejail/login.users` set with: ``` my_username: --writable-etc --private-opt=blah --disable-mnt --private-tmp --private-dev --private-bin=scp,rm,ls,rbash,passwd --shell=/bin/rbash ``` Outside the firejail, I see that `/usr/bin/passwd` is setuid and owned by `root:root`: ``` $ ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 59640 Mar 22 2019 /usr/bin/passwd ``` However, I see that in the firejail, while the setuid bit `/bin/passwd` is visible, it is owned by `nobody:nogroup`: ``` $ ls -l /bin/passwd -rwsr-xr-x 1 nobody nogroup 59640 Jul 21 21:03 /bin/passwd ``` This seems to prevent `passwd` from running properly, because `/etc/shadow` is owned by root and 0400, and therefore not readable by the `nobody` user. Has anyone tried to use firejail as a login shell and also successfully allowed the user to use the `passwd` command? Does `--private-bin` automatically copy files over as `nobody:nogroup`? **Reproduce** Steps to reproduce the behavior: 1. Set `/etc/firejail/login.users` as above 1. Set a user with `/usr/bin/firejail` as their shell 1. Login and try to run the `passwd` program 1. Enter your password when prompted by `passwd` 1. See `passwd` fail because it can't read `/etc/shadow`, and therefore can't validate your password **Environment** - Ubuntu 18.04: ``` $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic ``` - Firejail version: ``` $ firejail --version firejail version 0.9.52 Compile time support: - AppArmor support is enabled - AppImage support is enabled - bind support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - git install support is disabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled ``` **Additional context** NA **Checklist** - [NA] The upstream profile (and redirect profile if exists) have no changes fixing it. - [NA] The upstream profile exists (`find / -name 'firejail' 2>/dev/null`/`fd firejail` to locate profiles ie in `/usr/local/etc/firejail/PROGRAM.profile`) - [NA] Programs needed for interaction are listed. - [NA] Error was checked in search engine and on issue list without success. <details><summary> debug output </summary> Can't really supply the output of `firejail --debug ...` because this is a login shell. </details>

gitea-mirror closed this issue

2026-05-05 08:54:33 -06:00

gitea-mirror commented

2026-05-05 08:54:34 -06:00

Author

Owner

@FOSSONLY commented on GitHub (Jul 22, 2020):

Using a restricted shell based on firejail already implies that the respective user should be denied many critical resources. You, however, use the restricted shell, and you break it step by step by releasing critical resources, or should be released, which goes against the basic purpose behind it. By the way, a restricted shell based on bash (rbash) is completely insecure and still unsuitable to provide more security. If you already secure the login shell with firejail, then administrative tasks should no longer be done by the same user. Therefore the recommendation with Alt+Tab+F{1-6} (may vary depending on desktop and Xorg/Wayland) simply change the TTY to open a new session via a direct login as root. Then you can perform your administrative tasks, log out again, and change the TTY again to enter the regular graphical session. This is less comfortable, but also hardly avoidable for more security. I would at least suggest you to practice it better that way.

@FOSSONLY commented on GitHub (Jul 22, 2020): Using a restricted shell based on firejail already implies that the respective user should be denied many critical resources. You, however, use the restricted shell, and you break it step by step by releasing critical resources, or should be released, which goes against the basic purpose behind it. By the way, a restricted shell based on bash (rbash) is completely insecure and still unsuitable to provide more security. If you already secure the login shell with firejail, then administrative tasks should no longer be done by the same user. Therefore the recommendation with Alt+Tab+F{1-6} (may vary depending on desktop and Xorg/Wayland) simply change the TTY to open a new session via a direct login as root. Then you can perform your administrative tasks, log out again, and change the TTY again to enter the regular graphical session. This is less comfortable, but also hardly avoidable for more security. I would at least suggest you to practice it better that way.

gitea-mirror commented

2026-05-05 08:54:35 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 22, 2020):

private-bin is mounted with nosuid, see #2969.

@rusty-snake commented on GitHub (Jul 22, 2020): `private-bin` is mounted with `nosuid`, see #2969.

gitea-mirror commented

2026-05-05 08:54:36 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 22, 2020):

passwd is blacklisted in disable-common.inc which is included in the default profile.
If you remove that along with other necessary files it should work.

--
Personally if your goal is providing untrusted users access to a system, especially if it is remotely accessible, I would use something "stronger".
ie. full user confinement via selinux

If however all you need is remote file access for users, consider sshd chroot+internal-sftp and keys instead of passwords.

Either way I recommend a newer kernel and firejail.

Of extra note: scp is deprecated

@SkewedZeppelin commented on GitHub (Jul 22, 2020): `passwd` is blacklisted in disable-common.inc which is included in the default profile. If you remove that along with other necessary files it should work. -- Personally if your goal is providing untrusted users access to a system, especially if it is remotely accessible, I would use something "stronger". ie. full user confinement via selinux If however all you need is remote file access for users, consider sshd chroot+internal-sftp and keys instead of passwords. Either way I recommend a newer kernel and firejail. Of extra note: scp is deprecated

gitea-mirror commented

2026-05-05 08:54:37 -06:00

Author

Owner

@jsquyres commented on GitHub (Jul 22, 2020):

I translate the above responses to: "You can probably make passwd work in a firejail, but you probably shouldn't."

Got it. Thanks!

@jsquyres commented on GitHub (Jul 22, 2020): I translate the above responses to: "You can probably make `passwd` work in a firejail, but you probably shouldn't." Got it. Thanks!

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2221

No description provided.

Rows
Columns