I have a few Linux servers at home that I regularly remote into in order to manage, usually logged into KDE Plasma as root. Usually they just have several command line windows and a file manager open (I personally just find it more convenient to use the command line from a remote desktop instead of directly SSH-ing into the system), but if I have an issue, I’ve just been absentmindedly searching stuff up and trying to find solutions using the preinstalled Firefox instance from within the remote desktop itself, which would also be running as root.

I never even thought to install uBlock Origin on it or anything, but the servers are all configured to use a PiHole instance which blocks the vast majority of ads. However, I do also remember using the browser in my main server to figure out how to set up the PiHole instance in the first place, and that server also happens to be the most important one and is my main NAS.

I never went on any particularly shady websites, but I also don’t remember exactly which websites I’ve been on as root, though I do seem to remember seeing ads during the initial pihole setup, because it didn’t go very smoothly and I was searching up error messages trying to get it to work.

This is definitely on me, but it never crossed my mind until recently that it might be a bad idea to use a browser as root, and searching online everyone just states the general cybersecurity doctrine to never do it (which I’m now realizing I shouldn’t have) but no one seems to be discussing how risky it actually is. Shouldn’t Firefox be sandboxing every website and not allowing anything to access the base system? Between “just stop doing it” and “you have to reinstall the OS right now there’s probably already a virus on there,” how much danger do you suppose I’m in? I’m mainly worried about the security/privacy of my personal data I have stored on the servers. All my servers run Fedora KDE Spin and have Intel processors if that makes a difference?

  • taladar@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    arrow-down
    6
    ·
    1 year ago

    Of course I can store dozens of passwords but if every task that requires a single command to be run automatically on e.g. “every server with pending updates” requires entering each of those passwords that is unworkable.

    • 4am@lemm.ee
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      FreeIPA and your password is the same on every machine: yours. (Make it good)

      Service accounts should have either no sudo password or use something like Ansible with vault and keep every one of them scrambled and rotate regularly (which you can do with Ansible itself)

      Yes, even if you have 2 VMs and a docker container, this is worth it.

      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        arrow-down
        4
        ·
        1 year ago

        FreeIPA and your password is the same on every machine: yours.

        Any network based system like that sucks when you need to fix a system that has some severe issue (network, DNS, disk,…) which is exactly when root access is the most important.

    • ElderWendigo@sh.itjust.works
      link
      fedilink
      arrow-up
      6
      arrow-down
      2
      ·
      1 year ago

      Sounds like you’re doing things the hard way, making you believe that you are being forced into choosing between security and convenience.

      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        1 year ago

        Then enlighten me, what is the easy way to do tasks that do require some amount of manual oversight? Tasks that can be completely automated are easy of course but with our relatively heterogeneous servers automation a la “do it on this one test system and if it works there run it completely automatically on the 100 identical production systems” is not available to us.

        • ElderWendigo@sh.itjust.works
          link
          fedilink
          arrow-up
          4
          arrow-down
          4
          ·
          1 year ago

          Not my circus, not my monkeys. You’re doing things the hard way and now it’s somehow my responsibility to fix your mess? I’m SUPER glad I don’t work with you.

          • taladar@sh.itjust.works
            link
            fedilink
            arrow-up
            4
            arrow-down
            5
            ·
            1 year ago

            You are the one who insists that there is a better way to do things but refuse to say what that better way is.

            • bluespin@lemmy.world
              link
              fedilink
              arrow-up
              4
              arrow-down
              1
              ·
              1 year ago

              None of us can tell you the right approach for your specific system and use-case. People are simply pointing out that what you stated you’re doing is insecure and not recommended

              • taladar@sh.itjust.works
                link
                fedilink
                arrow-up
                1
                arrow-down
                5
                ·
                1 year ago

                And nobody in any of these threads has ever pointed out why it is considered to be insecure. The most probable origin for that idea I have come upon so far is that it is a left-over from pre-SSH days when people thought using the root password with su at something other than the start of their connection would make it harder to sniff. Literally nobody lists even one good reason why sudo should be more secure than direct root login with SSH public keys and password login disabled for full root access (as in not limited to just one or two commands).

                • MyNameIsRichard@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  5
                  arrow-down
                  1
                  ·
                  1 year ago

                  It’s not about someone sniffing your passwords, it’s about reducing your attack surface. If you use su then the entire session has root privileges and any piece of software you run could do system level damage if it has a bug. Using sudo limits the privilege escalation to just one command.