Would it be safe to assume this provides firefox with similar sandboxing that chrome has on a linux system.? Sorry i have not looked at this app very closely. Looks very interesting.
I would say: yes! Firejail basically applies the same technologies which are used for Chrome/Chromium. It even goes one step further: While the renderer in Chrome doesn't have access to the file system, the broker has. With Firejail this is also controlled by blacklisting specific folders/files. That's why someone else in this thread called Firejail a sort of "AppArmor light". One possible difference, though, is that Firejail's seccomp-bpf filtering disables a default list of system calls while the list of disabled system calls in Chrome is probably optimized for this application. However, I think that the default list in Firejail contains the security-relevant ones and is therefore good enough (particularly in combination with the SUID/user namespeces sandbox and dropping all capabilities).
This isn't a firejail issue, I think. I've experience the same thing on Debian without firejail, and on Arch without firejail.
It is firejail. I manually start pulseadio and everything is fine, I hit "firejail vlc" and pavucontrol/pulseaudio is down. I can endlessly repeat this process
Thanks I did..just wonder what kind of additionally information I could provide: https://github.com/netblue30/firejail/issues/70
I also wonder: is there a way to automatically firejail specific programs without running them as "firejail" manually ? I mean, if a program tries to run "firefox", then it will start firefox and it won't be firejailed... but it would be nice if "firefox" automatically gets firejailed, no matter how it got started ?
The way I do it in KDE is by opening the KDE Menu Editor and then changing the "command" line so that "firejail --options" are in front of whatever is there. KDE is the easiest Desktop Environment to work with this kind of variable, IMO. I'm looking forward to learn how to do so in MATE.
It's probably not Firejail. How could if affect Pulseaudio at all? Hhere's what happens to me sometimes: https://i.imgur.com/2R7k5rq.png You can see Pulseaudio itself fails to do something, there must be something in pulseaudio itself since Firejail can't interfere with it (I think). EDIT: Apparently this worked: https://github.com/amarildojr/Arch-Linux_what-to-do/blob/master/pulseaudio
It is firejail which crashes pulseadudio. Check firejail git for a guide on how to fix it. (disable smbchannel). Still wondering how I can prevent firejail from deleting my "last session".
Well, it worked only for a little while. I had to keep killing and starting pulseaudio. I tested Arch without Firejail and pulse still crashes. Debian Jessie with Firejail doesn't seem to have this problem in my case.
Is there a way so that apps will automatically get firejailed no matter if I run them with "firejail" or not? E.g. no matter how hexchat gets started (e.g. by clicking on an irc:// link), it will always be firejailed?
Yes, it is. Read the articles about Default applications and xdg-open in the Arch Linux wiki. Example: I'm using Debian Jessie with KDE and I've firejailed Okular by starting it with firejail okular in the KDE menu. However, when I clicked pdf attachments in, e.g., Thunderbird Okular was opened un-firejailed. So I executed: Code: xdg-mime query default application/pdf and got: Executing Code: locate okularApplication_pdf.desktop yielded: I simply modified the Exec= line in that file and all is well. In your case you could execute Code: xdg-mime query default x-scheme-handler/irc If you don't get anything you can define a default application, something like Code: xdg-mime default hexchat.desktop x-scheme-handler/irc I don't know if that's correct as I haven't hexcaht installed - but you get the idea. Notes: 1. If you have your own Firejail profiles defined in ~/.config/firejail I suggest to add the full path to those profiles to make sure that the application is properly firejailed even if you accidentally execute it as root. Example: Code: Exec=firejail --profile=/home/zakazak/.config/firejail/hexchat.profile hexchat 2. The relevant *.desktop files will probably be overwritten by updates of those applications. So it's probably a good idea to protect them by making them immutable with chattr. Example: Code: sudo chattr +i /usr/share/applications/kde4/okularApplication_pdf.desktop For details see man chattr.
@summerheat thank you for that precious info! Do you guys think Firejail is necessary if grsecurity is correctly implemented? I can't use Arch and Firejail because of that pulseaudio bug, but I will always be using Grsec.
Wow that is a good explenation but I still failed and have questions: 1. I tried doing "xdg-mime query default application/pdf" and its output was "kde4-active-documentviewer_pdf.desktop" altough I have okular installed as well ? 2. The command "locate kde4-active-documentviewer_pdf.desktop" didnt give me any output at all ? I couldn't try the other points/tasks obviously 3. Isn't there a "gui version" for that? E.g. in windows you have "default apps" or "prefered apps" where you could edit such things in the gui ? Btw I am on XFCE.. I got "prefer apps" but not real options in it. Thanks For me the solution from the github page of firejail is working fine on arch and pulseaudio ?
I don't know, I haven't tested it yet because some people say it "breaks" pulse and I absolutely need pulse working 100%. Does that fix actually breaks pulse? I'm on Debian Jessie at the moment but I'm already blanking a DVD-RW and will try Arch today.
It can be different from distro to distro and from DE to DE. Hm, strange. Perhaps you can try Code: sudo find / -name kde4-active-documentviewer_pdf.desktop
For me it 100% fixed the problem. That will give me an empty output again :/ Also: What kind of stuff can I actually blacklist ? E.g. what about: .dbus .gnupg .local .mono .nv .putty .bash_history .bash_logout .bash_profile .dmrc .esd_auth .ICEauthority .Xauthority .xfce-session-verbose-log .xprofile .xsessions-errors .config/xfce4 .config/xfce4-session etc etc ?
I'm not quite sure. From my understanding grsecurity mainly protects the kernel from being exploited while Firejail sandboxes specific applications. So they complement each other but might also overlap to some extent, though. If you're using RBAC this can probably replace Firejail's blacklist functionality.
Sorry, I'm lost. I cannot reproduce. You can blacklist whatever you want as long as it doesn't break your application. FWIW, netblue30 has added many new entries in disable-common.inc for the next Firejail version.