From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 2190351A8F; Tue, 6 Dec 2022 13:57:06 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id CD99251A89; Tue, 6 Dec 2022 13:57:03 +0000 (UTC) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by atuin.qyliss.net (Postfix) with ESMTPS id 1767351A87 for ; Tue, 6 Dec 2022 13:57:00 +0000 (UTC) Received: by mail-lf1-x12c.google.com with SMTP id g7so23797455lfv.5 for ; Tue, 06 Dec 2022 05:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XO7Y7LGNAtA+0/qahAreovmOUw1yKVkcFcZR2oxwfMM=; b=JbtAj8gqGAbCiB4QqpuNGCM0iZbRVDHvusBF8qKGdgTGMA+f4LdvYzgWlZYbFqde7u NhuZ9e3osk24sB84Z3lrYXNwCczbSXmfiboV87weXa3FuDaXRN8gRhlumjMl0cxKHU28 zq6Ib7QFNe+aRx9PK8MiMj+rxiZymU1yJq9M8j5FxV8vpBEhUU+xZrGjx5/AIO50+Ihe aTq9msZTL/Lj6jkDxK1HdJg7bt2e3JWmaMjy6kX6+KwOQtj/NhgTkVHRkHNreBXnkvek s8zYPavXVEawx+qTG8ov15CcZLLdb5VgTffixQBDehaJz6HCRXSvd8mAsnJLVSrvsG0W CywA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XO7Y7LGNAtA+0/qahAreovmOUw1yKVkcFcZR2oxwfMM=; b=uMhgykWSgUiwwAW15VyJ6qJITvFgzWaNnS2sjtwX7M30u4L3MrEwEezQw6Hg58wAbe OsgrBNmDoxakBj7g+2ac0wugr8Cl7SjCJCdooPC4gXlbQ2fYc2hoh0sDiOkSTYqPP3u5 pcrKYU6Ks9Xpy/X+GY+vUMUT2E0T6D4qqGP0srkGTXvS3KwKfyjpGiuQp3CaDU98BfRv PnLt/mjgJQzHw6kSzBHO21ZdrflN4kmgx1aiWb5LhLC00oq8Vfkad6+reDg9ucv3ixdq 3+5TQ2DdZF0YYJ4OAbGCOspXOVybEOeOKCpVzE1XSzgzbbNdeI7NN+mD2tkoIXajkcL8 N4VQ== X-Gm-Message-State: ANoB5pmuuGz0h3hEhYDPgU1+lPnZ0P1qy30s1XCWky74cqn6z1CRkBoN iWyFeVzJ1OGTeR70gD9fg0lgew== X-Google-Smtp-Source: AA0mqf46TKQE8NTPTN4eQRRMagTBAC+Fl201SZyV5YJQJ3oiKsro0COIdgECMHJiNaAUm8OcXh4p2Q== X-Received: by 2002:a05:6512:151e:b0:4af:1cbe:1ad8 with SMTP id bq30-20020a056512151e00b004af1cbe1ad8mr22396209lfb.16.1670335013508; Tue, 06 Dec 2022 05:56:53 -0800 (PST) Received: from smtpclient.apple (88-114-171-198.elisa-laajakaista.fi. [88.114.171.198]) by smtp.gmail.com with ESMTPSA id l16-20020ac24310000000b00498f871f33fsm2490311lfh.86.2022.12.06.05.56.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2022 05:56:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: Firefox appVM patches and appVM refactoring From: Vadim Likholetov In-Reply-To: <20221206114239.ifel7s6ctmhzymbc@x220> Date: Tue, 6 Dec 2022 15:56:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20221206114239.ifel7s6ctmhzymbc@x220> To: Alyssa Ross X-Mailer: Apple Mail (2.3731.200.110.1.12) Message-ID-Hash: ZVGEGGXF77RE2UKLKQF4AVHK66DGONQZ X-Message-ID-Hash: ZVGEGGXF77RE2UKLKQF4AVHK66DGONQZ X-MailFrom: vadim.likholetov@unikie.com X-Mailman-Rule-Hits: header-match-devel.spectrum-os.org-0 X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1 CC: devel@spectrum-os.org X-Mailman-Version: 3.3.5 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > On 6 Dec 2022, at 13:42, Alyssa Ross wrote: >=20 > On Mon, Dec 05, 2022 at 12:42:35AM +0200, Vadim Likholetov wrote: >> I've made an Firefox appVM for wayland using my waypipe patches. >> To make this appVM I have had to refactor Spectrum OS appvm = infrastructure. >> The main idea of refactoring is enabling appvm to have a user with = normal >> priviledges, not superuser. >> Running everything from root is not the best idea for secure OS :-) >=20 > In this case, the application running as root is the only thing = running > in the VM, so it doesn't _really_ matter, but it is still a good idea = to > fix, as some applications will refuse to run as root. I don=E2=80=99t agree there =E2=80=94 there are many reasons application = should not have unnecessary privileges, even assuming the case where = someone attacks the application using kernel/processor vulnerabilities = to get out of the virtualisation fencing is more fantastic than real :) Also in it is never =E2=80=9Cthe only" application in the VM =E2=80=94 = we always have those binutils, init stuff and other supplemental = software =E2=80=94 except the situation we=E2=80=99re running something = like bare kernel. So if we have really talking about *secure* OS =E2=80=94 drop the = gun priviledges ! :-) > (cloud-hypervisor also runs on the /host/ as root, and that's = something > that we'll definitely want to fix, but that's more complicated as just > statically assigning c-h processes to uids won't work when we want to > dynamically create and destroy VMs. We'll likely want something akin = to > systemd's DynamicUser=3D.) We can ran C-H as non-root on the host =E2=80=94 I don=E2=80=99t see any = huge problems there, it=E2=80=99s designed not to be run as root.=20 But the idea to assign an unique UID to each VM is secure enough :-) >=20 >> So now the .nix file for appvm has two sections, one that is executed = as >> root and one as user. >> Here is the sample of this definitions: >>=20 >> { config ? import ../../../nix/eval-config.nix {} }: >>=20 >> import ../make-vm.nix { inherit config; } { >> providers.net =3D [ "netvm" ]; >>=20 >> run =3D config.pkgs.pkgsStatic.callPackage ( >> { writeScript }: >> writeScript "run-root-shell" '' >> #!/bin/execlineb -P >> /bin/sh >> '' >> ) { }; >>=20 >> run-as-user =3D config.pkgs.pkgsStatic.callPackage ( >> { writeScript, lynx }: >> writeScript "run-lynx" '' >> #!/bin/execlineb -P >> ${lynx}/bin/lynx = https://www.google.com/url?q=3Dhttps://spectrum-os.org&source=3Dgmail-imap= &ust=3D1670931764000000&usg=3DAOvVaw3fPCahT573bNMQKMWAGTEW >> '' >> ) { }; >>=20 >> } >=20 > I'm not too sure about this part =E2=80=94 it seems like quite a lot = of > complexity in the app VM implementation, when dropping privileges > (unless there's something I haven't considered?) should be as simple = as > putting "s6-applyuidgid -u 1000 -g 1000" in the VM run script at the > point where privileges can be dropped. I think it=E2=80=99s more flexibility rather than complexity.=20 Also because of immature nature of the Spectrum OS it is good to have = some extra tools for developers to debug the stuff and to have extra = controls. I can think of refactoring this on the /img/vm level =E2=80=94 = I=E2=80=99m using su and not s6-tools, if you=E2=80=99re interested in = this patchset in general. >=20 >> Cloud-hypervisor has virtual hardware limitations -- it supports only = one >> console device and only one serial device. >> SpectrumOS is using serial device for kernel logs of appVM and = console >> device as a console. >> To have access both to root-executed part and to user-executed part = of the >> VM payload, I installed a tmux on console. >> Now, when you're running vm-console command you get access to the = tmux >> and have the ability to switch between root and user consoles, >> that can be useful during debugging VM payload. >>=20 >> To run Firefox appVM use vm-start-way command: vm-start-way = appvm-firefox :) >=20 > Would it work with virtio-gpu? I'm still not convinced on Waypipe =E2=80= =94 > where the previous discussion left off, we were talking about VMs over > the network. That would be an interesting thing to look at (and it > would be really cool if we could make it work!), but doing it would = take > a lot more than just network-transparent Wayland proxying, so if = that's > the main thing we'd get out of Waypipe, I think it would only make = sense > to add Waypipe support as part of that bigger work. (And this point = in > time, when how VMs work at all in Spectrum is a bit in flux, is = probably > not the best time to start trying to massively expand their scope!) I think it=E2=80=99s the wrong question :-) Both implementations of wayland passthru ( virtio-gpu and waypipe) are = ugly right now but they both allow to move the development forward. But = someday I believe they=E2=80=99ll become nice. I really believe! :-) The thing is definitely needed in the mainline is abstraction layer for = wayland apps =E2=80=94 to move all proxying and other system or hardware = dependant details out of VM=E2=80=99s descriptions =E2=80=94 we define = that is an wayland appVM ( like it=E2=80=99s defined it=E2=80=99s = networking appVM) and the mechanisms of how the WAYLAND_DISPLAY gets to = the is covered by this abstraction layer. >> i beleive that as soon as spectrumOS features will cover basic user = needs >> it's popularity and community will grow and this will make positive = impact >> on SpectrumOS itself. >> Using appvm-firefox prototype you may build another wayland-enabled = appVMs. >=20 > Yeah, having a Firefox example VM would be really great for > demonstrating how Spectrum works and what it can do, and I'm pleased > that we're even getting to a point where it would work! Firefox is a > big application that does a lot of stuff, so it would also be useful = for > testing all sorts of other features, like audio or XDG desktop = portals. > I'd be very happy to accept a Firefox VM that used virtio-gpu. :)