• Some commands, such as those that add new users, partition hard drives, and change system configuration, can be executed only by root. Superuser can use certain tools, such as sudo, to give specific users permission to perform tasks that are normally reserved for Superuser.
• Read, write, and execute file access and directory access permissions do not affect root: Superuser can read from, write to, and execute all files, as well as examine and work in all directories.
• Some restrictions and safeguards that are built into some commands do not apply to root. For example, root can change any user’s password without knowing the old password.
When you are running with root (Superuser) privileges, the shell by convention displays a special prompt to remind you of your status. By default, this prompt is or ends with a pound sign (#).
When you are working on the computer, especially when you are working as the system administrator, perform any task while using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, log in or use su so you have root privileges, complete the part of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can. Because you are more likely to make a mistake when you are rushing, this concept becomes more important when you have less time to apply it.
You can gain or grant Superuser privileges in a number of ways:
1. When you bring the system up in single-user mode, you are Superuser.
2. Once the system is up and running in multiuser mode, you can log in as root. When you supply the proper password, you will be Superuser.
3. You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, you will have Superuser privileges.
4. You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. The sudo utility is controlled by the /etc/sudoers file, which must be set up by root. Refer to the sudo man page for more information.
5. Any user can create a setuid (set user ID) file. Setuid programs run on behalf of the owner of the file and have all the access privileges that the owner has. While you are running as Superuser, you can change the permissions of a file owned by root to setuid. When an ordinary user executes a file that is owned by root and has setuid permissions, the program has full root privileges. In other words, the program can do anything root can do and that the program does or allows the user to do. The user’s privileges do not change. When the program finishes running, all user privileges revert to the way they were before the program started. Setuid programs that are owned by root are both extremely powerful and extremely dangerous to system security, which is why a system contains very few of them. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for Superuser to give a program setuid privileges:
# ls -l my*
-rwxr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwxr-xr-x 1 root other 24152 Apr 29 16:31 myprog2
# chmod 4755 myprog
# chmod u+s myprog2
# ls -l my*
-rwsr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwsr-xr-x 1 root other 24152 Apr 29 16:31 myprog2
The s in the owner execute position of the ls -l output (page 203) indicates that the file has setuid permission.
6. Some programs ask you for a password (either your password or the root password, depending on the particular command and the configuration of the system) when they start. When you provide the root password, the program runs with root privileges. When a program requests the root password when it starts, you stop running as the privileged user when you quit using the program. This setup keeps you from remaining logged in as Superuser when you do not need or intend to do so.
Some techniques limit the number of ways to become Superuser. For example, PAM controls the who, when, and how of logging in. The /etc/securetty file controls which terminals (ttys) a user can log in on as root. The /etc/security/access.conf file adds another dimension to login control (see the file for details).
root-owned setuid programs are extremely dangerous
Because root-owned setuid programs allow someone who does not know the root password to exercise the powers of Superuser, they are tempting targets for a malicious user. A system should have as few of these programs as possible. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option. You can also use SELinux to disable setuid programs.
Do not allow root access over the Internet
Prohibiting root logins using login over a network is the default policy of Fedora/RHEL and is implemented by the PAM securetty module. The /etc/security/access.conf file must contain the names of all users and terminals/workstations that you want a user to be able to log in on as root. Initially every line in access.conf is commented out.
You can, however, log in as root over a network using ssh. As shipped by Fedora/RHEL, ssh does not follow the instructions in securetty or access.conf. Also, in /etc/ssh/sshd_config, Fedora/RHEL sets PermitRootLogin to YES (it is set by default) to permit root to log in using ssh.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
No comments:
Post a Comment