docs: clarify to run "sudo firecfg" as a normal (desktop) user

[kmk3]

End users following the steps for desktop integration may end up running
sudo firecfg as root (or as a similar account) rather than as a normal
desktop user.

In that case, programs opened through a desktop launcher would still not
be running under firejail, which might surprise users.

So clarify that sudo firecfg should be executed as a normal (desktop)
user for desktop integration.

Relates to #6657.

Kind of relates to #5812.

Reported-by: @ginto37

[rusty-snake]

The alternatives is

# firecfg
# firecfg --add-users YOUR_USER
$ firecfg --fix

[rusty-snake]

In that case, programs opened through a desktop launcher would still not
be running under firejail, which might surprise users.

Half the story.

• if the .desktop file has the program name in the Exec= key rather than the absolute path and does not use DBusActivatable=true, then it works.
• if the .desktop file has an absolute path in the Exec= key or uses DBusActivatable=true, then it does not work.
• if the .desktop file has the wrong name ...
• if the program does autostart, dbus, systemd, ...

[ginto37]

I'm not sure the phrase "normal (desktop) user" really helps here, and I'd suggest not going with that. My admin account, the one with sudo privileges, is a normal, desktop user, and so is my standard user account, the one without the sudo privileges and the one I work in 90% of the time. But only the admin account can run sudo firecfg. Also, most desktop users won't have direct access to root - Fedora, Ubuntu and Debian don't even enable it by default. So the average user will be working with just the admin account and the standard account, only one of which will work with that command.

I feel like there's a fundamental difference in views here regarding the use of accounts on Linux. Basically I feel like you're looking at this from a different angle and it's leading you to write up the instructions from a slightly unhelpful viewpoint that's going to confuse users rather than help them.

For that reason, Rusty-snake's suggestion should be the default method, not the alternative, IMO, otherwise users like myself are going to wonder why sudo firecfg won't work when run in an account which doesn't have sudo privileges for firecfg.

Rusty-snake's method doesn't involve modifying the sudoers file - which would be necessary for a non-admin account, and which you don't cover in the steps, despite it being crucial and capable of breaking the system if performed incorrectly - and encourages separation of admin and standard user accounts, which is good security practice.

In essence,

# firecfg
# firecfg --add-users <EACH USER WHO NEEDS TO USE FIREJAIL>
As each of those users, for those who want desktop integration:
$ firecfg --fix

OOC, where would firecfg --fix-sound come in that list? Does it also have to be run for each user intending to use Firejail?

[rusty-snake]

sudoers file

I still don't get why you want to modify it.

OOC, where would firecfg --fix-sound come in that list? Does it also have to be run for each user intending to use Firejail?

Each user.

Keep in mind that firejails primary target are single user desktop systems.

[ginto37]

OK, I'll start from the official installation method.

• The official README.md calls out two distros for explicit mention: Ubuntu and Debian.

• In Ubuntu, the root account is disabled by default. On Debian, it is only enabled if configured during installation. If it is, the official documentation still recommends using sudo instead of suing to root for administration.

• It's generally recognized that using the root account is not recommended (see here and here). For the same reasons, sudo rights should not be granted without reasonable justification. For example, the sudo manpage on Debian 12 says this:

There is no easy way to prevent a user from gaining a root shell if that user is allowed to run arbitrary commands via sudo.

• If root is not enabled, there are only two account types available on Ubuntu and Debian for ordinary desktop users: Standard and Administrator. As security is the primary focus of firejail, let's assume that a Debian user didn't enable root during installation, and will be relying on sudo.

• On both distros, only Administrator user accounts can use sudo by default. This means that, by default, without making changes to sudoers, only an Administrator user account can run sudo firecfg. A Standard user trying to run it will see a message like this:

Sorry, user foo is not allowed to execute '/usr/bin/firecfg' as root on ubuntu-desktop.

Again because security is the primary focus of firejail, let's assume a user on either distro is using a Standard user for his daily activities, and only switches to an Administrator account when necessary.

• As per the README.md, desktop integration for firejail requires running the following commands:

firecfg --fix-sound
sudo firecfg

• Any security-conscious user running those commands as a Standard user will not be able to run the second one, and will see the error message described above. This will prevent the creation of the files necessary for that particular user to launch applications from Activities view using Search (this applies to both Ubuntu and Debian).

• In attempting to fix this, the user can:

a) run sudo firecfg as an admin user. This would not actually create the desktop integration for the intended Standard user (this was my experience), so the user would then have to run firecfg --fix from the Standard user account

Or b) Give the Standard user general sudo privileges, which is not recommended (see above)

Or c) Give the Standard user sudo privileges for the firecfg command by modifying the sudoers file.

Of those three, the most secure and least complex option is, IMO, the first: a).

Ideally, and IMO, the steps for desktop integration should be described something like as follows:

1. As an administrator, run firecfg to create the symlinks:

sudo firecfg

2. Enable firejail for each user who needs to use it:

sudo firecfg --add-users foo bar

3. As each Standard user, run:

firecfg --fix

That's really as far as my thinking takes me. I'm not a firejail power user. I can't comment on whether this solves every conceivable problem. But I think it's an improvement on the current instructions which are almost guaranteed to make a user wonder why his desktop integration doesn't always work.

Going one step further, I'd like to suggest that firecfg should be modified so that it takes into consideration any users added with --add-users and automatically performs desktop integration for them when run as an administrator. The only time this might not work is if the system uses encrypted home directories (which is supported on Ubuntu by default in addition to full disk encryption). In that case, firecfg --fix would be the answer.

HTH.

[rusty-snake]

let's assume

To many axioms.

Standard user for his daily activities, and only switches to an Administrator account when necessary.

I doubt that this is the common setup. The most users of firejail will have one user account. That is in the wheel group.

c) Give the Standard user sudo privileges for the firecfg command by modifying the sudoers file.

Should be treated equal to "Or b) Give the Standard user general sudo privileges, which is not recommended (see above)".

Ideally, and IMO, the steps for desktop integration should be described something like as follows:

Then send a PR.

As an administrator,

This could also be understood as "as root user" as a lot users thing "administrator = root" and "root = administrator".

Enable firejail for each user who needs to use it:

Add on this, if you never do --add-users, all users are allowed to use firejail.

firecfg --fix

Going one step further, I'd like to suggest that firecfg should be modified so that it takes into consideration any users added with --add-users and automatically performs desktop integration for them when run as an administrator. The only time this might not work is if the system uses encrypted home directories (which is supported on Ubuntu by default in addition to full disk encryption). In that case, firecfg --fix would be the answer.

We could also implement a firecfg --fix-system.

[ginto37]

The first sentence in the README.md:

Firejail is a lightweight security tool intended to protect a Linux system by setting up a restricted environment...

As the devs behind firejail, it's counter-productive to promote firejail but also to tacitly and implicitly promote a fundamentally less secure initial working environment.

If you genuinely believe most of your users are working day-to-day in root or admin environments, then you have a great opportunity to educate them out of that position before recommending firejail as additional hardening.