From: Vadim Likholetov <vadim.likholetov@unikie.com>
To: Alyssa Ross <alyssa.ross@unikie.com>
Cc: devel@spectrum-os.org
Subject: Re: Firefox appVM patches and appVM refactoring
Date: Tue, 6 Dec 2022 15:56:42 +0200 [thread overview]
Message-ID: <E390FF8D-A33F-4FC6-AE09-6275CE328EF2@unikie.com> (raw)
In-Reply-To: <20221206114239.ifel7s6ctmhzymbc@x220>
> On 6 Dec 2022, at 13:42, Alyssa Ross <alyssa.ross@unikie.com> wrote:
>
> 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 :-)
>
> 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’t agree there — 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 “the only" application in the VM — we always have those binutils, init stuff and other supplemental software — except the situation we’re running something like bare kernel.
So if we have really talking about *secure* OS — drop the <s>gun</s> 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=.)
We can ran C-H as non-root on the host — I don’t see any huge problems there, it’s designed not to be run as root.
But the idea to assign an unique UID to each VM is secure enough :-)
>
>> 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:
>>
>> { config ? import ../../../nix/eval-config.nix {} }:
>>
>> import ../make-vm.nix { inherit config; } {
>> providers.net = [ "netvm" ];
>>
>> run = config.pkgs.pkgsStatic.callPackage (
>> { writeScript }:
>> writeScript "run-root-shell" ''
>> #!/bin/execlineb -P
>> /bin/sh
>> ''
>> ) { };
>>
>> run-as-user = config.pkgs.pkgsStatic.callPackage (
>> { writeScript, lynx }:
>> writeScript "run-lynx" ''
>> #!/bin/execlineb -P
>> ${lynx}/bin/lynx https://www.google.com/url?q=https://spectrum-os.org&source=gmail-imap&ust=1670931764000000&usg=AOvVaw3fPCahT573bNMQKMWAGTEW
>> ''
>> ) { };
>>
>> }
>
> I'm not too sure about this part — 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’s more flexibility rather than complexity.
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 — I’m using su and not s6-tools, if you’re interested in this patchset in general.
>
>> 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.
>>
>> To run Firefox appVM use vm-start-way command: vm-start-way appvm-firefox :)
>
> Would it work with virtio-gpu? I'm still not convinced on Waypipe —
> 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’s 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’ll become nice. I really believe! :-)
The thing is definitely needed in the mainline is abstraction layer for wayland apps — to move all proxying and other system or hardware dependant details out of VM’s descriptions — we define that is an wayland appVM ( like it’s defined it’s 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.
>
> 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. :)
next prev parent reply other threads:[~2022-12-06 13:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-04 22:42 Vadim Likholetov
2022-12-06 11:42 ` Alyssa Ross
2022-12-06 13:56 ` Vadim Likholetov [this message]
2022-12-06 15:18 ` Alyssa Ross
2022-12-06 15:20 ` Alyssa Ross
2022-12-06 15:57 ` Vadim Likholetov
2022-12-06 17:10 ` Alyssa Ross
2022-12-06 20:12 ` Vadim Likholetov
2022-12-06 20:25 ` Alyssa Ross
2022-12-07 7:41 ` vadik likholetov
2022-12-06 20:19 ` Vadim Likholetov
2022-12-06 20:31 ` Developer-friendliness Alyssa Ross
2022-12-07 7:46 ` Developer-friendliness vadik likholetov
2022-12-06 20:59 ` Developer-friendliness Michael Raskin
2022-12-06 21:14 ` Developer-friendliness Alyssa Ross
2022-12-06 22:05 ` Developer-friendliness Michael Raskin
2022-12-07 8:04 ` Firefox appVM patches and appVM refactoring Ville Ilvonen
2022-12-07 11:09 ` vadik likholetov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E390FF8D-A33F-4FC6-AE09-6275CE328EF2@unikie.com \
--to=vadim.likholetov@unikie.com \
--cc=alyssa.ross@unikie.com \
--cc=devel@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).