Option to launch firejailed program as a different user

[scruloose]

I would like to revive the request in issue #208 for the ability to run programs inside Firejail as an entirely different local *NIX user.

Similar to the OP of that issue, what I have in mind is something like this:

• I have my primary user account on my desktop system, logged in with a full DE;
• I also have a secondary user account on the same machine, with its own home folder which in turn contains an extensive porn stash its own persistent .firefox tree for persistent browser settings, the whole meal deal;
• The primary user has sudo access;
• Using something like sudo firejail --runas=<seconduser> <program-to-run>, I could launch Firefox or SMplayer or whatever, in a Firejail sandbox, using Xpra or Xephyr or whatever, as the secondary user, using that user's own home dir, its own ~/.config tree, its own file-access permissions, its own everything, but export the window back to my existing desktop.

This would allow mixing and matching the strengths of sandboxing with the strengths of *NIX account separation (second user can have a different umask, its own system-enforced disk quota, its own group memberships, etc), while keeping the convenience of a single desktop environment.

Oddly, the thread for issue #208 seems to indicate that this ability was actually added in early 2016… but by a year and a half later it had been "removed a long time ago".

I don't know what prompted the removal of this feature shortly after implementing it, but if it was removed due to factors that are reasonably easy to resolve (or no longer relevant 5 years later), this is something that I for one would find really handy to have.

[M83tUt3]

* Using something like `sudo firejail --runas=<seconduser> <program-to-run>`

Wouldn't this be simply sudo -u <seconduser> firejail <program-to-run>?

[Khouderchah-Alex]

Wouldn't this be simply sudo -u <seconduser> firejail <program-to-run>?

IIUC, that's assuming seconduser has permission to execute firejail. Given the nature of SUID binaries in the context of privilege escalation, they are high-value targets, and so ideally seconduser wouldn't be able to use firejail. Under the assumption that all processes running as seconduser are sandboxed and have no access to firejail, I'm not sure how much benefit a --user flag would be outside of configuration errors, but retaining that additional layer of security doesn't seem so outlandish for a project specifically designed around security and whose users likely have a {,un}healthy amount of paranoia.

FWIW, it seems like the option was removed specifically under the assumption that a --user flag has no benefit over sudo -u:
ab36d45

[rusty-snake]

Do we want this or should we close?

[kmk3]

@Khouderchah-Alex commented 19 days ago:

Wouldn't this be simply sudo -u <seconduser> firejail <program-to-run>?

IIUC, that's assuming seconduser has permission to execute firejail. Given
the nature of SUID binaries in the context of privilege escalation, they are
high-value targets, and so ideally seconduser wouldn't be able to use
firejail. Under the assumption that all processes running as seconduser are
sandboxed and have no access to firejail, I'm not sure how much benefit a
--user flag would be outside of configuration errors, but retaining that
additional layer of security doesn't seem so outlandish for a project
specifically designed around security and whose users likely have a
{,un}healthy amount of paranoia.

Personally, I have also wondered about this exact same problem.

To me, from a high-level perspective, this:

• SUID -> privdrop -> untrusted_user -> program

seems more secure than this:

• untrusted_user -> SUID -> privdrop -> program

FWIW, it seems like the option was removed specifically under the assumption
that a --user flag has no benefit over sudo -u:
ab36d45

@rusty-snake commented yesterday:

Do we want this or should we close?

I have no idea about the costs of implementing this, so I'll just leave my "+1
nice to have" here.

[kmk3]

By the way, I see that there is a "wontfix" label, but it is currently only
used for #107 and #1743, and I suspect that there is more of such issues:

• https://github.com/netblue30/firejail/issues?q=label%3Awontfix

If this is resolved as a "wontfix", please consider using that label to make it
obvious at a glance why the issue was closed.

[rusty-snake]

@diyism this is a complete other issue/question. Pleas open a new issue/discussion for it.