qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
tilpner has quit [Quit: tilpner]
tilpner has joined #spectrum
xwvvvvwx has quit [Quit: ZNC 1.7.5 - https://znc.in]
xwvvvvwx has joined #spectrum
<qyliss> Been thinking about sharing files between VMs
<qyliss> The plan that sounds best to me is to have a 9p server written in a safe language that uses its own userspace ext4 implementation or whatever to avoid mount(2), and that only supports very simplistic paths (notably no "..", so there can be no risk of directory traversal attacks)
<IdleBot_5e50c57d> It looks like we might want to start with a standalone 9P server, and given the preference for Rust, rust-9p seems like a reasonable bet
<IdleBot_5e50c57d> I should try to package it already
<qyliss> Will need to be modified to avoid mount(2)
<qyliss> Because using the Unix file system is asking for trouble
<IdleBot_5e50c57d> What is the scenario where avoiding mount helps?
<qyliss> Kernel fs bugs
<IdleBot_5e50c57d> If it uses a local chunk of data, whatever can corrupt it, can corrupt it in any case
<IdleBot_5e50c57d> A from-scratch _ext4_ implementation will have more bugs.
<qyliss> Doesn't need to be ext4
<IdleBot_5e50c57d> (Re:CrosVM love for /dev/log: it _might_ agree to having a /dev/log as a socket to /dev/null, yay socat)
<qyliss> You might be right though that it's not critical right away
<qyliss> We can start with a normal 9p server without ..
<IdleBot_5e50c57d> It was not me who started mentioning ext4! Anyway: my point is, performant, clean rewrite, few bugs, choose two
<qyliss> We'll also have to check how hard links and stuff are handled
<qyliss> The nice thing about a userspace fs impl would be that it would be impossible to escape to the rest of the fs
<qyliss> We can use a filesystem namespace and get that to some extent
<IdleBot_5e50c57d> Well, to be completely honest a non-root 9p server on the host seeing _only_ /nix/store and sharing it to VM that then reshares whatever does not sound like our biggest escape risk for a long time
<IdleBot_5e50c57d> I expect escaping rust-9p to be work, and then it should just give attacker weird paths, but without breaking resharing-VM kernel these paths are what VM is allowed to see which is still /nix/store
<IdleBot_5e50c57d> OK, sorry, I have a class in ~10 minutes.
<qyliss> np
<qyliss> I have some direction now, at least.
<IdleBot_5e50c57d> OK, now I am kind of surprised. I applied the stupid stuff abount isolated /dev/log to /dev/null. I can read but not execute the 9p-mounted stuff inside CrosVM, which is not obvious from mount options and requires disabling driver sandbox. The fun part: on NixOS VM overlayfs I cannot even read the files (even though I can read underlying readonly versions)
<IdleBot_5e50c57d> Of course, maybe I should just compile your kernel already
<qyliss> Haven't tried 9p on it yet, fwiw
<IdleBot_5e50c57d> It is not like I am afraid of writing some boot scripts, of course
<IdleBot_5e50c57d> But there is a slight feeling of what the hell; maybe it is CrosVM behaviour, of course
<IdleBot_5e50c57d> I am not sure I like the idea of 9p server being able to create such a problem, though
<IdleBot_5e50c57d> Or is it incomplete support for 9p.2000.L?
<qyliss> don't kow
<IdleBot_5e50c57d> (of course, just its dislike for 9p-server-in-jail is already enough to be annoying)
<IdleBot_5e50c57d> CrosVM seems to claim 9p.2000.L as a fully supported and the only supported version
<IdleBot_5e50c57d> Linux 4.x? Which part requires the ChromiumOS kernel, Wayland socket?
<qyliss> Yeah
<qyliss> For virtio_wl
<qyliss> They have 5.4 available now
<qyliss> Seems to work just as well but my updateScript has been broken (fixed it yesterday) so haven't updated all the packages
<qyliss> It also works if you extract just the virtio_wl patches. I don't think I got that into much of a state to push though
<IdleBot_5e50c57d> Hmm, wait, Nixpkgs unstable defaults to 4.19???
<IdleBot_5e50c57d> I guess for VMs we should not have problems with this version…
<qyliss> errApparently so
<qyliss> We should probably update that...
<IdleBot_5e50c57d> Aaaahhhhh. It is indeed the latest released LTS
<IdleBot_5e50c57d> Well, I guess 5.4 can be claimed to be that, but it is not yet in the longterm state
<qyliss> Oh, I see
<qyliss> I assumed it would be LTS as soon as it came out
<qyliss> But I guess it makes sense to let it mature a bit firs
<IdleBot_5e50c57d> I guess it is already a promised LTS, but as it is the latest stable right now, the LTS-use crowd could in principle be wary whether the amount of real-world testing is sufficient
<IdleBot_5e50c57d> But I do not care enough about stable NixOS branches or LTS Linux kernel branches
<qyliss> Me neither, particularly
<qyliss> But I'm happy enough to follow CrOS
<IdleBot_5e50c57d> Hmmm. I wonder if rust-9p is related to crosvm 9p implementation and so switching will not help. Not based on anything, just a worrying idea
<IdleBot_5e50c57d> Of course, it would also be funny if CrosVM 9p2000.L implementation is slightly different in a way that is unobservable on ChromiumOS kernel because of some patch
<qyliss> New Chrome time!
<qyliss> So we get to update all our CrOS packages :)
<qyliss> I am extremely tempted to buy whatchromeisit.com and redirect it to https://www.chromestatus.com/features/schedule, which I can never remember how to find otherwise
<qyliss> (Inspired by https://whatrustisit.com)