moonpiedumplings

sandboxing is not the best practice on Linux… So I’m better off with Qubes than with Secureblue

No, no, no.

It's no that sandboxing is the best practice, it's just that attempting to "stack" linux sandboxes is mostly ineffective. If I run kvm inside xen, I get more security. If I run a linux container inside a linux container, I only get the benefit of one layer. But linux sandboxes are good practice.

I do agree that secureblue sucks, but I don't understand your focus on Qubes. To elaborate on my criticisms let me explain, with a reply to this comment:

Many CVE’s for Xen were discovered and patched by the Qubes folks, so that’s a good thing…

If really, really care about security, it's not enough to "find and patch CVE's". The architecture of the software must be organized in such a way that certain classes of vulnerabilities are impossible — so no CVE's exist in the first place. Having a lack of separation between different privilege levels turns a normal bug into a critical security issue.

Xen having so many CVE's shows that is has some clear architectural flaws, and that despite technically being a "microkernel", the isolation between the components is not enough to prevent privilege isolation flaws.

Gvisor having very few CVE's over it's lifespan shows it has a better architecture. Same for OpenBSD — despite having a "monolithic" kernel, I would trust openbsd more in many cases (will elaborate later).

Now, let's talk about threat model. Personally, I don't really understand your fears in this thread. You visited a site, got literally jumpscared (not even phised), and are now looking at qubes? No actual exploit was done.

You need to understand that the sandboxing that browsers use is one of the most advanced in existence currently. Browser escapes are mostly impossible... mostly.

In addition, you need to know that excluding openbsd, gvisor, and a few other projects almost all other projects will have a regular outpouring of CVE's at varying rates, depending on how well they are architectured.

Xen is one of those projects. Linux is one of those projects. Your browser is one of those projects. Although I consider Linux a tier below in security, I consider Xen and browsers to exist at a similar tier of security.

What I'm trying to say, is that any organization/entity that is keeping a browser sandbox escape, will most definitely have a Linux privilege escalation vulnerability, and will probably also have a Xen escape and escalation vulnerability.

The qube with the browser might get compromised, but dom0 would stay safely offline, that’s my ideal, not the utopic notion of never possibly getting attacked and hacked.

This is just false. Anybody who is able to do the very difficult task of compromising you through the browser will probably also be able to punch through Xen.

not the utopic notion of never possibly getting attacked and hacked.

This is true actually. Browser exploits are worth millions or even tens of millions of dollars. And they can only really be used a few times before someone catches them and reports them so that they are patched.

Why would someone spend tens of millions of dollars to compromise you? Do you have information worth millions of dollars on your computer? It's not a "utopic notion", it's being realistic.

