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=-2.0 required=3.0 tests=BAYES_00,DATE_IN_PAST_03_06, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.4 Received: by atuin.qyliss.net (Postfix, from userid 496) id 95FCC17F65; Sat, 13 Mar 2021 12:52:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 261D117F2A; Sat, 13 Mar 2021 12:52:35 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 4EA8B17FAC; Sat, 13 Mar 2021 12:52:32 +0000 (UTC) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by atuin.qyliss.net (Postfix) with ESMTPS id 42DFF17F24 for ; Sat, 13 Mar 2021 12:52:29 +0000 (UTC) Received: by mail-ua1-f54.google.com with SMTP id o8so2695129uar.3 for ; Sat, 13 Mar 2021 04:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FFmIphTj5PsNeG5zk0AD6vTvAHhVmahAM6mIjNhHOjk=; b=qHEYOXkR97Bdj3f/d7V4K3Z/KTwhg4o67hVyiw/fM3usPBUD/5t3ZnnyW17mYjl9r4 xpv57NiYBxFN9dk2LorPMOXH2babUpen7sOyRPGNCmI8wzei592JUZ9P1R46B1qNUhZk yEpeEzFKy79LpNiph9fDPCnd/fxEnv8D5RDFHDiK+DBYBIDM/NhfzzZsVgrnRLkFZVtO Uz7alqwNTK0rx97zM9fujM6bVNQ4JUgGEUbQ40pX2OoBti+B7+4+MwdGCQHBhV19D+QK B9o5ZkjbwpfMjbq+LoR6kBmKK3gj+JwFrjlgPNOD+GoqQ/0vecdTsww+rbDk4rloIOCp Onmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FFmIphTj5PsNeG5zk0AD6vTvAHhVmahAM6mIjNhHOjk=; b=EubXjNlWvR3mP37O6wxr6pgja1EjMf0CSebanBnbS0v9fQSq8YbFn9wxJikXUt8XRG unmdOIRsiCnkRmpMaw4yE0RVCqwk2HmVq5p+AelBJzSpx8Ll2O057fYubUwOm7S96KG3 UCyT5SSxAaFtW+wB9sQZZYOZbWRjXsXdf/39xLMVcnZQPFgCqPXtupp4oUvUnI6KM0m3 cnvKxRmNnVejOBKi+ywwZ6s/8Cz2yxQxhavMgoXjNykdhIRmZjWWiP6vtQgoEGxAFQ9h npmCaE90jzSO1t9tbL8quaupnLbvVW9JIeGdAFEV3jKH4ojJr0r0R5VTm5HJN0N6b1KK HOPw== X-Gm-Message-State: AOAM532BzUKNBLm9fjCs2T20eEid/dVAoV+hidaOuBPivXsAnk0pmUq8 w2qPqypRT/v6/ay+QFjUtf63jahZ7weJDXlx0L8= X-Google-Smtp-Source: ABdhPJxFMXPU9TNw69jDj9pno+A7a+oTJ6RTwOYcI0d89xqjGuBJVprq93J1046NXCYw8iZb4YDfuIqnOc7nWtSVVyA= X-Received: by 2002:ab0:49ce:: with SMTP id f14mr1123865uad.69.1615639947791; Sat, 13 Mar 2021 04:52:27 -0800 (PST) MIME-Version: 1.0 References: <87ble2czx6.fsf@alyssa.is> <87lfcvn1ln.fsf@alyssa.is> <87bldrn0kh.fsf@alyssa.is> <20210309162556.ctiy3yfp7plkbdqs@x220.qyliss.net> In-Reply-To: <20210309162556.ctiy3yfp7plkbdqs@x220.qyliss.net> From: Thomas Leonard Date: Sat, 13 Mar 2021 07:21:50 +0000 Message-ID: Subject: Re: New user getting started questions To: Alyssa Ross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: O6JDAYOR4NJE23GFNUW6IS6RWQKL4FNA X-Message-ID-Hash: O6JDAYOR4NJE23GFNUW6IS6RWQKL4FNA X-MailFrom: talex5@gmail.com 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: On Tue, 9 Mar 2021 at 16:26, Alyssa Ross wrote: > > 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: [...] > > 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]. For the short-term, it would be fairly easy to make a slight change to the wayland-virtwl-proxy[*] so that a version of it could run on the host. Unlike the guest one, which has to copy frames and deal with virtwl, this would just pass FDs through. And instead of connecting to /dev/wl0, it would just connect to the host compositor socket. It would then block access to screenshots (since it doesn't proxy that), and would add the VM's name to each window's title. Eventually I'd like to turn it into a full compositor, but I'm going to be busy for the next 6 months at least. > 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: Thanks for the link. I hadn't realised PulseAudio was in such a bad state! > > 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-= domain > > 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. Yes. I wonder why they didn't just use Wayland directly. Removing the XML schema files (I assume that's what they mean) doesn't seem like an improvement. That's what makes it easy to use Wayland from safer languages than C! [*] https://github.com/talex5/wayland-virtwl-proxy --=20 talex5 (GitHub/Twitter) http://roscidus.com/blog/ GPG: 5DD5 8D70 899C 454A 966D 6A51 7513 3C8F 94F6 E0CC