• 1 post
  • 25 comments
Joined 3 years ago
Cake day: August 10th, 2023
  • Debian unstable/sid (the rolling branch) was affected. Debian is not special.

    Debian stable, Red Hat, and Ubuntu LTS were not affected. They also happen to be popular on servers, because of things like this.

    This specific attack was discovered early,

    Debian only updates packages on a new distro release, every 4 years. Red Hat does so every 13 years. There is a huge difference between a 6+ year window to detect packages, and a less than a week’s notice because you are keeping up with the latest from upstream.

    The stable distro model is broken.

    I will address this one at the end, since it’s a longer point.

    Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones.

    Okay. And? We are talking about supply chain security here.

    There is a huge difference between vetting packages once every 6 years, and the continuous, ongoing, toilsome process that you are made to in order to maintain systems like cargo’s build system.

    despite actually shipping the compromised xz version? It’s Arch. Why? Because they didn’t patch systemd with xz support thinking they can outsmart an upstream.

    The XZ utils backdoor could have easily effected any distro that uses xz for any form of root/system level service. The backdoor makers decision to not do this doesn’t actually make Arch or other distros that did this more secure. Debian stable did not receive vulnerable code in the first place. Big difference.

    Distros pull from upstreams anyway (code has to exist somewhere), crates.io included.

    This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.

    But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.

    What makes you think JAVA or its ecosystem(s)

    The Java ecosystem, and it’s various language specific package managers have lots of problems. But I am specifically talking about the Java ecosystem available from stable Linux distros, like Red Hat or Debian.

    So. Why would I want a stable distro? Why would I want “old” packages? The reason is very simple: The absolute guarantee of compatibility between the security updates, of the programs themselves, and dynamically linked libraries.

    If I make, say, a Java program, and tie it to Java packages available from the stable distro, when programs in that

    The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don’t update them. This results in them shipping code with CVE’s to their users, even though the CVE has already been fixed in an upstream version.

    I like to run cargo-audit, or the go equivalents on the open source projects I look at, and I almost always find vulnerabilities of varying degrees of criticallity. Here is cargo-audit ran against radicle-tui: https://gist.github.com/moonpiedumplings/7e71121b76c58ecaba4176be9bb827c4

    With a mere 5 months of not being touched, there are now present CVE’s that are critical on the scoring system (radicles top repo had none yippee! and their second to top repo had a few mediums). It irritates me to see them in software that interacts with networked systems.

    I only very rarely find programs that are empty of CVE’s. Usually only the most well resourced, active projects are able to keep their audit clean. It’s a lot of work —

    Work that a stable distro automates. With a stable Linux distribution like Debian, I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.

    Look, you don’t have to use a stable distro on your own personal Linux desktop. I use Arch on my laptop. But for servers, not using pinned dependencies, and instead linking against libraries provided by distros means saving thousands of hours of toil doing basic cleanup of updating libraries and figuring out what the newer version of libraries broke. With a stable distro, you just do that once every six years.

  • Just curious, what RMM software are you using?

    So, the way Active Directory policies work is quite interesting under the hood. They are essentially served over SMB, and then clients query them, before applying them locally, or you can “push”, requesting clients to do this. To be explicit: group policies are the same local security policies, but synced. Of course their is a little bit more nuance, technically they are separate but group policies always win in case of conflict. Regardless, what I mean is that it’s not magic, it’s not really technically superior to other ways to do it, and you could theoretically get something of equivalent resilience.

    scripts are not reliable and tend to break with updates, they won’t stack well

    The cool thing about Active Directory policies, is that they are declarative, and idempotent. This means, that rather than say, editing a config file, or installing some program, you are just setting variables to values. A script that sets secpols.whatever to X value won’t really care about things like the order of the script, or whether the value has already been set, or whatever.

    Because of this group/security policies this way will be fairly reliable. Using powershell to set goup/security policies, isn’t really the same thing as doing scripting that does logic. Like, say I have a script that checks for something, then does something else — that’s where things begin to get brittle.

    Now, this is one half of the end, system management. The other half of what Active Directory provides is centralized accounts (IDM/IAM). Other services connect to active directory for authentication, so people use it to log into say, their file server, or their firewall, or the servers, or whatever. When a user leaves, or is compromised, or whatever, you can simply lock their account. This is much, much better, both in security wise, and ease of use wise for provisioning/onboarding users. The previous model, is “password sprawl”. Where a spreadsheet of passwords for services gets passed around, and sometimes makes it into the hands of attackers. There is no easy way to audit all the services, ensure that the passwords are up to date

    Now, if you are avoiding Active Directory, there exist alternatives for centralized accounts. For example, you can use Microsoft’s Cloud stuff, and then use that to authenticate the local machines. Don’t give the users admin, and then managing the group/security You can then use Microsoft 365, or Entra ID as a centralized authentication point for external, non microsoft cloud services.

    This can be superior to Active Directory for a few reasons. One reason is that Active Directory is a hard, toilsome service to deploy and secure. You have to sit on top of it, watch for CVE’s, and patch them. On the other hand, a small, specialized RMM server is much easier to secure, and way less attack surface. Also, if it’s push based to agents, it can be updated without any downtime, compared to users not being able to log into services when LDAP goes down. By offloading security onto cloud services like Microsoft’s authentication methods, you can gain a big increase in uptime and security, at a very low cost.

    Another is cost. A smaller RMM will be cheaper… or free if you are using an open source solution (like TacticalRMM which is built on Meshcentral (but Meshcentral can also be deployed seperately)). Active Directory on the other hand, costs money.

    "this is how we were advised to proceed”

    But, let’s be honest. What I wrote above is a charitable interpretation, where I am assuming what they are doing is good. What is described above is cool, but only 0.01% of environments you encounter will have novel, well thought solutions like this. It is way more likely that intuition is correct, and the infrastructure is simply brittle and insecure.

    Now, you probably want to change it, and that’s good! But you need to understand, that changing it is not so simple. At many businesses, security is treated as an expense with no benefit. It doesn’t actively make a profit, or save money, so it is ignored. Even free solutions that cost labor will be tough to push through. Active Directory is paid, but is honestly not that much ­— but the migration and deployment phase might cost a lot. You need to understand that, you are trying to fight through that, when convincing people in charge of making these decisions.

    You also need to understand, that when you argue or make points towards AD, or any better security solution, the people you are arguing with will not always be honest about the reasons. Perhaps they themselves don’t understand why.

    If you attempt to debate, you are may hear a bunch of excuses that obfuscate the real reason why better security isn’t pursued.

    • "this is how we were advised to proceed”
    • “We need administrators trained”
    • Various technical reasons, ranging from absurd BS to legitimate critique
      • “Our firewalls block SMB”
      • “Laptops”
      • “We have Linux servers”
    • AD Costs money

    And then, even if you grind down all these arguments, sometimes you are still just met with simple flat out rejection.

    So. If you want to increase security, you have to think like them. You have to translate it to $$$, and put that on a page, on a report, that you can summarize and present. One assumption I would like to correct in advance is the idea that “Labor hours = dollars”. From what I’ve seen, arguing that “automating xyz process saves my engineering hours” arguments, don’t really seem to work. What is arguably the most effective, is presenting a way to either save money (and I mean raw cash, not engineering hours), or make money, that incidentally increases security.

    Of course, not everybody is motivated by dollars. Sometimes it’s a senior engineer who wants things done “their way”, for specific reasons. Sometimes an executive is incapable of remembering a password other than “Password123!”. You have to understand why and work with their motivations.

    This is politics. Balancing peoples interests, making concessions, and granting them what they want in order to advance your own interests. Unfortunately, it’s a skill, that you will probably need in order to advocate for security.

    Good luck.

  • Check out Zotero: https://www.zotero.org/

    Zotero is an open source bibliography manager. It’s my main go to tool for generating works cited pages, like during essays.

    But, it also has a browser extension, which can download, and archive sites or academic articles you are adding to the sources. I would then use the fulltext search that zotero provides for easy searching of sources.

    Unfortunately, it’s not hosted, which would make it difficult to share.

    EDIT: It does look like the server component is open source, AGPLv3: https://github.com/zotero/dataserver/

    But, I cannot find any deployment instructions. But, it looks like their hosted version lets users create groups of shared items, including sharing archived snapshots of the various items.

  • One issue I have with rust is that it adds another layer of trusting the compiler isn’t backdoored. All UNIX/Linux systems use the gcc toolchain

    They are probably also referring to this: https://kerkour.com/rust-supply-chain-nightmare

    In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

    Cargo and crates are basically just as bad as npm, just less popular, which is why they haven’t been hit yet… And it’s currently very difficult to build rust programs without cargo.

    Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers. Debian, for example, was not affected by the xz utils backdoor, due to it’s policy of only doing cherry picked security patches, and ignoring feature or bugfixes for the most part. Given the:

    installation instructions for Debian-based distros: here

    That’s probably what the author was going for. Unfortunately I am too lazy to load up tor browser right now, to check the Debian installation instructions. I suspect they have their own repo with signed keys, just like Radicle does.

    Of course, C is still questionable. I would prefer Java if you cared strongly about supply chain security, since its a memory safe language with a mature ecosystem, and many packages available from Debian’s repositories. But, it would be slower than C.

  • Calling an enterprise-grade platform

    Except you use JWT’s for auth, which is idiotic and a security nightmare. No enterprise that cares about security would ever accept this.

    More info: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452

    There are other problems, some of which I can see… and some of which I can’t. The problem is that I am not a comprehensive expert, I can only spot a few things here and there. Even if I was an expert, why would I audit your software for free lmao? Pay me for that shit.

    What I do know, is that vibecoded apps are bad at security. Many, many vibecoded apps have been hit by horrific security bugs like remote code execution, xss, or authentication bypasses. That shit is simply unacceptable and should be extremely rare in modern apps. The fact that I’m not skilled enough to find them reliably makes me even more cautious and concerned around apps like yours.

    It’s not just about the app architecture, but also about you. When a known community figure creates an app, I have confidence that they will have a good security posture and architecture. With vibecoding… not so much.

    If you have an actual architectural critique

    Nice bait, but the problem is this: Just because you get people to audit “critique” your software, doesn’t fix the root cause of those problems — you. Just because you manage to re-vibecode the app to not use JWT’s or to fix any other number of issues someone would point out, doesn’t actually mean more issues exist that that person missed. Like if someone specialized in python, then they might miss database issues, and so on. The second problem is that inevitably, you will expand this software, adding more features… and vulnerabilities. That is to say, even if you manage to fix the architecture and security now, you have not demonstrated the requisite skill needed in order to keep it fixed.

  • What if the new account user, who is working on a product that integrates with what the vast majority of selfhosters run, just found Lemmy?

    This happens on Reddit, and basically my problem is that these users often don’t have enough experience to be able to actually give solutions. Reddit is full of people who think they have a good solution, dealing with comments of people explaining that what they are struggling with is actually a solved problem (or a skill issue). No one cares about your vibecoded slop that implements 1% of the features of an existing open source solution (they used to not be vibecoded but we still didn’t care). It being paid and proprietary is just even more annoying.

    My idea of requirement to engage with the community is also about being able to ensure that the users are technically competent. If they are experienced, it will show up in the discussions we can see and review. For their benefit, if they lurk, then they can take a look at what is being used, and what problems actually exist, instead of making assumptions.

    If they really believe their product is so good, they can spend a few weeks helping people with Linux questions and sharing their (non product related) insightful thoughts on Lemmy so I don’t dismiss them instantly when they finally advertise it.

  • nix doesnt have any of these, but sandboxing is hard, there is either stable or unstable, changing and configuring things is very complex. Likely no official packages. Still the method I prefer.

    Nix is what I use, and it was frustrating to have to hack a lot of it into place, but I feel like it has the most potential. Unfortunately the flakes nonflakes split, in combination with the split of “distros” like determinate nix, flox, and so on, and the governance concerns really hold it back. It has horrific documentation, for the most part caused by the above (flakes are “experimental” and so can’t be included in official docs), and it is frustrating the lengths I have to go to to make stuff work that should be easy.

    For example, GPU acceleration of Nix packaged apps on non Nixos systems. I figured out how to do it:

    (config.lib.nixGL.wrappers.mesa pkgs.gzdoom)

    source

    But I think it’s just straight up impossible to do this via imperative package installs, outside of home manager. And it’s kind off important if you want any GUI app whatsoever to work.

    But now that I have it working, I use Nixpkgs exclusively and am able to avoid the AUR entirely. To me, the AUR is a last resort, only for something like say, system level printer drivers (thankfully I’ve never needed to install anything to get printers to work). By ensuring that I only use the AUR once in a blue moon, I can make sure that I actually review the PKGBUILD when using it.

  • They are probably referring to the way that snap, flatpak, and distrobox are available as official packages in most linux distro’s repositories, whereas nix isn’t. I have encountered this frustration for sure. Debian and Arch provide nix packages, but many other distros don’t.

    In addition to this, nix requires manual setup if you install it from the repos, which is annoying. And then you have to do further manual setup to enable flakes, and then you have to figure out how to install packages and it’s not fun.

    So the main way people install nix is via the curl | bash scripts various “distros” of Nix provide.

  • Unraid is an example, that I consider fairly reasonable. Sure, it is a subscription.

    But all of the services are docker containers. What unraid brings to the table is a nice management UI, and the ability to mix and match drive of different sizes in a single raid pool. It makes having a fairly resilient self hosting setup easier than trying to do all of this stuff from scratch.

    Nice features sure, that many people find worth paying for, even if I don’t. But they are just nice to haves. If the company ever dies, it’s absolutely possible to export the data and move to say, portainer, or docker via the cli, or podman, or anything that can run containers.

  • On reddit, there is a community called r/progressionfantasy, which is about a specific type of fantasy fiction. They have a rule that self promotional posts (for paid books) must be preceeded by 10 comments, and actual engagement with the community.

    This is a reasonable compromise, in my opinion. Known community member who has been answering questions and contributiting to discussions?

    I would be okay if they dropped a paid product of good quality and with a reasonable business model (please no vibecoded slop).

    But drive by ProductNameAccount users who have never posted on lemmy before a bunch of self promotional posts? Yeah ban that shit.