So there is a desktop and root permission isn't needed on it (or if it's needed, then reboot to single mode/whateverlivecd fix a config file-> get root, do the stuff with it and at the end, disable again the root). There is no service on this machine (ex.: sshd), since it is a desktop.
My question: Does it bring more security if I disable the root user on a system? (If yes, how to do it? Disable password for it? Modifying the default shell for root to /sbin/nologin in the /etc/passwd and /etc/master.passwd file doesn't helps, since after reboot the shell will be ksh for it. Nevertheless the ex.: passwd file still contains /sbin/nologin)
Best Answer
Disabling the root password isn't really useful. Either there's a way to become root without using the password (such as another system service, or a security hole in a program running as root), in which case whatever you do about the password is irrelevant; or becoming root requires the password, in which case a strong enough password is as secure as disabling the password.
A strong password has to withstand brute force attacks. There is a first layer of security, which is that ordinary users cannot read the password hash, so they can only make attempts by calling
suorloginor a similar service. Even if an attacker manages to obtain the password hash, they have to calculate hashes by brute force until they find the right one. OpenBSD properly uses a slow hash; if you want your password to withstand a billion-CPU bot for 10 years, a password with 60 bits of entropy (13 random letter) is overkill.So my recommendation is to generate a strong random password, write it down on a piece of paper, and store it in a physically secure place. That way you have the password available in an emergency.
Of course, if you set up sudo, then your account becomes the weakest link, and there is no point in securing the root account more than your account.
OpenBSD offers a security feature that restricts the root account: the securelevel. If you set the securelevel to a positive value, then certain actions (including changing the securelevel, loading kernel code, and modifying files marked as immutable) are restricted to kernel code. This can be used to guarantee the integrity of a part of the system even if the root account is compromised; the downside is that console access is required in certain situations such as a failing hard disk. See File protection in Unix and How to guarantee the integrity of an OS? for more details, as well as the documentation.