From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.4 Received: by atuin.qyliss.net (Postfix, from userid 496) id C373C138CF; Tue, 9 Mar 2021 16:26:29 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 35210138B8; Tue, 9 Mar 2021 16:26:06 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 6AE64138A2; Tue, 9 Mar 2021 16:26:04 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by atuin.qyliss.net (Postfix) with ESMTPS id BE1B6138A0 for ; Tue, 9 Mar 2021 16:26:00 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D06F25C019F; Tue, 9 Mar 2021 11:25:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 09 Mar 2021 11:25:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=gJx/G0wypWa2jN3pk+vPa/KrrCF dNu/M5f0BoSZEbaM=; b=J5cNgQLjoysco5sFmInoJEo4Jb5qS6aB7jaq1x1hqud V9VqPQBeF+jlKa9fAuuVg52EZpvZJYU3TvuoXEZbe2I95JtDqZH8PR3wT6UL/f/F AhjwAj9Y8hnWMywotOcZ2FjYJ1YtuFjPL7dQv81c5FPG6essgD3oL425QFDwIwUd m/nFbD/XDQOakK9DPE4Z2VBa/bwLeUJ0OgHoQBwmgSolOnbKhokipZmlTDEZ5kuW M1htrmb1p6S5D9PDKaHzbSGeYdY0jf9p6Fo/DYNj2nHE0grdmwP2EuXJ5HVZysCP c1ZDZJg7JcMvZ2JH155bL1XNkfHZ/klfrfC3HhzRsVg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gJx/G0 wypWa2jN3pk+vPa/KrrCFdNu/M5f0BoSZEbaM=; b=J4G0pIfCgXCoAUWA7VaZ8H PKT3MqMzItkgudE5KXDmeClsjz/qLRO26sAJfcWQgLwyIM99E3+/jU4z5hIsSLUc xwp58Vd9KOgpshPUPbTf54O+H73X/uTBU76LMse3OqP9gF+8jIuh87VZpKbYGx+i ZWOaYQqJV2GirpVEyTxJhV71rVG3Oq3yUlxuUAoqkw8LxVoxQDpfC6lQPpu6L2Og akBmmjVybhhiB2Av3chGYw4apSR20syL0sqjJxhJlh+kBQj5owIoh0Lj6w8xk6oH mnuALkWoOR37jotIcxmQKHKZhRlZ5k54b7GrN99qObe9YhLSF5U1XwBiyoFvi/Lw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduiedgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepfffhvffukfhfgggtuggjsehgtddtredttdejnecuhfhrohhmpeetlhihshhs rgcutfhoshhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpeelvd ekheeltedvvdduledvheeghefhgeejhfetieffvedttdeuteevueethedvjeenucffohhm rghinhepghhithhhuhgsrdhiohdplhifnhdrnhgvthenucfkphepjeelrddvfeehrdduvd dvrddugeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepqhihlhhishhsseigvddvtddrqhihlhhishhsrdhnvght X-ME-Proxy: Received: from x220.qyliss.net (p4feb7a91.dip0.t-ipconnect.de [79.235.122.145]) by mail.messagingengine.com (Postfix) with ESMTPA id D78141080064; Tue, 9 Mar 2021 11:25:58 -0500 (EST) Received: by x220.qyliss.net (Postfix, from userid 1000) id AB6B5120A; Tue, 9 Mar 2021 16:25:56 +0000 (UTC) Date: Tue, 9 Mar 2021 16:25:56 +0000 From: Alyssa Ross To: Thomas Leonard Subject: Re: New user getting started questions Message-ID: <20210309162556.ctiy3yfp7plkbdqs@x220.qyliss.net> References: <87ble2czx6.fsf@alyssa.is> <87lfcvn1ln.fsf@alyssa.is> <87bldrn0kh.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tx6sy2cymigsxqin" Content-Disposition: inline In-Reply-To: Message-ID-Hash: 2WUX6WKBMRQ7HQEXRVRZHGKT2W7JARWW X-Message-ID-Hash: 2WUX6WKBMRQ7HQEXRVRZHGKT2W7JARWW X-MailFrom: qyliss@x220.qyliss.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Michael Raskin <7c6f434c@mail.ru>, discuss@spectrum-os.org X-Mailman-Version: 3.3.1 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: --tx6sy2cymigsxqin Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Thomas! Thanks for keeping us updated. It's really great to have all this written up to read, even though I'm only getting to it a month and a half later. On Wed, Jan 27, 2021 at 05:31:08PM +0000, Thomas Leonard wrote: > I've made a bit of progress this week: > > It turns out that weston-terminal crashes sommelier if started when > the clipboard is empty, due to trying to dereference NULL. I've > patched it to fix that, and now I can run it directly under sommelier, > without wayfire. I made a few other changes to sommelier too: > > - I switched to the latest version, which provides meson instead of > common-mk for building. Also, they removed the demos and got rid of > some bogus dependencies. That simplified the build a lot! > - They switched to the stable XDG protocols, but then reverted it > again. I unreverted it to get things going again. Not sure if I did it > right (they migrated from C to C++ so the patch didn't apply > directly). This is great to know -- it sounds like maybe they're trying to make Sommelier more widely usable? Will probably be a while before I get to updating but this is very exicting. > - I added xwayland to the VM and sommelier command, allowing X > applications to run in the VM. > - By default sommelier runs the program with an already-open socket, > which doesn't work if the program (or its children) want to open > multiple connections. > I was able to fix that by using `--parent` mode, and getting rid of > PEER_CMD_PREFIX (which just adds some chromium paths preventing it > from working). > - Note: in `--parent` mode it waits for the process to exit before > processing events on the socket, so if you just run an application > directly it will hang. I used `bash -c 'firefox &'` as the command as > a work-around. > - Some programs (e.g. firefox) refused to start because the protocol > versions offered by sommelier were too old. I increased the version > numbers and that's working now. It needs doing properly, though. e.g. > I implemented the new "sl_host_surface_damage_buffer" by simply > calling the old damage function, which is obviously not correct but is > working for me so far! > - Annoyingly, using `--parent` disables xwayland support. Maybe we > should run xwayland manually, or use a second sommelier instance? > > In general, sommelier seems quite buggy and annoying. I guess it will > need updating constantly to proxy every new wayland protocol. Yet it > can't add any useful security because it runs inside the VM, and is > therefore untrusted. Yeah... > Some other changes that I found useful: > > - I added the generated kernel modules directory to rootfs, which > allows using all the normal features of Linux (e.g. ext4) in the VM. Ah, yes, that would remove a lot of gotchas. I have avoided that so far because I'm hoping to eventually build custom kernels that don't need many modules, to reduce code size in each VM. But it would probably make sense to do for now. > - I switched from `bash` to `bashInteractive` as the VM shell, which > gets cursor keys working. Good catch! I'll make that change in Spectrum as well. > - I wrote a Nix package to generate one script for each of my old > qubes. So e.g. I can now run `qvm-start-shopping` to start my crosvm > shopping instance, with its own /home LVM partition and IP address. It > passes the network configuration using some new kernel parameters > (alongside spectrumcmd). > - I put each VM on its own point-to-point virtual network. These > networks are set up by /etc/nixos/configuration.nix. That works well > for my qubes-like VMs, though I guess spectrum will need something > more dynamic. > - I enabled the shared filesystem (VIRTIO_FS), which works nicely. I > use it to provide a (separate) shared directory to each VM that I can > access from the host. > One problem is that the crosvm driver runs in a minijail with a > uidmap that makes every file appear to be owned by root, so only root > can write things in the VM. > Possibly a newer kernel would help; later versions of the kernel > docs say you can include any normal FUSE flags here, so mounting with > `uid=3D1000` might work. I've only looked into virtio-fs a little bit -- I remember having to make a change to crosvm to make the sandboxing work. Glad to hear it's working well. I'll find out if a later kernel works when I get to updating Nixpkgs (or somebody else does -- someone on IRC was actually offering to try doing this the other day). > - Finally, I added a `vm-halt` command that just calls `reboot`, as I > don't want to develop the habit of typing `reboot` without thinking > ;-) I don't want to think about how many times I've made this mistake, lol. > If any of this sounds useful for spectrum let me know. I can try and > tidy it up; it's all a huge mess at the moment! I think it might well be -- the stuff you have going on with networking and filesystems sound great, in particular -- but I'll have to have gotten a bit more back into the project again to know exactly what. Right now I'm focusing on slowly bringing myself back up to speed and remembering what state things are in. > Once this is working more smoothly, I guess the next issues will be > setting up some kind of secure window manager on the host (e.g. > labelling windows with the VM they come from, not allowing > screenshots, etc). Would also be good to get sound forwarding working > somehow (Qubes routes pulseaudio to all the VMs and gives you a mixer > to control the levels for each, but I don't know how that worked). It > also needs some kind of VM manager to keep track of which VMs are > running. And some kind of IPC system like qrexec would be useful. Do > you have thoughts or plans about how to do any of this? The window manager is a part of this whole thing that makes me very nervous. A secure window manager is very important for Wayland, and I'm not sure how much I trust any of the existing ones to get it right. But with Wayfire I'm hoping it'll at least be easy enough to implement stuff like tagged/coloured windows for the proof of concept (since the plugin API and stuff is Wayfire's niche), and I'm hoping at some point somebody comes up with a security-focused Wayland window manager we can switch to -- I'd love a Rust one, and there's work going on in that area[1]. Not sure about IPC yet, but I recently read an article about PipeWire[2], and that's been making me think a bit about audio. With PipeWire, they seem to have cared about security from the start: > To avoid the PulseAudio sandboxing limitations, security was > baked-in: a per-client permissions bitfield is attached to every > PipeWire node =E2=80=94 where one or more SPA nodes are wrapped. This > security-aware design allowed easy and safe integration with Flatpak > portals; the sandboxed-application permissions interface now promoted > to a freedesktop XDG standard. And it gets better! In particular, this sounds very promising: > a native fully asynchronous protocol that was inspired by Wayland =E2=80= =94 > without the XML serialization part =E2=80=94 was implemented over Unix-do= main > sockets. Taymans wanted a protocol that is simple and hard-realtime > safe. It goes on to say they use this for sending file descriptors and stuff. The similarity to Wayland is very exciting, because it means we might just be able to run PipeWire over the existing virtio_wl infrastructure very efficiently. It'll be a while before I get to look at audio in depth, but this all sounds very good -- maybe most of the work will have been done for us! In general I'm feeling very optimistic about a lot of the stuff going on in the ecosystem to try to make Flatpak and co secure -- I don't trust Flatpak itself to provide meaningful security, but it means we're getting standard mechanisms for permissions for standard applications (xdg-desktop-portal is another that comes to mind), and if this goes well it means that all we have to do is provide implementations of those standard interfaces that cross VM boundaries, and applications designed to work in Flatpak etc. should already understand how to interact with them. [1]: https://smithay.github.io/pages/about.html [2]: https://lwn.net/SubscriberLink/847412/f5595d3e8875ce5d/ --tx6sy2cymigsxqin Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmBHoZIACgkQ+dvtSFmy ccCtdxAAjw8I7iu3Qe8PRCyTQOEEmCkg5BG6gVgt/fv4ZvDKzb/GEahhdcziLNKO 0KUsUmIPwSEplUy0vuP51VH2MKgWjzTrcAkAPc+qPZEKHA1n/aQTefPOykQqCHAk GvhRjJFy3jUADeA4HHmHrs1V7tTYuiXWj5Gc5yMHlpblJGXjFNH5tpmd0kQYqWcn 2LIng8SejqX1QtImRJyVarbUAwRnhUdbTw+kSO+wM3voJFDeq7bXb9Uw0/2uctAv EK0A778kUcJdhevlaT7j7fR5iuOXctL0WlXGwrfCkwHGy96fN9ehfPNz5YqYYeoz a/HPMtAP1+P/7czktNKtrqJUHFWAT7OZO9IxeZY5JzwGRKwBSdayd1t30CN7fYxl 2IVkBgiZhR7bjgSmuXDdbBGVbgqhBpfmxJuLN5t2qfIyxaaMasNQSaNk4t6Ox7jE kFRNSx79dg7e29OXuhVaeMYoN7dUYC7w399T2FyEeHfAV/zO50w1b8fFfeW2fsw+ BDd90Y1szp2yTNXz288aUf60Idh0BjrKHa6TRHNDV5ZGODlJYgEwc7DhZXmTEkei oXl73vUluN0gtzxgVzynzhyBmGHHaKtCHql99ES8d+u042GGb5HM30/yzaRGWoQl mAf+g5hsat2nhI/gaDHA1N+xJ7nx323VsPOg0CqLS3qDBWh721Y= =ddqY -----END PGP SIGNATURE----- --tx6sy2cymigsxqin--