5 ms·

Well technically Unixes like Linux are a mountain of legacy and they are fine. Windows is just a mountain of shit.

• direwolf20 8mo ago
  Unixes like Linux are not immune.
  • dgxyz 8mo ago
    True, as systemd and wayland point out elegantly. But at least there is a modicum of choice there.
    • jamespo 8mo ago
      Ironic in a post about a CVE, as systemd offers more security options for starting services than anything else.
• nananana9 8mo ago
  "Fine" Why does every Linux distro under the sun try so hard to protect the garbage under /usr/bin/ and /etc/ when literally the only files that matter to me are in /home, which is a free-for-all?
  • dgxyz 8mo ago
    The first point is fairly obvious and the latter point is not true (AppArmor etc)
    • oblio 8mo ago
      Phew, I'm so relieved that now we have the One True Security Solution To Rule Them All, AppArmor. Oh, what do you mean there's also SELinux, Snap, Flatpack, Docker, Podman, ...?
      • StilesCrisis 8mo ago
        He did say "etc"...
        • oblio 8mo ago
          Fairly sure the "etc" came after my comment, in an edit.
          • dgxyz 8mo ago
            No, it didn't. I've only just come back to review it after I posted it and there wasn't a reply.
  • TZubiri 8mo ago
    >Why does every Linux distro under the sun try so hard to protect the garbage under /usr/bin/ and /etc Because a compromised user could infect shared executables and spread the infection. A bit harder to do with etc but for sure possible. The main target would be infecting bash and you are done from the get go. >when literally the only files that matter to me are in /home, which is a free-for-all? The home folder's read write is usually restricted to the user. The only scenario where this isn't the case to my knowledge is Ubuntu where others can read it, but this is just a huge flaw in Ubuntu that almost no other distro has.
    • oblio 8mo ago
      > when literally the only files that matter to me are in /home, which is a free-for-all? > The home folder's read write is usually restricted to the user. Yeah, and that is the point. All user's programs including curl, wget, the web browser, anything else that connects to the network run as the user, and all the user's programs, by default, have access to everything inside ${HOME}. Most people don't really care if /bin gets obliterated, but they do care dearly when /home/joe/photos/annies-2nd-birthday gets wiped.
      • skydhash 8mo ago
        Protecting a user from himself is hard. Protecting user from others is easy. Linux is influenced by unix and a lot of installations are servers. Where most programs run under their own accounts. You can always have two user accounts: oblio and unsafe-oblio anf have a shared folder between the two for transferring files. Or invest into some backup software.
      • dgxyz 8mo ago
        Backups FTW.
      • TZubiri 8mo ago
        Just make another user bro. If you can't even create a user to run a program you distrust, the issue is not that windows doesn't provide sandboxes, it's that you don't use them And no, it's not "a lot of work" it's the bare minimum
  • razighter777 8mo ago
    Linux /home is far from a free for all. flatpak, landlock, selinux, podman, firejail, apparmor, and systemd sandboxing all exist and can and do apply additional restrictions under /home
  • thewebguyd 8mo ago
    Because Linux (and other nixes) have their root in multiuser/time-share systems/servers. Protecting the system* from the users was important, and protecting users from other users equally as important. Protecting the user's $HOME from themselves/user-level programs wasn't as much of a concern, the user was assumed to be responsible enough to manage it themselves.
  • lunar_rover 8mo ago
    Canonical and Red Hat have been modernising things for a long time, albeit slowly. Most funds went into server components. As for the desktop community… Well, it has a severe lack of professionals.
• est 8mo ago
  > a mountain of legacy and they are fine. telnetd CVE-2026-24061. It's embarrassingly simple exploit but took years to be discovered. > When telnetd invokes /usr/bin/login, it passes the USER value directly. If an attacker sets USER=-f root and connects using telnet -a or --login, the login process interprets -f root as a flag to bypass authentication, granting immediate root shell access.
  • Sohcahtoa82 8mo ago
    Well yeah, but nobody sane still uses telnetd.