containers / bubblewrap Public
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
breaks with /proc/xen mounted (QubesOS) #134
Comments
|
Looks like the combination of If I remove any of those options, Running with Any idea? |
|
So, the kernel disallows mounting proc in the user + pid namespace. That is weird. Clearly it has mount capabilieites, because earlier mounts succeeded. In the upstream kernel, procfs has: This flag (FS_USERNS_MOUNT) should allow mounting a new proc instance in a user namespace. Does the qubes kernel change this in any way? |
|
And anyway, the debian build of bubblewrap uses setuid, so it should have capabilities in the parent namespace too. Very weird. Does qubes itself use namespaces? |
|
This flag (FS_USERNS_MOUNT) should allow mounting a new proc instance in a user namespace. Does the qubes kernel change this in any way?
No, the kernel is very close to upstream one. Also we don't use
namespaces... It's really strange.
…--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
|
I wonder if its related to this: https://lwn.net/Articles/644932/ |
|
|
I don't have a xen build, but reading the code it seems this is the problem: This is created if you have the However, as far as I can see in the kernel that isn't enough to make it realize that this is an "empty" directory, and thus the /proc/xen mount is not covering anything. It should really call proc_create_mount_point("xen") for this to work. Can you try disabling that kernel config option? (or fixing the mountpoint as per the above). |
|
Indeed after unmounting |
|
If you want to be conservative, it might work to add a patch to bwrap to unmount it? |
|
(Just in the new mount namespace) |
|
That sounds awesome! Please do!
|
|
No, we can't unmount it. Thats the problem essentially. If /foo and /foo/bar are mountpoints when we create an unprivileged user namespace, then we get the two inherited as a unit, and we cannot unmount /foo/bar, because that may expose files under it that was not visible in the parent namespace. The same actually is true for mounting a new procfs instance, if /proc/foo was overmounted in the host, then we can't mount a fresh /proc, because we can see into foo where we couldn't before. Of course in some cases we know it is safe, because foo is always empty, because the only reason its there is as a mountpoint. In such cases the kernel marks these directories as "always-empty", and mounts on top of them is not considered to cover anything, thus allowing a fresh proc to be mounted. Changing proc_mkdir("xen", NULL) to proc_create_mount_point("xen") in the kernel would fix it, as the xen directory is then not considered covered. |
|
@alexlarsson Can we take advantage of the fact that we are suid to forcibly unmount |
|
The suid path isn't the future though. Based on comment #134 (comment) it sounds like Qubes is going to disable the legacy mountpoint which should address this issue, right? |
|
A quick |
|
@cgwalters bwrap is suid at least on my system, and it would be nice to use it to solve this problem. |
|
Also apparently several legacy scripts in Quebes rely on |
Not that many. There is only one thing that is still used from that - |
|
This is still broken as of today in Qubes 3.2 with Fedora 27 template. Notably, it breaks video thumbnailing in Nautilus (and presumably other programs, whose video thumbnails do not show up): Please fix this. |
Using Qubes Debian
jessiebased AppVM with bubblewrap from jessie-backports (version0.1.4-2~bpo8+1).(Neither AppArmor nor grsecurity is being involved.)
Here are instructions on how to reproduce this in Qubes:
QubesOS/qubes-issues#2540
A simple test
bwrap --ro-bind / / --proc /proc --dev /dev /bin/bashworked for me.Outside of Qubes, i.e. in a Non-Qubes Debian jessie (VirtualBox) VM
sandboxed-tor-browserworks fine.So I guess "something that Qubes does breaks bubblewrap". Could you help us please making this more specific?
I've been advised to:
Do you know why this is happening? How to fix this? Want any debug output? If you like a rebuild how bubblewrap with debugging enabled, where do you find build instructions?
The text was updated successfully, but these errors were encountered: