Skip Navigation

Posts
8
Comments
538
Joined
1 yr. ago

I'm the Never Ending Pie Throwing Robot, aka NEPTR.

Linux enthusiast, programmer, and privacy advocate. I'm nearly done with an IT Security degree.

TL;DR I am a nerd.

  • People keep finding significant vulnerabilities in its cryptography and the Matrix team tries to deflect or create strawmans for why it isnt actually a vuln. Soatok found a vulnerability in 2024 by just browsing the source code for tiny bit of time, and again just two weeks ago after looking for a couple hours. In both cases, Matrix then responded to his vuln report with hostility, saying it wasnt actually a vulnerability. He is sitting on another vulnerability.

    Having a cleartext mode is a security downgrade and no secure messenger should support cleartext. It only barely got functional forward secrecy recently. VoIP in most Matrix clients (and servers) still use Jitsi backend which isn't E2EE, even with the release of the newer (secure) Element call protocol. Matrix leaks tons of metadata, such as usernames, room names, emoji reactions, generate URL embedded previews. Rooms arent encrypted by default. It is also a UX nightmare and often times you cant decrypt your messages.

    Matrix is not secure. You'd be better off with XMPP and OMEMO which has its own problems and isn't secure either. Sill better than Matrix.

  • Session is a security downgrade. It doesnt support forward secrecy which is hella important.

  • Also the repo image

  • Yes, I understand what GVisor does. Cgroups2 are for isolation of system resources, bit arent even the main sandbox feature used for isolation by Docker. I am pretty sure namespaces significantly more important for these containers' security.

    GVisor helps with one of the main risks in a container setup which is the shared kernel by hosts and guests. I understand it comes with a performance penalty (and I didnt know it was incompatible with SELinux), but that does change my original point that GVisor is a security improvement to default Docker. I understand there is more nuance, even when I wrote my original comment I understood (just like any other security feature) it cant be used in every scenario. I was being intentionally general, and in my second comment I was pretty specific about what it protects against: Kernel vulnerabilities and privilege escalation.

    I researched cgroups2 more and I still dont understand why you brought it up in the first place. Cgroups2 and gvisor provide very different security benefits. Cgroups help to keep a system available (lessening the risk DoS attacks) by controlling access to some system resources (io, devices, cpu, memory) and grouping processes of a similar type. It seems rather optimized to solve resource control on a container host. I mentioned gvisor because it is mostly just a drop-in replacement container runtime which doesnt need setup to be used.s

    Now for a different container runtime which provides significantly more features (than gvisor) with less downsides (if configured correctly for a specific workload), Sydbox provides syd-oci which id an application kernel runtime which uses a permission config file to create a sandbox, isolating using namespaces, seccomp, landlock, and more. It can sandbox in many different categories (often times leveraging multiple features to provide a multilayer sandbox), you can see the categories at the syd manpage. The biggest downside is that you must really understand what your container application needs otherwise it will prevent it from running. It is a "secure by-default" sandbox which can be softened through config.

  • I dont really understand what you mean in your last sentence.

    My reason for saying GVisor is safer is because it is an application kernel which provides traps and emulates most Linux syscalls in the guest with a far smaller set of syscalls to the host kernel, helping to prevent container escapes and privilege escalation. GVisor also fully drops privileges early into start up (before running any significant logic), helping to prevent privilege escalation.

    Cgroups is not a really a security feature (from what I understand). It is about controlling process priority, hierarchy, and resources limiting (among other things). You can not use GVisor with LXC.

  • It was posted in like 5 different communities, some not even close to related (for example 3 Linux communities), some posted twice (eg. the Linux previously mentioned communities). They could have just crossposted it using the feature. Either way it is still a lot of spam. It isnt even that important of news because anyone who cares about this (anti or pro LLM) has already made up their mind and would already have formed an opinion on this feature without a random article.

  • The UI is proprietary.

  • In order of most to least secure

    VM > Docker+GVisor > Docker/LXC

    Docker+GVisor is good middle ground because it provides the guest container with an application kernel in a memory safe language and reduced syscall attack surface to avoid kernel container escapes. Docker/LXC share the kernel with the host.

  • One of my gotos is that they may have nothing to hide, but their friends and family (or people who they know who are at risk) might like having privacy. People don't (unusually) live in isolation and others are affected by their actions/choices.

  • They disregard the risk from the vendor because you are already using their hardware. The hardware has firmware already included which is proprietary, the hardware itself is proprietary, and hardware effectively runs as root anyways. You should already trust your hardware or you shouldn't be using it. Linux-libre is a purity test, that is it. It is security theater which actually, definitely, really makes you vulnerable without doing anything meaningful. The only time it makes any sense is if you only use open source hardware.

  • They disregard the risk from the vendor because you are already using their hardware. The hardware has firmware already included which is proprietary, the hardware itself is proprietary, and hardware effectively runs as root anyways. You should already trust your hardware or you shouldn't be using it. Linux-libre is a purity test, that is it. It is security theater which actually, definitely, really makes you vulnerable without doing anything meaningful. The only time it makes any sense is if you only use open source hardware.

  • Being 2 months late to a quarterly patch is still very bad. /e/OS should be avoided.

  • A good idea also if you want to help the tape stick better is to wipe the surface with a slightly damp rag to remove any dust.

  • Well then my recommendation still stands because painters tape sticks pretty well.

  • The embargo on security patches isnt what i am talking about. Once security patches are released, /e/OS takes 1-2 months to patch these vulnerabilities. This isnt because of the embargo but in addition to it! They are by far the worst about this out of any of the alt Android ROMs (2nd worst is iode, at around ~1 month). /e/OS has been terrible about security for years even before all this "Google security patch" nonsense.

  • I hope for your sake that the tape you used isn't too sticky otherwise it will tear off the paint in some places, or the very least might leave the walls sticky. It kinda looks like duct tape, I'd recommend paper masking/painter's tape which is meant to be used on walls. It often comes in blue or beige but you can by it in other colors, it wont fall off easily, doesnt leave residue, wont risk damaging the paint, and is most likely cheaper.

  • 196 @lemmy.blahaj.zone

    Jeff the kicker rule

  • 196 @lemmy.blahaj.zone

    Beatles rule

  • 196 @lemmy.blahaj.zone

    HD2 Rule

  • Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ @lemmy.dbzer0.com

    What is the URL for AudioBookBay?

  • 196 @lemmy.blahaj.zone

    does not rule (also fuck the police and corporate news)

  • 196 @lemmy.blahaj.zone

    #1 Rule of USA Healthcare: discriminate against poor people.

  • 196 @lemmy.blahaj.zone

    The GOAT (rule)

  • 196 @lemmy.blahaj.zone

    mr(ule) boner