Chris Tyler - Fedora Linux

#

mv foo baz

#

rm baz

# ls baz

ls: baz: No such file or directory

The immutable capability is provided by the ext2/ext3 filesystems. Each file has an immutable flag that is part of the ext2/ext3 file attributes; when set, the ext2/ext3 code in the kernel will refuse to change the ownership, group, name, or permissions of the file, and will not permit writing, appending, or truncation of the file.

By making configuration files and programs immutable, you can provide a small measure of protection against change. This can be used to guard against accidental changes to configuration files. It can also prevent a program from being subverted to change files it should not; although SELinux provides similar protection, you may add software to your system that is not covered by the SELinux targeted policy.

Do not attempt to upgrade or remove software packages if you've made any of the files belonging to those packages immutable! Doing so may render your system unusable. Be particularly careful if you are using immutable files on a system that has automatic yum updates enabled.

The -R option to chattr causes it to operate recursively over all of the files and subdirectories within a directory:

# chattr -R +i /etc

Although a number of file attributes have been defined for ext2/ext3 filesystems, very few of the interesting ones have been implemented! For example, attributes have been defined to enable per-file automatic data compression, automatic zeroing (enhanced security erasure) of deleted files, and save-for-undeletion, but none of those features have been implemented so far.

But there is one other attribute that is occasionally useful: the append-only attribute, a . When applied to a file by chattr , this attribute provides all of the protection of the immutable attribute, except that it remains possible to append data to the file. This is ideal for logfiles, because it makes it impossible to alter or erase data that has been placed in the logfile.

 The manpages for chattr and lsattr

Sometimes it's useful to delegate superuser privilege to a Fedora user; however, giving him the superuser password gives him total control of the system. The sudo system enables superuser privilege to be delegated on a program-by-program basis.

There are two parts to sudo : the /etc/sudoers file, which controls who can do what, and the sudo command, which enables authorized users to run commands with superuser privilege.

To configure /etc/sudoers , use the visudo utility, which will start vi so that you can edit the file. When you are done, it checks the syntax before installing it. If there is a syntax error, visudo will prompt you for a course of action; to see the available options, enter a question mark:

# visudo

>>> sudoers file: syntax error, line 17 <<<

What now? ?

Options are:

(e)dit sudoers file again

e(x)it without saving changes to sudoers file

(Q)uit and save changes to sudoers file (DANGER!)

What now? x

To enable the user chris to run the netstat and ifconfig commands as the superuser, add this entry to the sudoers file:

chris ALL=/bin/netstat,/sbin/ifconfig

This entry contains the username, the computers (in this case, ALL ) on which this user can execute this command (useful if the sudoers file is shared among several machines, either through a file-sharing protocol or by copying the file), and a list of commands that may be executed as root .

Be careful selecting the commands to include in the list: if any of the commands permit access to the shell, the user will be able to execute anything!

Once this change has been made, the user chris can use sudo to execute the netstat command using the -p option (which requires superuser privilege to operate correctly):

chris@bluesky$ sudo netstat -ap

Password:

bigsecret

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 *:sunrpc *:* LISTEN 1488/portmap

tcp 0 0 laptop3:smtp *:* LISTEN 1724/sendmail

tcp 0 0 laptop3:x11-ssh-offset *:* LISTEN 20494/2

tcp 0 0 *:42365 *:* LISTEN 507/rpc.statd

tcp 0 0 *:http *:* LISTEN 21393/httpd

...(Lines snipped)...

Notice that a password is requested; this is the user's password, not the root password.

The user can also execute ifconfig :

$ sudo /sbin/ifconfig eth2 down

The full pathname of the command ( /sbin/ifconfig ) is required because /sbin is not in the user's normal search path.

It is reasonable idea to add /sbin and /usr/sbin to everyone's search path, since it makes both sudo and su more useful and provides easy access to the nonprivileged modes of the administration utilities.

This time, no password is requested because it's been less than five minutes since the last time sudo asked for the user's password. To disable the password request entirely, add the keyword NOPASSWD: after the equal sign in the sudoers entry:

chris ALL=NOPASSWD:/bin/netstat,/sbin/ifconfig

By default, sudo enables the execution of the listed commands as root ; to enable execution as another user, place that user's name in parentheses after the equal sign in the configuration entry. For example, to permit chris to run the script /usr/local/bin/checkstatus as the user scott :

chris ALL=(scott) NOPASSWD:/usr/local/bin/checkstatus

chris can then use sudo with the -u option to specify the desired user ID:

$ sudo -u scott checkstatus

Replacing the command list with the word ALL will include all commands. For example, this entry permits chris to execute any command or script as root :

chris ALL=ALL

Permitting unrestricted access to all commands through sudo is equivalent to giving away the root password. A root user can compromise the system at very basic levels, making it impossible to later secure the system, even if you cut off that user's access.

For convenience, you can define groups of users, hosts, or commands and then reference those in entries. This is done by using the User_Alias , Host_Alias , and Cmnd_Alias statements.

For example, to define a group of administrators and permit them to run the ifconfig and route commands as root on any of a group of desktop systems, you could use a configuration file like this: