Créer un compteSe connecter

Recherches récentes

Aucune recherche récente

Options de recherche

Disponible uniquement lorsque vous êtes connecté.
mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

641
comptes actifs

mastouille.fr: À proposAnnuaire des profilsPolitique de confidentialité

Mastodon: À proposTélécharger l’applicationRaccourcis clavierVoir le code sourcev4.3.4

#kvm

0 message0 participant0 message aujourd’hui
Public *
Jan Wildeboer 😷:krulorange:

On modern #Linux, a virtual machine using #KVM is more or less just another running process. Which allows you to treat a VM more or less as a container. Which is why we at Red Hat offer Openshift Virtualisation, that puts all of that together. This was kinda mind-blowing for some at the event where I presented yesterday. Seeing VMs as "fat" containers that you can now start planning to convert to real containers :) 1/4

Public *
Aho

Switched from #lookingglass 2:B6-10 to 2:B7-1 and it was nice that you didn't have to click on the window to get control of the host mouse, you got full control of the mouse pointer as soon as you mouse went over to the looking-glass window.

Just wish the RTX2060 would be more stable in the guest OS, sometimes it just crash while using heavy graphics programs like PhotoShop (yeah, I do know #Gimp but not all people want to use it and those this VM).

#kvm#qemu
Public
futurile

For #guix social I'm going to do a talk for #beginners on trying #guix as a #linux distribution. Basically, how to install Guix System, and getting started.

I'm going to do it in a #kvm #vm as that's an easy way to try the #nix derived #declarative goodness without fully committing.

What do you think the key things are to cover? Any particular sticky areas? Anything that was super interesting when you were getting started? What do #beginners need to know?

Public
Pope Bob the Unsane

After taking the nickle tour of #Qubes, my hasty conclusion is that it is anti-#KISS; there are seemingly many moving parts under the surface, and many scripts to grok to comprehend what is going on.

I plan to give it some more time, if only to unwrap how it launches programs in a VM and shares them with dom0's X server and audio and all that; perhaps it's easier than I think.

I also think #Xen is a bit overkill, as the claim is that it has a smaller kernel and therefore smaller attack surface than the seemingly superior alternative, #KVM. Doing some rudimentary searching out of identified / known VM escapes, there seem to be many more that impact Xen than KVM, in the first place.

Sure, the #Linux kernel may be considerably larger than the Xen kernel, but it does not need to be (a lot can be trimmed from the Linux kernel if you want a more secure hypervisor), and the Linux kernel is arguably more heavily audited than the Xen kernel.

My primary concern is compartmentalization of 'the web', which is the single greatest threat to my system's security, and while #firejail is a great soltion, I have run into issues maintaining my qutebrowser.local and firefox.local files tuned to work well, and it's not the simplest of solutions.

Qubes offers great solutions to the compartmentalization of data and so on, and for that, I really like it, but I think it's over-kill, even for people that desire and benefit from its potential security model, given what the threats are against modern workstations, regardless of threat actor -- most people (I HOPE) don't have numerous vulnerable services listening on random ports waiting to be compromised by a remote threat.

So I am working to refine my own security model, with the lessons I'm learning from Qubes.

Up to this point, my way of using a system is a bit different than most. I have 2 non-root users, neither has sudo access, so I do the criminal thing and use root directly in a virtual terminal.

One user is my admin user that has ssh keys to various other systems, and on those systems, that user has sudo access. My normal user has access to some hosts, but not all, and has no elevated privileges at all.

Both users occasionally need to use the web. When I first learned about javascript, years and years ago, it was a very benevolent tool. It could alter the web page a bit, and make popups and other "useful" things.

At some point, #javascript became a beast, a monster, something that was capable of scooping up your password database, your ssh keys, and probe your local networks with port scans.

In the name of convenience.

As a result, we have to take browser security more seriously, if we want to avoid compromise.

The path I'm exploring at the moment is to run a VM or two as a normal user, using KVM, and then using SSH X forwarding to run firefox from the VM which I can more easily firewall, and ensures if someone escapes my browser or abuses JS in a new and unique way, that no credentials are accessible, unless they are also capable of breaking out of the VM.

What else might I want to consider? I 'like' the concept of dom0 having zero network access, but I don't really see the threat actor that is stopping. Sure, if someone breaks from my VM, they can then call out to the internet, get a reverse shell, download some payloads or build tools, etc.

But if someone breaks out of a Qubes VM, they can basically do the same thing, right? Because they theoretically 'own' the hypervisor, and can restore network access to dom0 trivially, or otherwise get data onto it. Or am I mistaken?

Also, what would the #LXC / #LXD approach look like for something like this? What's its security record like, and would it provide an equivalent challenge to someone breaking out of a web browser (or other program I might use but am not thinking of at the moment)?

Public
Eva Winterschön

💻 HomeLab Chanukah 💻

Ok not really, but every HomeLab hardware weekend feels like a wonderful gift! 🎁

Today I'll be setting up a new 25U rack, and then mostly recuperating. I'm also working on the FreeBSD port of this OSS KVM: crowdsupply.com/techxartisan/o .. couple of Qt6 bugs with serial usb handling but otherwise can get video just fine. It arrived yesterday, so of course the first thing to do is de-pack the Debian package and start reviewing repo source. Love it.

Disregard the boxes and living room clutter in these photos, we're still unpacking from the move.

25U white rack, from Navepoint, from the front. Juniper switch and APC are presently mounted.
25U white rack, from Navepoint, from the side. Juniper switch and APC are presently mounted. Sears Tower in the background.
#homelab#linux#freebsd
Public
futurile

#Guix survey found that 70% of users deploy it as a graphical #desktop #linux

Be interesting to consider packaging and testing priorities at #guixdays given this figure

About a third are #server deployments, on hardware, but also #vm #kvm - interesting!

The ability to use #guix for #docker or #singularity deployments and #CI were all mentioned. Maybe potential for further development?

#Using #guix in #cloud or #containers with #orchestration (e.g. #k8s ) doesn't seem widespread yet.

Screenshot of a table from the blog post. Table shows different deployment types that the user and contributor (2024) survey found - including that 70% of users deploy Guix as a graphical desktop on laptop/workstation hardware.
Public
Bardia

someone in the chat asked if the flx1 can run a KVM machine and my initial thought process was well, probably not out of the box since during the boot process EL2 is locked and even if kernel has KVM, it will never initialize correctly.

so today after finishing my daily tasks i decided to take a stab at our bootloader, preloader and trustzone's source code.

Lo and behold, turns out i did indeed cook.

Docker support will land in the next release too!

An ubuntu 24.04 ARM64 VM running under KVM on the FLX1
Phosh app drawer with settings, CPU-Z running inside an Android container and QEMU KVM
#flx1#furilabs#FuriPhoneFLX1
ExplorerFlux en direct
À propos