Patch to bind user home directories

[lepasserby]

Hi!
Perhaps a silly question, but it was mentioned that --x11 is not available for root.

Would it work for cases where firejail is called like

sudo firejail --x11 --user=non-root-user --net=br1 program-name
?

Reason for sudoing: need to bind a "host" directory into the sandbox at startup (so the jailed program's output is available to certain processes at host), thus plan to have whitelist directory directive in the profile and it requires root.

program that needs to be jailed can run as non-root (hence --user=non-root-user)

[netblue30]

The order Firejail applies the commands will prevent you from doing it. This is something that will work:

Start with a naked root sandbox where you apply the bind:

$ sudo firejail --noprofile --bind=t1,t2

Switch to your user:

# sudo netblue

Start the real x11 sandbox using --force:

$ firejail --force --x11 --net=eth0 xterm

Or you can do all in one line:

$ sudo firejail --noprofile --bind=t1,t2 sudo -u netblue firejail --force --net=eth0 --x11 xterm

[lepasserby]

I assume if I want to apply secomp filters or something like that, I'd best do that in the "last" firejail (the --force one) ?

Should first firejail come with --noprofile, or could it have one?

If "naked" firejail is started with a specific profile, would the second (--force) one honor the profile (esp whitelist directive) ?

[netblue30]

Yes, seccomp is applied to the second sandbox. If you put it in the first sandbox, the second one will not start.

And yes, you can use also use a profile for the first sandbox, but don't put in anything that might prevent the second sandbox from starting, such as seccomp, caps etc. Whitelisting should work in the first profile.

[lepasserby]

Okay, thanks!

Last (maybe) question (tangentially related, but might deserve own issue)

Let's say I want to run program in a "hollow" non-persistent homedir (as achieved by --private) but want to make one specific directory in the new homedir available to host and/or persistent.

What profile and command line directives and in what order would achieve that ?

[netblue30]

You would use --whitelist. Example:

$ firejail --whitelist=~/somedir

will create a "hollow" /home/user directory with /home/user/somedir imported form the filesystem and it will be persistent.

[djfd]

just a couple of cents,

there is a patch allowing to mount a few home subdirectories in bind mode, thus their content is fully synchronized between a host and sandbox.

I do not know how secure it is, is it possible to escape somehow using such kind of binding or not...
Experts advises and thoughts related to this approach are very welcome!

binding-home-subdir.patch.txt

[netblue30]

Thanks, I'll look into it.

[chiraag-nataraj]

Isn't --force deprecated now? So how would one do this with the newer firejail versions?

[tonsimple]

@netblue30 @chiraag-nataraj

I too have an interest in launching firejailed apps from a limited user, but in a firejail environment that was initially set up using "root-stuff"

"--force" still works for me (version 0.9.44.8 Debian 8) but if it is "on its way out" that may cause issues for me later on so I would like to know what's best practice is for the kind of thing I'm doing

P.S.:
Also, I would like to humbly request the return of --user command line switch. I realize there are probably practical reasons for its removal, but it was so comfy

[Vincent43]

It was removed due to security concerns so I doubt it will be ever restored.

[tonsimple]

@Vincent43
Woah, that sounds bad.

@netblue30 , is running firejail "as someone else" unsafe in principle, or is it just --user implementation that was not very safe?

I'm currently doing

run firejail as root, set up environment, then use daemonize binary (easy to build on most platforms) to run another firejail with --force and proper profile (including seccomp and capability filters) . Seems to be working fine and daemonize offers a few neat bells and whistles.

using su to launch second firejail also works, I just kind of like daemonize more.

Is such a methodology somehow bad?

[rusty-snake]

Something like --bind-home=s,t would allow a lot of workarounds, I'm thinking #3139, …