If you want maximum browser security, ~_{disable javascript}~ use chromium on openbsd. Chromium has slightly stronger sandboxing than firefox, although chromium mostly outputs CVE's at the same rate as firefox. Where it really shines, is when combined with Openbsd's sandboxing (or grapheneos' for phones).

Sure, you can run Xen under that setup. But there will be no benefit, you already have a stronger layer in front of Xen.

TLDR: Your entire security setup is only actually as strong as your strongest layer/shield. Adding more layers doesn't really offer a benefit. But trying to add stronger layers is a waste of your time because you aren't a target.

Proxmox is based on debian and uses debian under the hood...

This post is a pretty good overview of why oauth2/openid are more popular.

Not to say that oauth/openid have never ever had vulnerabilities of their own, but there is a big difference between "accept these configurations" and what saml is, which is "parse this xml".

to answer your first question, kind of. Gvisor (by google btw) uses the linux kernels sandboxing to sandbox the gvisor process itself.

Distrobox also uses the linux kernels sandboxing, which is how linux based containers work.

Due to issues with the attack surface of the linux's kernels sandboxing components, the ability to create sandboxing or containers inside sandboxes or containers is usually restricted.

What this means is that to use gvisor inside docker/podman (distrobox) you must either loosen the (kinda nonexistent) distrobox sandbox, or you must disable gvisors sandboxing that it applies to itself. You lose the benefit, and you would be better off just using gvisor alone.

It's complicated, but basically the linux's kernels containers/sandboxing features can't really be "stacked".

I remember I fit binding of isaac and an archlinux install into 10 gigs of storage using btrfs transparent compression.

The computer was a craptop with only 32 gigs of flash storage overall.

Care to elaborate? Proxmox's paid tier is long term support for their older releaes, and paid support. The main code is entirely free, with no features gated behind paywalls or anything like that.

Check out turbowarp, an ultra fast reimplementation of scratch.

I've seen games that only worked in turbowarp.

Custom editors are probably needed.

Kde's spectacle (screenshot utility) does this by default now.

I don't see any mention of games so far.

A minecraft server is always a good time with friends, and there are hundreds of other game servers you can self host.

Syd3, and gvisor, a similar project in go aren't really sandboxes but instead user mode emulation of the linux kernel. I consider them more secure than virtual machines because code that programs run is not directly executed on your cpu.

Although syd3 doesn't seem to emulate every syscall, only some, I know rhat gvisor does emulate every syscall.

If you compare CVE's for gvisor and CVE's for xen/kvm, you'll see that they are worlds apart.

Xen has 25 pages: https://app.opencve.io/cve/?vendor=xen

Gvisor has 1: https://app.opencve.io/cve/?q=gvisor

Now, gvisor is a much newer product, but it is still a full 7 years old compared to xen's 22 years of history. For something that is a third of the age, it has 1/25th of the cve's.

There is a very real argument to be made that the hardened openbsd kernel, when combined with openbsd's sandboxing, is more secure than xen, which you brought up.

I don't know what the commenter you replied to is talking about, but systemd has it's own firewalling and sandboxing capabilities. They probably mean that they don't use docker for deployment of services at all.

Here is a blogpost about systemd's firewall capabilities: https://www.ctrl.blog/entry/systemd-application-firewall.html

Here is a blogpost about systemd's sandboxing: https://www.redhat.com/en/blog/mastering-systemd

Here is the archwiki's docs about drop in units: https://wiki.archlinux.org/title/Systemd#Drop-in_files

I can understand why someone would like this, but this seems like a lot to learn and configure, whereas podman/docker deny most capabilities and network permissions by default.

Is your flux config public?

99.9999% of freecell games are winnable. Very nice, and one of the reasons I preferred freecell.

https://opensource.google/documentation/reference/using/agpl-policy/

WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

https://alfredvalley.itch.io/diedream

Designed to be played before falling asleep,

I like to play chess in my head.

Re: lag.

LACP doesn't even work between wifi and ethernet, doesn't it? I thought it required configurations on the network switch, which implies ethernet.

The bug they mention seems to only apply to the LACP mode of link aggregation, when they should probably be trying to use failover from this page. Where what you do is set the ethernet as the primary and the wifi as the failover (although this doesn't seem to work on their case because the ethernet interface is dynamically created.

Other complaints and issues they have still apply as well.

I understand the technical challenges with running x86 apps on arm... but multiple wrappers that do something similar to proton have already been released.

If you follow the r/emulationonandroid subreddit, they have gotten PC games working on android for a while now. One of the wrappers, gamehub, has made it to the playstore. You can just sign in to your steam account (don't do that gamehub is sketchy af, proprietary, and by a company that stole gpl code fro, yuzu and didn't release a derivative product), download games, and play them.

The current concern is performance, but most lower and midrange games run just fine.

Corporations really, really love being admin on everybody elses devices. See kernel level anticheat.
I feel like people have gotten zero trust (I don't need to trust anybody) confused with "I don't trust anybody".
I was listening to a podcast by packet pushers and they were like "So you meet a vendor, and they are like, 'So what do you think zero trust means? We can work with that'".

Yes, you have noticed that HA with GPU's is very, very difficult. My understanding is that most people have given up, where they use something like kubernetes and just kill and restart the application on another machine, instead of truly failing over a virtual machine/container.

Now, you've stated that you can't afford enterprise grade gpu's. That's okay. You should know that there exist projects to unlock vgpu features on non-enterprise/server grade nvidia gpus.

this is the main one: https://github.com/DualCoder/vgpu_unlock — but it only supports 2080 nvidia gpus and below. It looks like there is some work on getting 30/40 series nvidia gpus working, but I cannot find a public guide. It should be noted that only the 30/40 series has tensor cores!

Now, even if you cannot get vgpu working, you should also know that although you cannot share a virtual machine between virtual machines, you can can share a gpu between LXC containers, which proxmox supports management of.

all of my VM’s are built as if they can freely migrate

I also want to clarify something about the way HA in proxmox works. Live migration only works when the relevant proxmox hosts are online. Failover, which is a form of high availability, happens when a host goes offline, and the new virtual machine reboots from the shared storage in use.

My honest recommendation is to give up on HA for this. Going for minimal cost, I would buy one cheaper GPU (intel arc's offer best bang for buck right now iirc) which is dedicated to VDI and jellyfin hardware decoding (but this only works if your VDI and jellyfin are in LXC containers... since there is also no vgpu), and buy one more expensive nvidia gpu with tensor cores for machine learning and AI workflows.