Sudo vs su root code#
Sudo vs su root password#

There's no way of restricting copies, and if someone does make a copy, they have all the attempts they want to brute-force the passphrase.

Sudo vs su root password#

It's much better to use SSH keys, and this can be a workable system for remote root access as well.īut the problem there is now you've moved from password management to key management, and ssh keys aren't really very manageable. Using passwords at all for SSH is dangerous, since password-sniffing trojaned ssh daemons are put into place in something like 90% of the real-world system compromises I've seen. It's probable that many people were simply setting them to be the same - or worse, setting them to be the same initially and then letting them get out of sync, leaving the root password to rot. On your home system, I think it's really more a matter of the convenience of not having to remember two passwords. With the root password situation described, it's hard to track down who did what - something sudo with remote logging deals with pretty well. Remember that most 'cyber-crime' comes from within.

Even keeping track of what machine has what password is a challenge - let alone tracking who knows which one. That leaves a big vulnerability, since revoking or changing access becomes a big production number. At many organizations, these tend to be passed around like candy, written on whiteboards, and left the same forever. Using sudo to do everything is the most common use I see now, but it's not necessarily the problem the program was meant to solve (hence the ridiculously complicated config file syntax).īut, sudo-for-unrestricted-root does address another security problem: manageability of root passwords. It's important to consider what Sudo was designed for originally: delegation of specific commands (like those to manage printers) to 'sub-administrators' (perhaps grad students in a lab) without giving away root completely. Sudo doesn't protect against that very well at all - if they have your password, after all, no need to try tricking you for later. LD_PRELOAD and PATH attacks like those you describe assume that there is an attacker with access to your account already, or at least to your dotfiles. Just like the proverbial server which is in a safe, unplugged, at the bottom of the ocean, root would be most secure if there were no way to access it at all. Security is always about making trade-offs. But using the above logic wouldn't this be the safest thing to do: What about SSH? Traditionally root can't log in through SSH. So am I missing something? Why did the Ubuntu guys decide to only allow sudo? What can I do to improve the security of any of the methods? Besides that the only problem I see is the lack of timeout. I don't know if programs running on X can intercept ++ (and open a fullscreen window that looks like a console) or it is safe like ++ on Windows. The keypress events can't be intercepted by programs running on X. Since it is started by init if an attacker can control PATH or LD_PRELOAD he is already root. Login on a text-mode console seems to be the safest. Some operations (especially IO redirection) are more convinient with su but security-wise this seems to be worse. I have the same doubts about su but it doesn't even have time limit. The only advantage I can see is the timeout so I never forget to log out.

For example adding aliases, adding stuff to my PATH, setting LD_PRELOAD and X11 keyloggers just to mention a few.

Sudo vs su root code#

There are too many things that can go wrong if an attacker can run code as my normal user. However I am not sure it is any safer than just using login on a text-mode console. On Ubuntu you can only use sudo for 'security reasons' by default.

I would like to have the root account in safety even if my unprivileged user is compromised.