This is for a system with Secure Boot enabled.

If you remove or disable the root account, can malware still enable root or get just as powerful?

Perhaps by taking advantage of software faults like buffer overflows if you forget to keep it fully up to date at all times?

Not in any case I've ever heard of, but removing the root user is a really bad idea. It will break your system.

If you use Ubuntu or a derivative, root is obscured (that is the password is not known), which is kinda sorta disabling root; sudo is used to execute root commands. Sudo is included with every Linux distro I've used, but, commonly, it's not configured.

Malware is nowhere near the issue on Linux that it is on other operating systems. Part of this is that it's too small a bit of the market to be a popular target. Part of it is the built-in security model of using the computer as user and not using root privileges unless and until you need to do root tasks. Configuring a strong firewall is wise, but many experienced Linux users choose not to use anti-virus software, as there are currently no Linux viruses in the wild and haven't been for years. The Linux kernel includes firewall capability, and numerous command line and GUI programs make configuring it easierl

The biggest security threat in Linux is the person at the keyboard who goes to dodgy websites, clicks on questionable links, and falls for phishing schemes. Vulnerabilities do get discovered, but they are normally quickly patched.

2 members found this post helpful.

Apologies, the question is a little misleading because by malware I mean software by malicious hacker trying to remote control what they can after getting you to run a trojan on a computer that is ONLY used for browsing the internet and when you knowingly run unknown software while trying to learn underground security.

So if I allow you to run absolutely anything you like, can you or anyone else do what it says in the title? Would that strategy make persistence on a bootable usb flash drive impossible?

root account must not be disabled, because the system will not boot/start without that. But anyway if you can become root anyone else can do that too, so it is not impossible (but probably too hard...)

What if a script disables the root account after booting is complete and the boot is from a live USB flash drive that will re-enable root at the next boot?

I do not really understand what do you mean by "disable the root account"

It's not supposed to be possible, but there have been numerous examples of exploits that did it anyway.

When you're not running as a privileged user, the kernel is supposed to restrict your access to system resources. Other programs and daemons may be running with root privileges and offering services to unprivileged users, but they too must prevent such users from accessing protected resources.

If a bug is found in the kernel or in a piece of software that runs as root, it may be possible for a regular user to exploit said bug to obtain root privileges. This is known as a privilege escalation attack.

I don't either. Just seen some distros where typing su does not work. Only sudo. Therefore you can remove the regular user from the sudoers file, sudo no longer works, su does not work either, so no one can run commands with root previleges.

There must be more thorough ways to disable root though. Are they all vulnerable to programming errors allowing privilege escalation?

you need to allow to become root somehow. Either by sudo or su or whatever you find safe/convenient. But remember, if you can do that anyone else can be able to use that too.
From the other hand see post #7.

Root could be used on another computer that is not used with a web browser but is reserved for cooking the .iso's that go into the bootable usb flash drive of the production system whenever you want a system change, such as an update.

ok, probably I start to understand it.
for example openelec has a readonly root filesystem, which will simply disallow any modification of it. are you looking for something like this? Probably you need to boot from a live CD and that's all.

On a server, every cracker trying to brute-force their way in will know it has an account named root and will try that first. What they don't know is what the usernames of your other users are. Since the root account password is locked, this attack becomes essentially meaningless, since there is no password to crack or guess in the first place. And yes it is possible via privilege escalation attacks through setuid programs (programs that run as root) running on your systems: type find / -perm -4000 -print to find these programs and change them to read only for everyone except for the root user.

If your login id is a member of the wheel group, then you can simply sudo su, enter your own(!) login password, and ... "there you are!" The shell-prompt has become "#." You're now root.

A similar thing happens on OS/X or Microsoft Windows if you are "an Administrator."

These things are the reason why you should never use a login account "for ordinary purposes" which is a member of wheel. You're not Clark Kent. You can only step into a telephone booth to make a phone call – you won't emerge in blue tights.

- - -

Note that recent versions of Linux and OS/X have begun to impose limits on the root account: it is no longer "all-powerful."

- - -

The bottom line, however, is to never expose your system to "ssh hackers." Don't allow anyone on the outside world to be able to reach a login: prompt by any means at all. Secure your system using OpenVPN with tls-auth security and strong digital certificates. Anyone "port scanning" your system will see ... nothing. Anyone who suspects the existence of OpenVPN and tries to connect to it – will be silently and forever ignored. The only way to get to ssh (or to any other type of shell) is to pass through OpenVPN first – which they cannot do. (They can't even try. The door is shut, and hidden. There's 4096 + 1024 bits of pure entropy standing in the way.)

Increasingly that's what I am gravitating to unfortunately. This is unfortunate because cd drives nowadays have a short working life, not to mention the long boot time and time to burn compared to flash.

That's why I mentioned openelec, which can do that without CD. It uses squashfs.