• 6 Posts
  • 94 Comments
Joined 2 years ago
cake
Cake day: August 10th, 2023

help-circle
  • 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.


  • 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”.





  • 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.







  • In my opinion, you are starting too big. It’s better to start smaller. Many locations have a “Linux User Group” or “hackerspace” or a “Computing Club”. (Those are exact keywords you can try searching for).

    And often times, those organizations host their own small set of services for their members. For example, when I was searching for help on how to set up something with Kubernetes, I came across this blog, where the blog author hosts services for their “Chaos Computing Club”, like proxmox, nextcloud (has a calendar app), matrix, and forgejo.

    Instead of trying to spin up a set of services for the whole “FOSS Community” start smaller and just host for your local groups. Maybe your local hackerspace already hosts these services.

    To find local meetups, I checked out https://meetup.com/, which has a lot.

    As for me personally, I am trying to put together services for my Cybersecurity club at my school, right now I have centralized identity, and virtual machine hosting for members to access and play with, but I want to also host extra services like the stuff you mentioned, because the reasons why you want them are good.

    On my blog, I discuss my plans and steps: https://moonpiedumplings.github.io/projects/build-server-6/

    I think creating a “FOSS hub” overall is a really really big challenge because all of these groups that make up the FOSS world have a heterogeneous set of overall interests, and an even more heterogeneous set of users.

    A simple example is the language barrier. Fun fact: There exist alternatives to apps that primarily have English as their first language, but in other languages first, centering around the communities those languages are used in. For example, the opendesk docs are in German first. Of course, there are English docs for things like engagement, but the problem is that —

    For something like a FOSS hub, user engagement is critical, and one of the best ways to have engaged users is dogfooding, where users contribute back to this software they use. But with software that treats one language or another as a first class citizen, there is becomes a bump, when users want to dogfood.

    The other problem is that the users themselves have different needs and wants. One user or set of users hates email and never wants to touch it. Another wants to exclusively use plain email for everything, including as an alternative to code forges, discussion platforms, and scheduling systems. One set of users prefers discord, the others prefer irc. They meet in the middle on matrix, but this other set of users hates matrix due to being VC funded and it’s just a clusterfuck.

    You cannot make both groups of users happy. When you try to please everybody, you end up pleasing nobody.

    What you can do, however, is catch the needs of your local groups and slowly expand from there. I think a FOSS Hub is possible, but I think trying to start it as a foss hub is bound for failure because the scope is too large.

    I think the closest thing right now is disroot, which hosts a lot of services, but again Disroot uses XMPP whereas some people may prefer Matrix for this usecase, and plenty of other nitpicks.










  • I’m pretty sure it’s possible to use timeshift to create backups on another drive using rsync (instead of btrfs). They are incremental, and deduplicated, as well.

    But the other commenters are correct, timeshift is not a backup tool, it’s more for snapshots to undo system changes you may not want. In addition to that, it doesn’t do user files by default — because again, it’s not a backup tool.

    btrfs send/receive technically does what you want, using btrfs to do backups to another drive, but I don’t think any GUI app supports it. Plus, you would have to create snapshots for btrfs from the command line.

    Your best bet are apps explicitly designed for this usecase, like someone mentioned pika, or borg or restic are good choices. They don’t do BTRFS, but they do incremental, deduplicated updates in a user friendly way.