mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3078] Firejail and the reboot command #1930
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1930
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ShellCode33 on GitHub (Dec 12, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3078
Hey ! Thanks to you all for that amazing tool, became a huge fan immediately.
I'm trying to use firejail to retrieve execution traces of all the binaries available in my
/usr/binfolder, my script works really well, multiprocessed and all, but this morning I checked out my computer and it had been shutdown...So I tried the following :
(This is the command I use to exec all my /usr/bin binaries... If you have some advice to give me about some parameters I could add/change/remove, please tell me)
And boom my computer reboots... Which was kind of expected. But now my question is how can I prevent that ? Is there a specific syscall I could block using seccomp to prevent that from happening ? Or maybe a magical parameter ?
Hope to hear from you soon :)
@rusty-snake commented on GitHub (Dec 12, 2019):
What happend if you add
--seccompor at least--seccomp.drop=@reboot?1a1543f356/etc/templates/syscalls.txt (L51)Maybe this doesn't work with systemd?
@ShellCode33 commented on GitHub (Dec 12, 2019):
None of the two worked :(
I don't know if it's relevant at all but on my computer
/usr/bin/rebootis a symlink to/usr/bin/systemctl. I might be wrong but I think systemctl communicates (through sockets/dbus stuff like that) with systemd therefore the seccomp filters are not applied and systemd is still able to reboot the system. As a workaround I will simply blacklistreboot,halt,poweroffandsystemctlfor now, but it would be great to find something better !Also, I've read in firejail's manpage the following :
I am using that option for strace, could it be that
--seccompdoesn't prevent reboot because of that issue ?Side question, I was reading about http://man7.org/linux/man-pages/man7/pid_namespaces.7.html does firejail implements such mecanism ? It sounds really great in order to provide more isolation between processes, it would probably prevent the whole system from rebooting ?
From
man 2 reboot:@topimiettinen commented on GitHub (Dec 12, 2019):
DBus can be blocked with
--nodbus.@ShellCode33 commented on GitHub (Dec 12, 2019):
Thank you very much ! It was indeed that simple...
@rusty-snake commented on GitHub (Dec 13, 2019):
No, because the bug is before the 4.8 Verison of the kernel. Therefore there is no
allow-debuggersoption.However,
nodbusis the solution.@jonleivent commented on GitHub (Jan 24, 2020):
I have run into a similar issue and nodbus does not work for me. Specifically, from what I believed to be an extremely restrictive firejail profile (below), I can still issue systemctl commands (the host is running systemd). This is in Debian 10 Buster with its standard firejail version 0.9.58.2. The profile in question is:
The profile has nodbus, caps.drop all and seccomp. But I can still issue various systemctl commands (including suspend, shutdown, reboot) from within the firejailed xephyr session with this profile. They emit warnings, but still cause the host to obey to various degrees. For instance, systemctl reboot causes a shutdown with no reboot. That probably indicates a very partial interference by the above profile with systemd's systemctl, but certainly not enough.
One question is whether this is because 0.9.58.2, even though current in Buster, is out of date. If so I will try to upgrade first. If not, what is the fix?
Also, if the issue is fixed after 0.9.58.2, should this be considered a major security bug, considering how restrictive the above profile is supposed to be, and how widely used Buster (Debian stable) is? In that case, even if the problem is due to the version being 0.9.58.2, should a newer version with a fix be pushed to Buster?
@jonleivent commented on GitHub (Jan 25, 2020):
blacklist /run/systemdseems to prevent all systemctl calls. I suggest adding that to disable-common.inc@ghost commented on GitHub (Jan 25, 2020):
IMHO this is not a security bug. Although the profile you showed above is indeed more restrictive, that doesn't mean it is restricting usage of systemctl.
Apparently that breaks on Arch when systemd-resolved is used. See the comments in disable-common.inc on line 151-152. We could add another comment clarifying this behaviour, and advise users who DON'T use systemd-resolved to add it to their
disable-common.local.@jonleivent commented on GitHub (Jan 25, 2020):
Is there a difference between blacklisting /var/run/systemd and /run/systemd?
It would be nice to have a portable way to disable powerful systemd calls in all cases, though. I'm using suspend/shutdown/reboot to illustrate the hole, but I'm not at all confident those are the only cases that could cause security problems. Could malicious software use a systemd call from within a jail to schedule arbitrary code for later execution outside the jail, for instance?
@ghost commented on GitHub (Jan 25, 2020):
@jonleivent
No, /var/run is symlinked to /run. Is that not the case on Debian 10 Buster?
If you know upfront which commands/files you need inside the sandbox, you can use
private-binand/or create a whitelist profile. If you don't, you can always block systemd by adding:I left out the systemd directories under ${HOME} because you use private /home/jil/jailedhomes/common-wm in your profile, so those would already be non-existing (unless you recreated them
in /home/jil/jailedhomes/common-wm).
If by
the holeyou mean you can run any command that is not explicitly blacklisted inside a sandbox, sure, there's always potential risk. To minimize such potential risks firejail uses security profiles per application. Do you use your common-wm profile like a 'prison' to run all kinds of applications in?@jonleivent commented on GitHub (Jan 25, 2020):
It doesn't look like /run/systemd and /var/run/systemd are symlinked, but they are identical on Debian. Perhaps they are just two mountpoints for the same virtual fs.
That common-wm profile is my first attempt at running a small WM (note xephyr in the profile) session entirely within a very restrictive firejail that will run several apps together. I am much more familiar with customizing firejail profiles for particular apps, but need this one general case where many apps run together and can't get out (or observe the outside) using the X11 socket or anything else - something which I had previously been using a virtual machine to accomplish. That's the reason for calling it a "prison" - high walls, no way out, multiple occupants.
I admit a bit of surprise and panic because I thought it wouldn't need more restrictions than I initially gave this profile to prevent systemctl shutdown/suspend/reboot. And worried further when I read this issue had previously been resolved by nodbus. Obviously, systemctl is managing to get a signal out of this firejail somehow. What stops some other app which I may use in this particular jail from using the same hole to signal out, even if every systemd app is blacklisted?
I will be adding either private-bin or a whitelist profile. I know there's a way to prevent any particular app from executing. The issue is those things which I do need to execute within the "prison" and whether any could get a signal out using the same technique as systemctl.
@rusty-snake commented on GitHub (Jan 25, 2020):
@jonleivent yes, firejail 0.9.60 relnotes:
8b930734d2/RELNOTES (L42)0.9.60/0.9.62 should be in the backports:
sudo apt -t buster-backports install firejail firejail-profiles@rusty-snake commented on GitHub (Jan 25, 2020):
restrictive against a lot of things, but not against the filesystem.
@ghost commented on GitHub (Jan 25, 2020):
@jonleivent Thanks for further clarifying what you want to achieve. I'd recommend opening a new issue, as this one has been closed and not many users actively follow those. You can always refer to this thread for problem clarification/potential attack vectors etc., but I think you will get more feedback doing so.
You're probably already familiar with a few basic tips, but let me repeat them here nonetheless. There's an (older) X11 Guide that might be of interest. Besides that, both
/etc/firejail/default.profileand/etc/firejail/Xephyr.profileoffer good starting points for building/hardening your WM profile. There are also a few xephyr-specific configuration options in/etc/firejail/firejail.config. One thing to keep in mind is that in a jail like this, all started applications will inherit the options of the original WM profile. So you will need to arrange access to config files, settings etcetera as you see fit.Personally I tend to disagree. The fact that one can shutdown/suspend/reboot a machine from within a custom sandbox is not the same as a security hole. If you don't want applications to perform such actions, you will need to explicitly prohibit them to do so. If you did prohibit them and it still is possible to esacpe the sandbox and shutdown/suspend/reboot/... that would be a different story.
Please don't read my remarks as dismissive of your basic idea itself. It's more a matter of design and security is a matter of degree(s) IMHO. There are much more experienced and knowledgeable collaborators here that will be happy to share info on this - crucial - aspect of your setup. Again, by opening a new issue and being as clear as you can (including code examples) I do believe you will get more valuable information on a topic like yours.
HTH
@topimiettinen commented on GitHub (Jan 25, 2020):
systemctl reboottalks to DBus via/run/dbus/system_bus_socket, not something under/run/systemd. If in your system/var/rundoes not point to/run(as it should), Firejail probably isn't blocking the other path to the DBus socket.@jonleivent commented on GitHub (Jan 25, 2020):
I was mistaken about Debian - it does symlink /var/run -> /run. Sorry for the confusion about that.
@rusty-snake
I will try 0.9.62-2, which is in Debian backports, to see if I can use systemctl there even with nodbus set - but need to prepare for that upgrade as I have many existing firejails working in 0.9.58-2, so that will take some time.
I noticed that:
prevents the suspend even though --nodbus instead of blacklisting /run/dbus did not. I would have thought the two were equivalent before. It is too bad I can't blacklist all of /run (xephyr fails to connect to any clients when I try that), or create a private /run - that would be a better option.
@glitsj16
I know that all apps running in the same jail inherit the original profile - and that is precisely my intention here. Thanks for the pointers - yes I am familiar with them. I did alter /etc/firejail/firejail.config with respect to xephyr, but mostly to give xephyr some other command-line options, like '-s 0' to prevent screenblanking. It would be nice if there was a way to pass xephyr command line options through the firejail command line or user profile somehow instead of editing /etc/firejail/firejail.config.
Unfortunately, AFAICT the firejail documentation is not comprehensive. I posted elsewhere that the documentation does not explain how or even whether certain combinations of options work. Another is in what cases command line options override profile options. There are a few others that one must use trial-and-error to determine - but since they are not documented, one wonders about their stability across releases. Which is a reason it will take me a bit of time to upgrade to 0.9.62-2.
@rusty-snake commented on GitHub (Jan 25, 2020):
This is the case since firejail 0.9.60, see
4814096e10.To get the firejail 0.9.60 behaviour in 0.9.58, you can add
?HAS_NODBUS: blacklist /run/dbus/system_bus_socketto your globals.local.@jonleivent commented on GitHub (Jan 25, 2020):
Even with all of these mitigations against dbus usage, if I --join the jail, I can again do
systemctl syspendfrom the joining app. In fact, many - perhaps all - blacklisted items are visible from the joining app. I thought that would only happen if I joined as root, which I am not doing.@rusty-snake commented on GitHub (Jan 25, 2020):
🤦♂️ abstract unix socketssudo ss -x.@ghost commented on GitHub (Jan 25, 2020):
Please share your complete profile and exact commands here so we can try to reproduce.
@jonleivent commented on GitHub (Jan 25, 2020):
Profile:
Obviously you will need to change the private directory location. And, yes, lots of blacklist redundancy.
Commands:
I first noticed the issue because I started a toolbar app (tint2) by doing a --join, then launched apps (such as urxvt) from the toolbar. I can work around this by using icewm-session instead and launching a toolbar from the session startup file, or having icewm use its own (not so great and somewhat buggy) toolbar.
firejail is 0.9.58.2, host OS is Debian 10.2 stable (Buster), MX 19 with systemd.
From within that urxvt (or any term you want), you can do systemctl commands and see into all blacklisted items. In that term, do an ls on /usr/share/systemd (blacklisted) for an example.
@rusty-snake commented on GitHub (Jan 25, 2020):
Remove
read-only /, more infos will follow.@rusty-snake commented on GitHub (Jan 25, 2020):
read-only /does not work any more (dba9dff, 0.9.62).@jonleivent commented on GitHub (Jan 25, 2020):
Can I
read-onlyall real dirs under / ?@ghost commented on GitHub (Jan 26, 2020):
@jonleivent I installed icewm and uxrvt and did some testing. I only changed the private item to something that exists on my system. And I left out the now broken read-only /. Here are my observations.
To me that looks just fine. The jail works OK. You can indeed see /usr/bin/systemctl inside the jail but it is an empty file with perms 0400.
@jonleivent commented on GitHub (Jan 26, 2020):
@glitsj16
I am finding similar with testing. And read-only on subdirs of / doesn't appear to interfere.
Perhaps
read-only /should emit an error? Or maybe just read-only all real subdirs of /. I doubt I'm the only one dumb enough to thinkread-only /enhances security.@rusty-snake commented on GitHub (Jan 26, 2020):
@jonleivent it does it in 0.9.62
@glitsj16 if you use firejail <=0.9.60 you will be able to reproduce.
@smitsohu commented on GitHub (Jan 26, 2020):
It is a regression, I'll put a fix in.
@smitsohu commented on GitHub (Jan 26, 2020):
Fixed in
afb7e0363b.@jonleivent Note that the root directory is still a special case: Unlike all other remounts,
read-only=/is not fully recursive. If you try to create a new file/foo, it fails as expected in such a sandbox, but you can still write in some places, for example in/run/user/$UID. And actually we need some kind of special treatment, because Firejail expects some paths to be writable and cannot run otherwise.If you want a fully recursive read-only remount, you need to do
read-only=/etc,read-only=/usr, ... and so on on top ofread-only=/. But also note that Firejail does most of this already out of the box. From the manual:Probably we should document this exception though and drop a sentence in the man pages.
@jonleivent commented on GitHub (Jan 27, 2020):
@smitsohu
I was never clear what "default" meant in "The default Firejail filesystem". I had always though it meant what firejail did if run without a profile (so using the default profile), but that once a profile was used, the profile writer was in control. But, yeah, everything I've been trying to do above was based on that mistake. I've never bothered to look at default.profile before, and now that I am, I can see how mistaken I was about that.
Perhaps to clarify things for the semantically confused such as myself, it would be better if the man page said "Firejail always starts, prior to any additional command-line options or profile settings, with a filesystem that is based on the host filesystem with main system directories mounted read-only".
@jonleivent commented on GitHub (Jan 27, 2020):
It might also be helpful if firejail, when it sees an option like
read-only /etcthat can't possibly add any new protections beyond what is always present, issues some warning to users, and then ignored the useless option.