How do you do your sysadmin work?
Submitted by emeitner on Wed 15 Feb 2006
| Login as root |
   17% | 309 votes |
| 'su' to root when needed |
53% | 977 votes |
| 'sudo' when needed |
27% | 508 votes |
| Other |
1% | 22 votes |
| Total 1816 votes |
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I find using sudo the simplest since I often look after a whole bunch of machines and find it hard to sometimes remember the root passwords!
Logging in with SSH keys and knowing my own password on a collection of hosts is much simpler. (And I'd usually disallow ssh logins for root anyway.)
(The passwords for root are all written down and stored away safely, and being generated via a perl script they are not often easy to recall.)
[ Parent ]
[ Parent ]
Firstly, the ability for user-passwords to achieve root level system control (in the vast majority of sudo installations) seems to weaken the security for user priveledge seperation. In large numbers of installations (and increasing!) the main user seems to be able to become root for any command with their own password, and in some cases no password at all. Two passwords to achieve root seems a useful security barrier and I'm not sure why it's being circumvented.
While sudo theoretically has the power to apportion administrative tasks in a finer granularity than 'root or nothing' as is traditional, it does so through a confusing and somewhat inappropriate configfile format. It tries to achieve high amounts of flexibility by allowing for the creation of classes of users and actions, but does so via variables or names, instead of syntactical elements, making it difficult to review. Additionally, a sudo config line may contain as many as four elements, which are not clearly labelled or intentioned, as in the classic
user ALL = (ALL) ALL
Next, sudo's seeming primary purpose, of constraining per-user or user grouping abilities to specific elevated-priveledge actions is fraught with danger. It is very easy to allow users to achieve general root from poorly constrained command patterns. Fewer modern commands are willing to execute commands on behalf of users so this type of problem is smaller than it is in the past, but in general sudo does not offer good assistance in creating safe strings or identifying likely problems. In deployed environments I have worked in /etc/sudoers has been found to contain practical weaknesses in the majority of cases. This is what really started me down the path of hating sudo.
Lastly there is the checkered past of a larger number of security problems being identified in sudo than roughly equivalent tools such as su. Some of this can probably be attributed to its unnecessary complexity (mocking the user for errors is really not important functionality), but I believe the maintenance and/or design of the tool is just sub-par.
[ Parent ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
It is definitely the case that poorly written configuration file entries can completely compromise the security of a host, and this is something to be aware of.
However that said I've found it a useful way of delegating authority to users - allowing them to restart a webserver when working on a fastCGI process, for example. That kind of thing is good for users and good for the admin.
Even if you enable "ALL ALL" in the file you still get a good audit trail by default of all the commands executed. If you're working with other people then it is a good idea to review these logs, or store them in a central location where they cannot be tampered with.
Personally I think that there is no inherant security weakening if you force the user to enter their password. It is difficult to protect against the NOPASSWD option if a users account is compromised - and the use of sudo can be inferred from the shell history, etc.
Still I think there is a fair bit of truth to what you say, but the benefits for me outweigh the risks.
[ Parent ]
It has the disadvantage of no longer being maintained.
[ Parent ]
[ Parent ]
I left Ubuntu in favor of Debian, and one of my issues was to have to sudo everything. I will occasionally su into root, but that's not often any more. I like the clear distinction that the root console window is in KDE, its bright yellow background makes it very clear to recognize.
Rob
[ Parent ]
sudo -swhen you realize you need to do a few more tasks...
[ Parent ]
I my be pessamistic, but hopefully I'm locked down tight :P
V.
[ Parent ]
I'm unsure whether it strictly meets what you qualify as "other".. In sessions where I know I will need the almighty root I tend to run an su and background it (the shell `suspend` command) between root commands. Means I'm not at a dangerous shell except when needed, but leaves it handy when I need it back. Things like the yellow-background terminal window are roughly equivalent to this.
For large networks, you tend to SSH in as root from your administrative system. Nothing else is really practical when doing scripts on >100 hosts. There is also the issue that you cannot get partially pregnant, once you've got any root, you've really got it all.
[ Parent ]