RootSudo
发表于 ： 2005-05-22 22:21
Sudo and the Root Account
In Ubuntu, the traditional UNIX 'root' account is disabled (i.e. it is not possible to log in as root). The reasons for this choice are outlined later in this document.
Quick Answers
To execute commands with root privileges, the command 'sudo' is used in front of each command, e.g.
sudo chown bob *
You will be prompted for your password, which will be stored for 15 minutes. After that time, you will need to enter your password again.
While using Ubuntu you are encouraged to use sudo.
To start a root shell (i.e. a command window where you can run root commands) use:
sudo -s
Warning: sudo -s doesn't change the environment variables ($HOME, $PATH etc). It can have some bad side effects. You can use sudo -i to initialize a full root environment.
To enable the root account (i.e. set a password) use:
sudo passwd root
To disable the root account after you have enabled it use:
sudo passwd -l root
This locks the root account.
To give a graphical application root privileges use either:
gksudo [application]
or
:
kdesu [application]
The kdesu in ubuntu has been patches to use sudo.
Using sudo as opposed to gksudo/kdesu can sometimes lead to file ownership problems.
Benefits of this model
The benefits of leaving root disabled by default include the following.
*
Initially the Ubuntu team wanted the easiest install possible. By not enabling root, a couple of steps requiring user interaction during install could be avoided. (Colin Watson)
*
Even more significantly, if root were enabled during install, the user would be required to forever remember the password they chose--even though they would rarely use it. Root passwords are often forgotten by users who are new to the Unix security model. (Matt Zimmerman)
*
It avoids the "I can do anything" interactive login by default--you will be prompted for a password before major changes can happen, which should make you think about the consequences of what you are doing. If you were logged in as root, you could just delete some of those "useless folders" and not realize you were in the wrong directory until it's too late. It's been good Unix practice for a long time to "su-command-^D" regularly instead of staying in a root shell--unless you're doing serious system maintenance (at which point you can still "sudo su"). (Jim Cheetham and Andrew Sobala)
*
Sudo adds a log entry of the command(s) run (In /var/log/auth.log). If you mess up, you can always go back and see what commands were run. (Andrew Zbikowski)
Security
While there are various advantages and disadvantages to this approach, compared with the traditional superuser model, neither is clearly superior overall.
*
By encouraging the execution of single commands with root privileges, rather than opening a shell, sudo:
o
Reduces the amount of time spent with root privileges, and thus the risk of inadvertently executing a command as root
o
Provides a more useful audit trail
*
Having a separate root password (the traditional model) provides an extra layer of protection if an administrative user's password is compromised
*
In either case, if the administrative user (who uses sudo or su to become root) is compromised, the attacker can generally gain root through an indirect attack
Possible issues with the "sudo" model
Although for desktops the benefits of using sudo are great there are possible issues which need to be noted.
*
Some packages from universe are effectively broken (e.g. webmin) or become dangerous to use. A good workaround is to enable the root account before dealing with the affected packages (sudo su-; passwd <password>) and to lock it again afterwards (su -; passwd -l).
*
Redirecting the output of commands run with sudo can catch new users out (consider "sudo ls > /root/somefile"). Workarounds for this include using "sudo sh -c 'ls > /root/somefile'" (but escaping for this gets very ugly very quickly), using Adverbio, or simply using sudo -s to get a root shell and going from there
o
MattZimmerman: A simple approach which works for most cases is to use dd(1): ls | sudo dd of=/root/somefile
*
In a lot of office environments the ONLY local user on a system is root. All other users are imported using NSS techniques such as nss-ldap. To setup a workstation, or fix it, in the case of a network failure where nss-ldap is broken, root is required. This tends to leave the system unusable unless cracked.
o
JerryHaltom: Perhaps in these cases it neccassitates the creation of a local account: "admin" with sudo to root privledges.
o
LucasVignoliReis?: I think this is a good idea, a sudoer system administration account, and normal user accounts for the other users.
Misconceptions
*
Isn't sudo less secure than su?
o
The basic security model is the same, and therefore these two systems share their primary weaknesses. Any user who uses su or sudo must be considered to be a privileged user. If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so. The user account is the weak link in this chain, and so must be protected with the same care as root. On a more esoteric level, sudo provides some features which encourage different work habits, which can positively impact the security of the system. sudo is commonly used to execute only a single command, while su is generally used to open a shell and execute multiple commands. The sudo approach reduces the likelihood of a root shell being left open indefinitely, and encourages the user to minimize their use of root privileges.
*
I won't be able to enter single-user mode!
o
The sulogin program in Ubuntu is patched to handle the default case of a locked root password.
In Ubuntu, the traditional UNIX 'root' account is disabled (i.e. it is not possible to log in as root). The reasons for this choice are outlined later in this document.
Quick Answers
To execute commands with root privileges, the command 'sudo' is used in front of each command, e.g.
sudo chown bob *
You will be prompted for your password, which will be stored for 15 minutes. After that time, you will need to enter your password again.
While using Ubuntu you are encouraged to use sudo.
To start a root shell (i.e. a command window where you can run root commands) use:
sudo -s
Warning: sudo -s doesn't change the environment variables ($HOME, $PATH etc). It can have some bad side effects. You can use sudo -i to initialize a full root environment.
To enable the root account (i.e. set a password) use:
sudo passwd root
To disable the root account after you have enabled it use:
sudo passwd -l root
This locks the root account.
To give a graphical application root privileges use either:
gksudo [application]
or
:
kdesu [application]
The kdesu in ubuntu has been patches to use sudo.
Using sudo as opposed to gksudo/kdesu can sometimes lead to file ownership problems.
Benefits of this model
The benefits of leaving root disabled by default include the following.
*
Initially the Ubuntu team wanted the easiest install possible. By not enabling root, a couple of steps requiring user interaction during install could be avoided. (Colin Watson)
*
Even more significantly, if root were enabled during install, the user would be required to forever remember the password they chose--even though they would rarely use it. Root passwords are often forgotten by users who are new to the Unix security model. (Matt Zimmerman)
*
It avoids the "I can do anything" interactive login by default--you will be prompted for a password before major changes can happen, which should make you think about the consequences of what you are doing. If you were logged in as root, you could just delete some of those "useless folders" and not realize you were in the wrong directory until it's too late. It's been good Unix practice for a long time to "su-command-^D" regularly instead of staying in a root shell--unless you're doing serious system maintenance (at which point you can still "sudo su"). (Jim Cheetham and Andrew Sobala)
*
Sudo adds a log entry of the command(s) run (In /var/log/auth.log). If you mess up, you can always go back and see what commands were run. (Andrew Zbikowski)
Security
While there are various advantages and disadvantages to this approach, compared with the traditional superuser model, neither is clearly superior overall.
*
By encouraging the execution of single commands with root privileges, rather than opening a shell, sudo:
o
Reduces the amount of time spent with root privileges, and thus the risk of inadvertently executing a command as root
o
Provides a more useful audit trail
*
Having a separate root password (the traditional model) provides an extra layer of protection if an administrative user's password is compromised
*
In either case, if the administrative user (who uses sudo or su to become root) is compromised, the attacker can generally gain root through an indirect attack
Possible issues with the "sudo" model
Although for desktops the benefits of using sudo are great there are possible issues which need to be noted.
*
Some packages from universe are effectively broken (e.g. webmin) or become dangerous to use. A good workaround is to enable the root account before dealing with the affected packages (sudo su-; passwd <password>) and to lock it again afterwards (su -; passwd -l).
*
Redirecting the output of commands run with sudo can catch new users out (consider "sudo ls > /root/somefile"). Workarounds for this include using "sudo sh -c 'ls > /root/somefile'" (but escaping for this gets very ugly very quickly), using Adverbio, or simply using sudo -s to get a root shell and going from there
o
MattZimmerman: A simple approach which works for most cases is to use dd(1): ls | sudo dd of=/root/somefile
*
In a lot of office environments the ONLY local user on a system is root. All other users are imported using NSS techniques such as nss-ldap. To setup a workstation, or fix it, in the case of a network failure where nss-ldap is broken, root is required. This tends to leave the system unusable unless cracked.
o
JerryHaltom: Perhaps in these cases it neccassitates the creation of a local account: "admin" with sudo to root privledges.
o
LucasVignoliReis?: I think this is a good idea, a sudoer system administration account, and normal user accounts for the other users.
Misconceptions
*
Isn't sudo less secure than su?
o
The basic security model is the same, and therefore these two systems share their primary weaknesses. Any user who uses su or sudo must be considered to be a privileged user. If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so. The user account is the weak link in this chain, and so must be protected with the same care as root. On a more esoteric level, sudo provides some features which encourage different work habits, which can positively impact the security of the system. sudo is commonly used to execute only a single command, while su is generally used to open a shell and execute multiple commands. The sudo approach reduces the likelihood of a root shell being left open indefinitely, and encourages the user to minimize their use of root privileges.
*
I won't be able to enter single-user mode!
o
The sulogin program in Ubuntu is patched to handle the default case of a locked root password.
