Chris Tyler - Fedora Linux

User_Alias ADMINS=sally,harry,jason

Host_Alias ADMINDESKTOPS=yellow.fedorabook.com,orange.fedorabook.com

Cmnd_Alias NETCONFIG=ifconfig,route

ADMINS ADMINDESKTOPS=NETCONFIG

The sudo program executes with root privilege. If you view the permissions on the binary, you will see that the set-user-ID permission bit is enabled (note the s in the user community permissions):

$ ls -l /usr/bin/sudo

---s--x--x 2 root root 106832 Feb 12 04:41 /usr/bin/sudo

Since this bit is set and the file is owned by root , it executes with root 's privilege.

sudo checks the /sbin/sudoers file to determine if and how it should run the requested command. It requests a password if necessary, and then either denies execution or changes the effective user ID to the specified value (or leaves it as root ) and executes the requested command.

When the user is prompted forand successfully entersher password, sudo updates a timestamp file in /var/run/sudo . The next time sudo is executed, the timestamp is checked, and if it is less than five minutes old, the user is not prompted for her password again. The timestamp is then updated.

The value of sudo lies in the ability to permit a user to execute specific commands with privilege. However, it's easy to accidentally misconfigure sudo to permit more access than intended.

For example, if you wish to permit frank to view text files owned by jenny , you could create the sudoers entry:

frank ALL=(jenny) NOPASSWD:/usr/bin/less

But the less command permits the user to access the shell by typing !, and frank can use this loophole to execute any command as though he were jenny :

frank$ sudo -u jenny less /home/jenny/.bash_profile

...(Normal output of less)...

!

$ id

uid=508(jenny) gid=508(jenny) groups=508(jenny)

$ mail -s boss@fedorabook.com

Subject: I Quit I quit because you are a hateful, mean boss. -Jenny .

Cc:

Enter

$ rm -rf /home/jenny/*

$ exit

...(Normal output of less)...

It can be useful to configure sudo for ALL commands for users that already have the root password because it encourages good practice, especially when used without the NOPASSWD option. The benefits of this configuration are:

 A user can assume root privilege from time to time only when it is necessary, operating without root privilege the majority of the time. Compared to the use of a root shell, this practice reduces the likelihood that a command will accidentally be executed with privilege.

 If the user steps away from the display while a shell is open, root access is not exposed.

 The user must enter a password to escalate privilege but does not have to enter the password for each individual privileged command in a series.

 The act of typing sudo in front of privileged commands serves to remind the user to check the command carefully.

By default, sudo won't prompt the user for their password as long as they have entered it successfully in the last five minutes. To change this value, add this entry to the top of the /etc/sudoers file:

Defaults timestamp_timeout= 2

The value for this timeout is expressed in minutes.

The user can voluntarily give up the timestamp at any time using the -k option:

$ sudo -k

This is useful if the terminal will be unattended for a while.

The Fedora community has discussed this idea and ultimately opted to keep a root password. Fedora's consolehelper PAM configuration relies on a root password, and using a root password can in some cases provide one additional obstacle to gaining superuser access.

 The manpages for sudo , sudoers , and visudo

Fedora uses the Pluggable Authentication Module (PAM) system to handle user authentication and identity changes. As the name implies, PAM is modular and configurable, enabling you to change the authentication (and authorization) setup on your system without programming.

PAM configuration files are stored in /etc/pam.d , with one file per configured service. Each file is written in plain text and consists of at least three fields separated by spaces. The entries in these files are divided into four categories according to the first field, which identifies the module type . Possible values are:

auth

Authentication configuration (determining who is logging in).

account

Non-authentication-based access control, such as restricting activities by time of day.

password

Password changes or other authentication token updates (such as recording a new retinal scan or fingerprint).

session

Setup of the post-login session and environment.

The entries for a given module type are executed in sequence. For example, when performing authentication, the modules listed on the auth lines are executed in sequence.

The second field in each entry is called the control flag and determines the action taken when the module succeeds or fails. Possible values are:

required

The module must succeed for the module type to succeed. Regardless of whether the module fails or succeeds, processing will continue with the next line (other modules of the same module type will be executed), but at the end of all of the processing, a failure will be recorded.

requisite

The module must succeed for the module type to succeed. If it fails, processing stops immediately. If it succeeds, processing continues with the next line.

sufficient

If the module succeeds, then the module type succeeds and processing stops immediately. If it fails, processing continues with the next line.

optional

The module is executed, but the failure or success of the module is ignored.

include

In place of a module name, another configuration file is given. All of the lines of the same type from that configuration file are treated as if they were present in this configuration file.

It is also possible to use a complex expression as a control flag, but this feature is not used in the default Fedora Core configuration.

The remaining fields on the line contain the name of the module and any arguments to it (except when the control flag is include , in which case the third argument is the included file).

Here's an example. This is the content of /etc/pam.d/sshd , the configuration file for the SSH server daemon: