Mounting images inside a user namespace
Mounting images inside a user namespace
Posted Jun 14, 2023 12:29 UTC (Wed) by bluca (subscriber, #118303)In reply to: Mounting images inside a user namespace by karim
Parent article: Mounting images inside a user namespace
Posted Jun 14, 2023 12:34 UTC (Wed)
by karim (subscriber, #114)
[Link]
Personally if that UML instance is wrapped around tools for just filesystem manipulation then I honestly don't care so much to just grab the latest stable release from kernel.org, building it and deploying it for that purpose. Again, with just that use-case in mind: accessing random FS images.
For me, having to actually think about the trustability of the FS image in question is a step too many. For all I care, the image could be maliciously crafted and I want to not think about it.
Posted Jun 14, 2023 13:10 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (20 responses)
Hardening the file systems in question appears to be more expensive than that, esp. given that not even the file systems' fsck maintainers are willing to guarantee that an fsck-clean file system wont' crash the kernel.
Posted Jun 14, 2023 13:43 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (19 responses)
Except of course nobody really does that, apart from a handful of hackers on their 'pet' systems.
> Hardening the file systems in question appears to be more expensive than that, esp. given that not even the file systems' fsck maintainers are willing to guarantee that an fsck-clean file system wont' crash the kernel.
Hence why the rest of the article
Posted Jun 14, 2023 13:53 UTC (Wed)
by karim (subscriber, #114)
[Link] (14 responses)
Oh, now that's very constructive. Pigeonholing an approach by marginalizing an audience. Do you feel better now? Do you think you've actually achieved anything?
Now, please explain why Ubuntu, Debian, Fedora, etc. couldn't just do "make" twice on the same kernel as was precisely suggested to you before and ship that UML version with possibly some scripts around it to facilitate looking at any image that the Linux kernel already supports without any changes to any fsck or requirement for any trust on any images. How harder would that be? In fact, how hard would that be for Joe User if they had to just grab the sources of the distro kernel they're already using and rebuild it for UML even if the distro didn't do this?
Posted Jun 14, 2023 14:03 UTC (Wed)
by zdzichu (guest, #17118)
[Link] (7 responses)
Posted Jun 14, 2023 15:05 UTC (Wed)
by geert (subscriber, #98403)
[Link]
Posted Jun 15, 2023 7:59 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (5 responses)
Posted Jun 15, 2023 8:51 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (4 responses)
In most distros today, you build one kernel per CPU architecture you support - so there's one AMD64 kernel, one AArch64 kernel, one RISC-V 64GC kernel etc.
You'd need to repeat that with UML for each CPU architecture you support, thus doubling the number of kernels you build - instead of building one kernel per supported architecture, you'd build two.
Posted Jun 15, 2023 12:19 UTC (Thu)
by karim (subscriber, #114)
[Link] (2 responses)
Posted Jun 15, 2023 13:40 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (1 responses)
For starters, UML is currently x86-only; so using UML as your filesystem handler means porting UML to the other architectures, and taking on the security and code maintenance burden that represents.
Then you need a trustworthy IPC mechanism with the host kernel; something that allows the UML kernel to read/write the block devices it's managing, and a trustworthy filesystem protocol to share the FS from the UML kernel to the host kernel. Again, both of these add to the security and maintenance burdens.
Alternatively, you could go the ChromeOS route - the only filesystem used on external devices is FUSE from the kernel point of view, and you run userspace filesystem implementations that have been deliberately and intentionally hardened, and can be sandboxed heavily - you can design the userspace component to accept the FS as one file descriptor, and the FUSE interface as the other, and sandbox it such that all you have is anonymous memory plus accesses to those two file descriptors. This has the advantage over UML that the process that mounts the filesystem is designed to only read that one FS, and no others; so there's a much smaller attack surface to begin with.
Posted Jun 15, 2023 13:43 UTC (Thu)
by karim (subscriber, #114)
[Link]
Posted Jun 15, 2023 12:53 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Posted Jun 14, 2023 14:49 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (5 responses)
Pet vs cattle is a well-known and widely used phrasing to describe the dichotomy between power users' custom systems vs large scale deployments. If you take offence at that categorization go complain to the tech press industry, as they're the ones who came up with it. Or not, but in either case, please stop bothering me.
> Now, please explain why Ubuntu, Debian, Fedora, etc. couldn't just do "make" twice on the same kernel as was precisely suggested to you before and ship that UML version with possibly some scripts around it to facilitate looking at any image that the Linux kernel already supports without any changes to any fsck or requirement for any trust on any images. How harder would that be? In fact, how hard would that be for Joe User if they had to just grab the sources of the distro kernel they're already using and rebuild it for UML even if the distro didn't do this?
Given the number of times that has happened is precisely 0, I'd wager the answer lies somewhere between "harder than you'd think" and "it's just such a stupid idea that nobody could ever be bothered". Your pick.
Posted Jun 14, 2023 14:52 UTC (Wed)
by karim (subscriber, #114)
[Link] (4 responses)
I see. Thank you for clarifying the type of debate you like engaging in. I, for one, have better things to do in life.
FWIW, you've just help me convinced myself that the UML approach is likely the better one. Thank you.
Posted Jun 14, 2023 18:30 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (3 responses)
Posted Jun 14, 2023 18:55 UTC (Wed)
by karim (subscriber, #114)
[Link] (1 responses)
<spits-coffee-laughing/>
Buddy, I don't think you understand. I have no compunction butting heads with anyone. Let's just say that I've had my fingers caught in a few lkml flame wars circa 20 years ago and it was great fun. But, if you will, blame it on getting old ... I don't have the time to waste on the sort of debate you seem to want to have.
My position still stands. UML is the cleanest way to do this because: a) it works today, b) it doesn't need any changes to any tools, c) it doesn't require me to make any assumptions regarding the safety of the images I want to access.
Your semantic side-show changes nothing to this.
Posted Jun 15, 2023 10:36 UTC (Thu)
by bluca (subscriber, #118303)
[Link]
Posted Jul 19, 2023 9:36 UTC (Wed)
by nye (subscriber, #51576)
[Link]
Posted Jun 14, 2023 14:20 UTC (Wed)
by leromarinvit (subscriber, #56850)
[Link] (3 responses)
I assume most people use distro kernels. So the obvious way to get something like that into the hands of average users is for distros to package it. For the user, the cost of having a UML kernel that's in sync with their regular kernel would just be a bit of disk space and network traffic for updates.
People who build their own kernels will probably be technical enough to understand how this works, and to make an informed decision whether they want to also build a UML image when they upgrade (the alternatives would be either continuing to use an older one, with all the potential pitfalls this entails, or disabling this mechanism entirely).
Posted Jun 14, 2023 15:06 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Jun 14, 2023 15:58 UTC (Wed)
by leromarinvit (subscriber, #56850)
[Link] (1 responses)
As for the merits of the UML approach (or something like lklfuse) vs what's described in the article, for one, it could be used with arbitrary file systems. Special trusted images seem like a non-starter for random removable media. (But of course that's an entirely different use case than for containers - I see no reason both approaches can't live side by side.)
What are your security concerns with the UML approach? The worst thing a malicious fs image could do is compromise the UML kernel - so a user-space process. What that process can do can be suitably constrained using the same methods as for any other user space application - of course it shouldn't be allowed to access any other device than the image in question, or access the network or any such things. The security boundary would then be the interface used to connect to the "host" kernel (be it 9p, NFS, FUSE, or something else), and whatever is used to sandbox the UML process.
It seems the alternative most everyone is using today (for removable media) is to just look the other way and mount it directly in-kernel. This seems to be strictly worse to me, security-wise.
Posted Jun 14, 2023 17:58 UTC (Wed)
by bluca (subscriber, #118303)
[Link]
In the "user plugs USB drive" use case, the status quo is terrible, as the kernel developers go 'lalala can't hear you', and desktop developers simply stick udisks in and allow mounting anything that is plugged in. This is of course bad, so any movement toward improving, like the already suggested FUSE approach, seems good, and the proposal in the article is not aimed at this.
The proposal in the article is aimed at the use cases where status quo is simply: you cannot do that, full stop. So to enable that use case, we need to take security seriously. And that's where establishing trust _before_ use is fundamental - if you 'only' compromise your local container manager instead of the kernel, sure it's less bad, but it's simply still unacceptable where this matters. UML uses the exact same drivers as the normal kernel, which are just as, let's say, not guaranteed to be robust against malicious images, so just shouting SANDBOXING and turning the other way, while a step up, it's nowhere near good enough.
Not to mention the fact that someone mentioned UML is x86 only, which again is a non-starter - arm64 is not only a thing, it's an important thing. And the whole maintenance angle, of course.
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
...
> Given the number of times that has happened is precisely 0, I'd wager the answer lies somewhere between "harder than you'd think" and "it's just such a stupid idea that nobody could ever be bothered". Your pick.
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace
Mounting images inside a user namespace