Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to launch firejailed program as a different user #3892

Open
scruloose opened this issue Jan 13, 2021 · 7 comments
Open

Option to launch firejailed program as a different user #3892

scruloose opened this issue Jan 13, 2021 · 7 comments
Labels
enhancement New feature request

Comments

@scruloose
Copy link

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
Copy link

M83tUt3 commented Jan 14, 2021

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

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

@akhouderchah
Copy link

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
Copy link
Collaborator

Do we want this or should we close?

@kmk3 kmk3 added the enhancement New feature request label Apr 7, 2021
@kmk3
Copy link
Collaborator

kmk3 commented Apr 7, 2021

@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
Copy link
Collaborator

kmk3 commented Apr 7, 2021

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:

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

@diyism

This comment was marked as off-topic.

@rusty-snake
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request
Projects
None yet
Development

No branches or pull requests

6 participants