I believe it would be interesting to add an optional firejail USE flag to further isolate dnscrypt and unbound, as firejail includes profiles to deal with both of them. It's as simple as forcing either program to execute with the prefix 'firejail'.
this is virtually guaranteed not to be implemented upstream, because it would mean unbounded work. imagine another sandbox program comes along, each upstream has to reimplement wrappers? what is plausible is if firejail would install init scripts that would automatically run the services inside the jail. alternatively, and more portably, the packages could implement namespaces/seccomp themselves. however, you would have to file bugs upstream for that.
(In reply to Alex Xu (Hello71) from comment #1) > this is virtually guaranteed not to be implemented upstream, because it > would mean unbounded work. A simple USE flag would suffice. Implementing it is trivial, as it only requires an extra dependency and changing the init script to include the 'firejail' prefix. >imagine another sandbox program comes along, each > upstream has to reimplement wrappers? There are plenty already. Vagrant, LXC, AppArmor, SE Linux, to name a few. I just prefer firejail because I find it more modular and easier to work with. It's also more malleable in that I can unbreak things more easily. Like I said, implementing this is quite easy, as firejail already contains profiles for a myriad of programs. > alternatively, and more portably, the packages could implement > namespaces/seccomp themselves. however, you would have to file bugs upstream > for that. How's that more portable? It requires more developer hours and amount of features would depend on a per-software basis. Firejail is a more unified solution. >what is plausible is if firejail would install init scripts that would automatically run the services inside the jail. You mean running a myriad of programs inside a jail, as opposed to one per jail? Because that would actually undermine security, as each program would have access to folders that would otherwise not be whitelisted (the ones that don't use the generic profile, like firefox, unbound, dnscrypt, chromium, and so on). List of firejail profiles: audacious.profile bitlbee.profile chromium-browser.profile chromium.profile clementine.profile conkeror.profile deadbeef.profile deluge.profile disable-common.inc disable-devel.inc disable-mgmt.inc disable-secret.inc dnscrypt-proxy.profile dropbox.profile empathy.profile evince.profile fbreader.profile filezilla.profile firefox.profile generic.profile gnome-mplayer.profile google-chrome-beta.profile google-chrome.profile google-chrome-stable.profile google-chrome-unstable.profile hexchat.profile icecat.profile icedove.profile iceweasel.profile login.users midori.profile nolocal.net opera-beta.profile opera.profile parole.profile pidgin.profile qbittorrent.profile quassel.profile rhythmbox.profile rtorrent.profile server.profile skype.profile spotify.profile steam.profile thunderbird.profile totem.profile transmission-gtk.profile transmission-qt.profile unbound.profile vlc.profile webserver.net weechat-curses.profile weechat.profile whitelist-common.inc wine.profile xchat.profile
Nevermind, I understand what you meant with the last paragraph. I believe if that were to happen, netblue30 would most likely write init scripts for the most popular init system, systemd. Would be a LOT more work for him.
It is actually quite interesting to have some kind of integration. It seems wrong that user would have to modify init scripts him/herself. Also, I don't think it's something for upstream to do.
(In reply to Amadeusz Żołnowski from comment #4) > It is actually quite interesting to have some kind of integration. It seems > wrong that user would have to modify init scripts him/herself. Also, I don't > think it's something for upstream to do. Precisely, and for stuff like unbound and dnscrypt, which are pieces of software designed to do few things, it's considerably better, more secure and, dare I say, 'tidier'/'neater' to have a USE flag for an alternative init script and dep (firejail) at no cost. I don't get it though: do you believe the USE flag should be on firejail's side, as opposed to dnscrypt/unbound's?
(In reply to cristiano04 from comment #5) > I don't get it though: do you believe the USE flag should be on firejail's > side, as opposed to dnscrypt/unbound's? No. In that case firejail would have to overwrite init script of other package. Flag for dnscrypt/unbound seems to be OK, but maybe we can have even more generic solution. Firejail has some predefined profiles, but it's actually quite simple to define more - for anything. I am thinking about integrating it with OpenRC, but I haven't done any research on that yet, so I don't know if that's possible.
(In reply to Amadeusz Żołnowski from comment #6) > (In reply to cristiano04 from comment #5) > > I don't get it though: do you believe the USE flag should be on firejail's > > side, as opposed to dnscrypt/unbound's? > > No. In that case firejail would have to overwrite init script of other > package. Flag for dnscrypt/unbound seems to be OK, I'm with you on that. >but maybe we can have > even more generic solution. Firejail has some predefined profiles, but it's > actually quite simple to define more - for anything. I am thinking about > integrating it with OpenRC, but I haven't done any research on that yet, so > I don't know if that's possible. OpenRC integration would be GREAT, something like 'rc-update --jails add dnscrypt-proxy'. There are generic profiles, and you don't need to do much else. If you need to whitelist a directory for a daemon, you do so by editing /etc/firejail/*.profile, or the generic.profile. This is going better than I thought. Great idea, although you're going to have to edit a few ebuilds, like dnscrypt-proxy and unbound, since you will no longer benefit from using enewgroup and enewuser. At least, I don't think you will, correct me if I'm wrong. So ideally, dnscrypt's ebuild should use enewgroup and enewuser but ONLY if the firejail USE flag hasn't been set.
(In reply to cristiano04 from comment #7) > Great idea, although you're going to have to edit a few ebuilds, like > dnscrypt-proxy and unbound, since you will no longer benefit from using > enewgroup and enewuser. At least, I don't think you will, correct me if I'm > wrong. So ideally, dnscrypt's ebuild should use enewgroup and enewuser but > ONLY if the firejail USE flag hasn't been set. firejail doesn't provide full isolation. It still should switch to unprivileged user.
It seems to me the right place for this would be in either a specific package whose ebuild you want to teach about a USE=firejail that adds a DEPEND and then customizes that package's init script, or, a feature enhancement to openrc to add some knob to start-stop-daemon and such, to tell it to firejail $thing. But either way I think this should be a bug for one of those others, not for firejail itself, and this bug ought to be closed.
(In reply to cristiano04 from comment #0) > I believe it would be interesting to add an optional firejail USE flag to > further isolate dnscrypt and unbound, as firejail includes profiles to deal > with both of them. > > It's as simple as forcing either program to execute with the prefix > 'firejail'. It might be even easier than that. firecfg creates symlinks in /usr/local/bin/ for all (or the specified) supported programs, pointing to /usr/bin/firejail, which then reads its first argument to determine what it's supposed to actually run jailed. So, /usr/local/bin/unbound will be found first in $PATH and it'll behave just like if 'firejail unbound' was run. cristiano04 if you are still interested in this, please try making symlink(s) and running the init script normally. Does it find the /usr/local/bin/ versions, or is that not in $PATH during startup, and/or the full path to the regular executable is used instead? If that did not work, you could perhaps get a more generalized change implemented by those other packages: make it possible to override their primary executable by a variable in their conf.d file. For examples, see docker and fwknopd and how they assign *_BINARY variables: both have some default in the init.d script, if not overridden in their conf.d file. That would be a one-time change in those packages' init scripts that should be harmless for anybody not customizing their conf.d files. Either way I think this ceases to be a request about firejail, so I'm closing this bug. If you try one of the above methods and firejail does not behave correctly, please open a new bug.
