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?
You must log in or register to comment.
You seriously need to stop what you’re doing. Log in with ssh only. If you need multiple terminals use multiple ssh sessions, or screen/tmux. If you need to search something do it on your desktop system.
The server should not have Firefox installed, or KDE, or anything related to desktop apps. There’s no point and nothing good can come of it.
This. Thread should have officially ended here.
Yeah there’s a bit of scope to review what op is doing here.
Why is there even a DE on a server if it’s headless. If it’s not headless why not write up some Dockerfiles and manage it from a non-root account?
Are the services running as root?
Also, is it being accessed via wireguard/ovpn? It would be unwise to run a server as root with an open port.
came to say this
I think there are many security issues with your setup. You really, really shouldn’t do everything as root. That is just a time bomb waiting to blow.
Your frame of mind is “dangerous”. If you are browsing on your servers as root, you need to not manage servers anymore. If that sounded harsh, learn about attack surface area first and then I might let you back in the server room.
You won’t find discussions about running browsers as root because it’s not something you should need to discuss. Also, you don’t need to be browsing “shady” websites to get compromised. Get that myth out of your head.
find it more convenient to use the command line from a remote desktop instead of directly SSH-ing into the system
How is extra steps and added latency more convenient? The latency of a console via remote desktop would drive me crazy. Hell, I haven’t installed any kind of desktop environment on Linux server for over 20 years. It’s not needed and a waste of resources. Who needs file managers anyway?
Is it actually dangerous to run Firefox as root?
Yes, very. This is not specific to Firefox, but anything running as root gets access to everything. Only one thing has to go wrong for the whole system to get busted.
usually logged into KDE Plasma as root.
Please don’t do this! DEs are not tested to be run as root! Millions of lines of code are expected to not have access to anything they shouldn’t have and as such might be built to fail quietly if accessing something they shouldn’t in the first place. Same thing applies to Firefox, really.
Please don’t do this! DEs are not tested to be run as root! Millions of lines of code are expected to not have access to anything they shouldn’t have and as such might be built to fail quietly if accessing something they shouldn’t in the first place. Same thing applies to Firefox, really.
Could you elaborate on this? I’m genuinely surprised because Fedora just asks you if you want to have the option to log into root from KDE during installation, so I always just assumed that it’s intended to be used that way.
I don’t know the specifics on Fedora’s installer, but normally that question is about disabling root account, not logging into a DE.
Not sure what else to elaborate here. There’s a bunch of code that is not tested to be run as root. A whole class of exploits becomes unavailable, if you stick to an unprivileged user.
Say there’s some exploit that allows some component of KDE to be used to read a file. If it’s running under an unprivileged user - it sucks. Everything in user’s homedir becomes fair game. But if it runs as root - it’s simply game over. Everything on the system is accessible. All config, all bad config, files of all applications (databases come to mind). Everything.
Thank you.
Say there’s some exploit that allows some component of KDE to be used to read a file. If it’s running under an unprivileged user - it sucks. Everything in user’s homedir becomes fair game. But if it runs as root - it’s simply game over. Everything on the system is accessible. All config, all bad config, files of all applications (databases come to mind). Everything.
This is also something I’m thinking about: All the hard drives mounted on the server is accessible to the only regular user as that is what my other computers use to access them. I’m the only one with access to the server so everything is accessible under one user. The data on those drives is what I want to protect, so wouldn’t a vulnerability in either KDE or Firefox be just as dangerous to those files even running as the regular user?
Also, since my PC has those drives mounted through the server and accessible to the regular user that I use my PC as, wouldn’t a vulnerability in a program running as the regular user of my PC also compromise those files even if the server only hosted the files and did absolutely nothing else? Going back to the Firefox thing, if I had a sandbox breach on my PC, it would still be able to read the files on the server right? Wouldn’t that be just as bad as if I had been running Firefox as root on the server itself? Really feels like the only way to 100% keep those files safe is to never access them from an internet accessible computer, and everything else just falls short and is just as bad as the worst case scenario, though maybe I’m missing something. Am I just being paranoid about the non-root scenarios?
How does a “professional” NAS setup handle this?
You keep your files safe by having backups. Multiple copies. Set up the backups to gets copied to another server or other system your regular user doesn’t have access to. Ideally, you follow the 3-2-1 backup standard if the files are important. That is 3 copies, on 2 different media, and 1 offsite. There are many ways of accomplishing that and its up to you to figure out what works best.
You never log in as root. On every new VM/LXC I create, I delete the root password after setting it up so that my regular user can use sudo.
Run as your regular user and sudo the commands that need privileges.
Also if these are servers, run them headless. There’s no need for a GUI or a browser (use wget or curl for downloads, use your local browser for browsing)
Yes, it is. As a user you compromise only that user as a consequence of some sandbox escape. Then there may or may not be some successful privilege elevation.
I have no clue how dangerous running Firefox as root is, but it begs the question…why would you do that?
Create a user account for managing things and create a separate user for each service and/or containers.
For managing things use tmux with ssh, if you want to manage files etc. just use ranger/lf/mc. One can also mount the file system with sshfs.
This is like removing a safety feature in your car. Like removing seatbelts or maybe anti-lock brakes.
Realistically it’s not super dangerous, and no you probably don’t have a virus just from browsing a few tech support sites, but you do eliminate your last line of defense when you run software as root. As you know, root can read/change/delete anything on your system whereas regular users are generally restricted to their own data. So if there is a security problem in the software, it’s made worse by the fact that you were running it as root.
You are right though that Firefox does still have its own protections - it’s probably one of the most hardened pieces of software on your computer exactly because it connects to the whole wide internet - and those protections are not negated by running as root. However if those protections fail, the attacker has the keys to the kingdom rather than just a sizable chunk of the kingdom.
To put that in perspective though, if there is a Firefox exploit and a hacker gets access to your regular user account, that’s already pretty bad in itself. Even if you run as a regular unprivileged user they would still have have access to things like: your personal documents, your ssh keys, your Firefox profile with your browsing history, your session cookies and your saved passwords, your e-mail, your paypal account, your banking information, …
As root, they could obviously do even more like damage like reading all users’ data, installing a keylogger or screengrabber, installing a rootkit to make themselves undetectable, but for most regular users most of the damage is already done when their own account is compromised.
So when these discussions come up, I always have to think about this XKCD comic:
They might have access to all that data once but a lot of the paths towards making that a persistent threat that doesn’t go away after the next reboot and most of the ones towards installing something even deeper in the system that might even survive a reinstall do require root.
That’s what I said yes.
It’s about as dangerous as using IE in the old days, or Edge in administrator mode.
but no one seems to be discussing how risky it actually is.
That is because people stopped doing it ages ago.
But shouldn’t Firefox be sandboxing every website and not allowing anything to access the base system?
Security is always a matter of layers. Any given layer can fail some of the time but you want to set up your security so situations where all the layers fail together are rare.
My goodness
Usig anything as root is a security risk.
Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.
So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.
Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.
Ideally you run the UI as a normal user and then use sudo to run individual commands as root.
So is the main worry with GUIs that they have potential code execution vulnerabilities? Or is the worry that the plugins themselves are malicious?
Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.
There are non-UI applications with similar problems though.
Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.
I just wanted to add that you can run gui applications through ssh with x11 forwarding, options -X or -Y (untrusted/trusted but at least in Debian back in the day they behaved the same). So if you wanted a gui file manager you run it in the ssh session on the remote server, sudo if you need but NEVER logged as root, and the window will pop on your local DE instead of having to run an entire desktop on each server
Firefox does sandbox everything but vulnerabilities exist and sometimes go unnoticed for a while before they’re discovered and patched. If a malicious script does manage to escape the sandbox it will be able to do literally anything to the system since it has root privileges. It would have full access to any device that’s in /dev, it could create, modify and delete udev or iptables rules, it could mess with the BIOS since the kernel exposes EFI variables, if the mainboard has re-writable flash chips for the firmware it could write malicious code to them since they may show up in /dev, etc. If any of this makes you uneasy then you probably should stop running stuff as root in general except for when you really need to.
Also in general you don’t want to run any graphical applications on a Server unless there is a very specific reason for it because it takes up extra resources and therefore makes the machine use more power overall. This is especially bad when the machine in question has no hardware acceleration and renders everything in software. Remote desktop also adds CPU/GPU load and takes up a good bit of I/O and network bandwidth which is not ideal for a NAS server.
As a general best practice, you should never directly login as root on any server, and those servers should be configured to not allow remote connections as the root user. You should always log in as a non-root user and only run commands as root using sudo or similar features offered by your desktop environment. You should be wary of even having an interactive root shell open; usually I would only do so on a VM console, when first setting up a system or debugging it.
By doing this, you not only guard against other people compromising your system, but also against accidentally running commands as root that could damage your system. It’s always best to only run things with the minimum permissions they need, and then only grant them additional permissions on an as-needed basis.
you should never directly login as root on any server, and those servers should be configured to not allow remote connections as the root user. You should always log in as a non-root user and only run commands as root using sudo or similar features
That is commonly recommended but I have yet to see a good solution for sudo authentication in this case that works as well as public key only SSH logins with a passphrase encrypted key and ssh-agent on the client-side. With sudo you constantly have to use passwords anyway which is pretty much unworkable if you work on dozens of servers.
Whose letting you run dozens of servers if managing dozens of passwords is “pretty much unworkable” for you?
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.
Sounds like you’re doing things the hard way, making you believe that you are being forced into choosing between security and convenience.
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.
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.
You are the one who insists that there is a better way to do things but refuse to say what that better way is.
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.
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.
You could implement NOPASS for the specific commands you need for a service user. Still better than just using root.
In what way would that be more secure? That would just allow anyone with access to the regular account to run those commands at any time.
You can allow only specific commands and options. See my config for example.
You can limit this to a specific user as well.
Anyone who hacks into the account can now only run those tightly defined commands and no others. Compared to root, who can run anything.
I am well aware that sudo can limit which commands you run but so can force_command in authorized_keys if you really need that functionality.
Realistically, there is only a trivial pure security difference between logging in directly to root vs sudo set up to allow unrestricted NOPASS access to specific users: the attacker might not know the correct username when trying to brute force. That doesn’t matter in the slightest unless you have password auth enabled with trivial passwords.
But there is a difference in the ability to audit what happened after the fact if you have any kind of service storing system logs remotely or in a tamper-proof way. If there’s more than one admin user on a service, that is very very important. Knowing where the compromise happened is absolutely essential to make things safe.
If there’s only ever going to be one administrative user (personal machine), logging in directly as root for manual administrative tasks is fine: you already know who the user is. If there’s any chance there might be more administrative users later (small but growing business), you should consider doing it right from the start.
I was aware of the login UID for auditd logging as a difference but as you say, that is only really helpful if the logs are shipped somewhere else or tampering with them is otherwise prevented for admin users. It is not quite the same but the auth.log entries sshd produces on login also contain the key fingerprint used to login these days so on a more limited scale you can at least tell who logged in when from those (or whose key but that is no different than whose account for the sudo approach).
you should consider doing it right from the start.
Do you have any advice on how to use the sudo approach without having a huge slow down in every automated process that requires
ssh user@hostcalls for manual password entry? I am aware of Ansible but I am honestly very sceptical of Python tools since they tend to break easily and often from my past experiences and I would like to avoid using additional ones for critical tasks. Plus Ansible in particular seemed to be very late with their Python 3 transition, as I recall I uninstalled it when it was one of the last tools left that did not work with Python 3.Well, my recommendations for anything semi-automated would be Ansible and Fabric/Invoke. Fabric is also a Python tool (though it’s only used on the controlling side, unlike Ansible), so if that’s a no-go, I’m afraid I don’t have much to offer.
I thought your passwordless passphrase passkey ssh connection that is superior to passwords was secure. Is it not?
It is. That is the whole point. Why would I make extra unprivileged accounts that can run any command I need to run as root at any time without a password on the system just to avoid it. That just increases the attack surface via any other vector by giving an attacker accounts to choose from to break into.
