System security maintenance is an essential task when running a computer, but it's never been particularly glamorous or fun. The basic goal of system security is to ensure that the system provides the services it is supposed to provide, cannot be subverted to do things it was not intended to do, and to ensure that the services remain available for use.
Effective security requires a multipronged approach, and Fedora provides effective tools to secure your system in several different ways:
Filtering of network traffic
System activity logging and automatic monitoring tools
Discretionary access controls such as permissions and access control lists
Mandatory access controls through SELinux
Intrusion-detection tools and immutable file attributes to detect and prevent file alteration
Tools to delegate specific system administration privileges to different users
Together with automated software updates, these tools enable you to efficiently maintain your system security.
Most Fedora systems are connected to a TCP/IP network. You can guard against unwanted inbound connections to your system by using the built-in firewall.
To adjust the Fedora firewall graphically, select the menu option System→Administration→"Security Level and Firewall." After you enter the root password, the window shown in Figure 8-1 will appear.
Figure 8-1. Firewall configuration tool
The control at the top of this window enables and disables the firewall. When the firewall is enabled, the lower portion of this window can be used to permit connections to your system for selected services; simply select the checkboxes for the desired services. SSH should remain selected to permit secure remote administration.
To permit connections to services that are not listed, click on the triangle for "Other ports." The display will change to reveal an additional section, as shown in Figure 8-2 .
Figure 8-2. Configuring other ports
To add additional ports, click the Add button, and the window shown on the right side of Figure 8-2 will pop up. Enter the port number or the service name, select TCP or UDP for the protocol, and click OK.
A list of most of the common services and their corresponding port numbers can be found in the file /etc/services.
When the firewall is configured to your liking, click OK.
Enter this command:
# lokkit
The screen displayed in Figure 8-3 will appear. Use the Tab key to navigate among fields, the spacebar to select and deselect checkboxes, and Enter or the spacebar to activate buttons.
Figure 8-3. Lokkit firewall configuration screen
Enable or disable the firewall using the checkboxes. To customize the types of connections that are permitted through the firewall, tab to the Customize button and press Enter. The customization screen shown in Figure 8-4 will appear.
Figure 8-4. Lokkit firewall customization screen
The Trusted Devices and MASQUERADE Devices checkboxes are applicable only to systems with multiple network connections. Do not select either of those options on a system with a single network interface.
The Trusted Devices checkbox will disable firewall protection for the selected interface!
Use the Allow Incoming checkboxes to select the services that will be permitted to connect to your system through the firewall. In almost all cases, SSH should be selected to permit secure remote connections for system administration.
To allow incoming connections to services that are not listed, enter the port number or service, followed by a colon (:), and the protocol (TCP or UDP) into the "Other ports" field at the bottom of the screen. You will need to separate multiple entries with a space or comma. For example, to permit incoming connections to the VNC service as well as to a custom UDP service running on port 64447, use:
vnc:tcp 64447:udp
Select OK to return to the main screen ( Figure 8-3 ); select OK on that screen to save your settings and exit.
To disable the firewall until the next reboot, stop the iptables service:
# service iptables stop
To reset your firewall to the configured settings, restart the iptables service:
# service iptables restart
The Fedora firewall uses the kernel's iptables capability, which can filter packets based on their source, destination, port, protocol, contents, and current connection state.
To view the current iptables configuration, use the -L option:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT ipv6-crypt-- anywhere anywhere
ACCEPT ipv6-auth-- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
There are four chains of rules defined here:
INPUT
Filters packets that are inbound to this system.
FORWARD
Filters packets that are passing through the system. This applies only if there is more than one network interface and IP forwarding is turned on to pass packets between the interfaces (for example, in a system serving as a router).
OUTPUT
Filters packets that are outbound from this system.
RH-Firewall-1-INPUT
This is the chain of rules configured by the firewall system. Notice that this chain is included into the chains for INPUT and FORWARD.
In this example, IPP (Internet Print Protocol, used by CUPS), MDNS (multicast DNS, used by Avahi), and SSH connections are all permitted; only SSH was configured for the firewall, demonstrating that not all services are configured through the firewall configuration tools.
Since the policy for each chain is ACCEPT, flushing (clearing) the rules will result in all packets being accepted. This is exactly what the iptables -F command does, which is executed when the iptables service is stopped.
The graphical firewall configuration tool is system-config-securitylevel (which, in recent versions, also handles SELinux configuration). The character-based version is system-config-securitylevel-tui , which is also known as lokkit . Both of these tools save the firewall configuration in /etc/sysconfig/system-config-securitylevel and, from that configuration, derive a set of iptables rules that are saved in /etc/sysconfig/iptables . That file, in turn, is used by the iptables service ( /etc/init.d/iptables ) to configure the firewall; options that control the operation of the iptables service are stored in /etc/sysconfig/iptables-config .
iptables is actually an unusual service. Most other servicessuch as cups , httpd , or gpm have a server process that begins running when the service is started and that is stopped when the service is stopped; iptables , on the other hand, just configures the iptables facility in the kernel when the service is started or stopped, so there's no actual process running when the firewall is active.
The firewall interface provided by Fedora's system-config-securitylevel supports only the filtering of inbound (and forwarded) packets and is quite simple. However, the iptables mechanism supports much more complex filtering. Fedora Extras provides several alternate tools for firewall configuration, including firestarter , fwbuilder , and shorewall .
The manpages for iptables
The home page for iptables at http://netfilter.org
Security Enhanced Linux (SELinux) is installed and enabled by default in Fedora Core. SELinux controls what a program is and is not allowed to do, enforcing security policy through the kernel. This prevents an attacker from using a compromised program to do something it was not intended to do.
Although SELinux can at times be challenging to configure, it dramatically improves protection against some common system attacksso a little bit of effort can pay off in a big way.
SELinux is managed using the same graphical tool used to manage the firewall. Click System→Administration→"Security Level and Firewall" to start it, then select the SELinux tab, shown in Figure 8-5.
Figure 8-5. Graphical configuration tool for SELinux
There are three possible values for SELinux Setting:
Enforcing
Fully enables SELinux. Any attempted operation that violates the current security policy is blocked.
Permissive
Enables SELinux security checks but does not enforce the security policy; operations that violate the current security policy are permitted, but an error message is logged to record the event. This is useful if you have previously disabled SELinux and want to evaluate the potential impact before you enable it.
Disabled
Completely disables SELinux.
If you enable SELinux (using Enforcing or Permissive mode), expand the Modify SELinux Policy section by clicking the triangle. The SELinux policy configuration categories will appear, as shown in Figure 8-6 .
Figure 8-6. SELinux policy configuration categories
Each of these categories contains a number of options (represented as checkboxes) called booleans . Each boolean may be set on (checked) or off (unchecked).
To expand the options in any category, click on the arrow in front of that category. In Figure 8-6 , the Admin category has been expanded, and the window width has been resized to fully show each option.
After selecting or deselecting booleans as desired, click OK. Changes in boolean values will take effect immediately, but changing the SELinux setting to or from Disabled will take effect only when the system is booted.
SELinux can also be configured very easily from the command line. To enable SELinux, edit the file /etc/selinux/config and set the SELINUX value to enforcing , permissive , or disabled :
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
Changes made to this file will take effect when the system is booted. If SELinux is enabled, you can use the getenforce command to view the current mode, and you can use the setenforce command to immediately switch between enforcing and permissive modes:
# getenforce
Enforcing
# setenforce permissive
# getenforce
Permissive
# setenforce enforcing
# getenforce
Enforcing
Boolean valuescorresponding to the checkboxes in the graphical Security Level configuration toolcan be viewed with the getsebool command, using the -a option to see all values:
$ getsebool -a
NetworkManager_disable_trans --> off
allow_cvs_read_shadow --> off
allow_execheap --> off
allow_execmem --> on
...(Lines snipped)...
ypserv_disable_trans --> off
ypxfr_disable_trans --> off
zebra_disable_trans --> off
You can also specify a specific boolean:
$ /usr/sbin/getsebool httpd_enable_cgi
httpd_enable_cgi --> on
To temporarily set a boolean value, use the setsebool command:
# setsebool httpd_enable_cgi 1
# setsebool httpd_enable_homedirs=0
Notice that the on/off state of the boolean is expressed numerically, with 1 representing on and 0 representing off. Also note that the boolean name and value may be specified as two arguments (first example), or they may be specified as a single argument, joined with the = symbol (second example). If you use the second form, you can set multiple booleans with one command:
# setsebool httpd_enable_cgi=1 httpd_enable_homedirs=0
Changes made to boolean values with setsebool take effect immediately but are not permanent; they will reset at the next boot. To make them permanent, add the -P argument:
# setsebool -P httpd_enable_cgi=1
The default boolean settings for SELinux are reasonable for most systems, but they may need to be changed to relax the security policy for specific applications.
For example, by default, web scripts are not permitted to communicate through the network; this prevents an untrusted script from somehow transferring private data to another host. But if your web scripts need to connect to an IMAP email server or an SQL database such as MySQL or PostgreSQL, you'll need to set the appropriate boolean.
In this case, you can find the boolean in the graphical interface by expanding the HTTPD Service category and looking through the options. Select the checkbox for the boolean labeled "Allow HTTPD scripts and modules to connect to the network."
There is also a manpage provided for each of the most popular servers protected by SELinux. These manpages are named service _selinux ; for example, to access a description of the SELinux booleans that affect httpd , view the httpd_selinux manpage:
$ man httpd_selinux
To see a list of all the service-specific manpages for SELinux, enter the command:
$ apropos _selinux
In the BOOLEAN section you will find this text:
httpd scripts by default are not allowed to connect out to the network.
This would prevent a hacker from breaking into you httpd server
and attacking other machines. If you need scripts to be able to
connect you can set the httpd_can_network_connect boolean on.
setsebool -P httpd_can_network_connect 1
To translate between the descriptions shown in the graphical Security Level Configuration tool and the boolean names used by setsebool and getsebool , use the file /usr/share/system-config-securitylevel/selinux.tbl , which looks like this:
unlimitedUtils _("Admin") _("Allow privileged utilities like hotplug and insmod to run unconfined.")
unlimitedRC _("Admin") _("Allow rc scripts to run unconfined, including any daemon started by an rc script that does not have a domain transition explicitly defined.")
unlimitedRPM _("Admin") _("Allow rpm to run unconfined.")
staff_read_sysadm_file _("Admin") _("Allow staff_r users to search the sysadm home dir and read files (such as ~/.bashrc)")
direct_sysadm_daemon _("Admin") _("Allow sysadm_t to directly start daemons")
...(Lines snipped)...
Each line consists of the boolean name used by setsebool / getsebool , followed by the configuration category and the description used by the Security Level Configuration tool.
Use grep with a server name, boolean name, or a description from the configuration tool to quickly find values in this file:
$ cd /usr/share/system-config-securitylevel
$ grep httpd selinux.tbl
httpd_enable_cgi _("HTTPD Service") _("Allow HTTPD cgi support")
httpd_can_network_connect _("HTTPD Service") _("Allow HTTPD scripts and modules to connect to the network.")
httpd_enable_homedirs _("HTTPD Service") _("Allow HTTPD to read home directories")
httpd_ssi_exec _("HTTPD Service") _("Allow HTTPD to run SSI executables in the same domain as system CGI scripts.")
httpd_builtin_scripting _("HTTPD Service") _("Allow HTTPD to support built-in scripting")
httpd_disable_trans _("HTTPD Service") _("Disable SELinux protection for httpd daemon")
httpd_suexec_disable_trans _("HTTPD Service") _("Disable SELinux protection for http suexec")
httpd_unified _("HTTPD Service") _("Unify HTTPD handling of all content files.")
httpd_tty_comm _("HTTPD Service") _("Unify HTTPD to communicate with the terminal. Needed for handling certificates.")
$ grep "Allow ftp to read/write files in the user home directories" selinux.tbl
ftp_home_dir _("FTP") _("Allow ftp to read/write files in the user home directories")
$ grep unlimitedRPM selinux.tbl
unlimitedRPM _("Admin") _("Allow rpm to run unconfined.")
Table 8-1 contains some of the most commonly altered SELinux booleans.
Table 8-1. Commonly altered SELinux booleans
| Boolean name | Description in system-config-securitylevel | Reason for altering | Default value |
|---|---|---|---|
| allow_ptrace | Allow sysadm_t to debug or ptrace applications. | Permit root to use tools such as gdb for debugging. | Off |
| allow_execmod | Allow the use of shared libraries with Text Relocation. | Required to use Adobe Flash browser plug-in and Sun Java. | Off |
| allow_ftp_anon_write | Permits the FTP server to write to files labeled with type public_content_rw_t, described in Table 8-2. | Off | |
| httpd_can_network_connect | Allow httpd scripts and modules to connect to the network. | Enables web scripts to connect to databases and mail servers. | Off |
| httpd_enable_homedirs | Allow httpd to read home directories. | Enables the use of ~/public_html for personal web pages. | Off |
| httpd_tty_comm | Unify httpd to communicate with the terminal. Needed for handling certificates. | Enables the use of certificates with passphrases (requires the passphrase to be entered on the terminal). | Off |
| allow_httpd_anon_write | Permits Apache to write to files labeled with type public_content_rw_t (see Table 8-2). | Off | |
| named_write_master_zones | Allow named to overwrite master zone files. | Required for dhcpd updating of zones. | Off |
| nfs_export_all_ro | Allow reading on any NFS filesystem. | Enables NFS file sharing (read-only). | Off |
| nfs_export_all_rw | Allow read/write/create on any NFS filesystem. | Enables NFS file sharing (read/write). | Off |
| use_nfs_home_dirs | Support NFS home directories. | Allows home directories (such as /home/chris) to be imported from an NFS server. | Off |
| samba_enable_home_dirs | Allow Samba to share users' home directories. | Allows homes shares in smb.conf. | Off |
| use_samba_home_dirs | Allow users to log in with CIFS home directories. | Allows home directories (such as /home/chris) to be imported from a Samba or Windows server. | Off |
| allow_samba_anon_write | Permits Samba to write to files labeled with type public_content_rw_t. | Off | |
| spamassasin_can_network | Allow Spam Assassin daemon network access. | Enables the use of real-time blackhole lists (RBLs) by Spam Assassin. | Off |
| ssh_sysadm_login | Allow SSH logins as sysadm_r:sysadm_t. | Allows root login via SSH (otherwise, you'll need to log in as a regular user and then use su). This may be required if you're running remote backups via SSH. | Off |
| subsystem_disable_trans | Disable SELinux protection for subsystem. | Use this as a last alternative. It's better to disable SELinux protection for one subsystem than to turn it off entirely. | Off |
SELinux uses file labels to specify an SELinux context for each file. To display the context labels, use the -Z or --context options to ls :
$ ls -Z /etc
-rw-r--r-- root root system_u:object_r:etc_t a2ps.cfg
-rw-r--r-- root root system_u:object_r:etc_t a2ps-site.cfg
drwxr-xr-x root root system_u:object_r:etc_t acpi
-rw-r--r-- root root system_u:object_r:adjtime_t adjtime
drwxr-xr-x root root system_u:object_r:etc_t alchemist
-rw-r--r-- root root system_u:object_r:etc_aliases_t aliases
-rw-r----- root smmsp system_u:object_r:etc_aliases_t aliases.db
drwxr-xr-x root root system_u:object_r:etc_t alsa
drwxr-xr-x root root system_u:object_r:etc_t alternatives
-rw-r--r-- root root system_u:object_r:etc_t anacrontab
-rw------- root root system_u:object_r:etc_t at.deny
-rw-r--r-- root root system_u:object_r:automount_etc_t auto.master
-rw-r--r-- root root system_u:object_r:automount_etc_t auto.misc
-rwxr-xr-x root root system_u:object_r:automount_etc_t auto.net
-rwxr-xr-x root root system_u:object_r:automount_etc_t auto.smb
...(Lines snipped)...
The context label displayed on each line contains the text system_u:object_r: followed by the file type assigned to the file. In the output above, the aliases file has been given the file type etc_aliases_t (which is unique to that file), indicating that the SELinux policy treats that file specially.
All file types end in _t for easy identification.
Files contained in your home directory are usually given the type user_home_t . The default policy will not permit web pages in ~/public_html to be accessed through the web server, even if the httpd_enable_homedirs boolean is turned on, unless the files being shared have the type httpd_sys_content_t . To change file contexts, use the chcon command:
$ chcon -R -t httpd_sys_content_t ~/public_html
The -R option causes chcon to recursively change the context of directories within ~/public_html , and -t httpd_sys_content_t sets the file type.
The file context types most commonly used with chcon are shown in Table 8-2 .
Table 8-2. Common nondefault file context types
| Type | Description | Examples |
|---|---|---|
| httpd_sys_content_t | Files that may be served by httpd | Web pages, graphics, CSS files, client-side ECMAScript/JavaScript |
| httpd_sys_script_exec_t | CGI scripts that may be executed by httpd | Web scripts written in any external scripting language (e.g., scripts written in Perl when you are not using mod_perl) |
| httpd_unconfined_script_exec_t | CGI scripts that will not be constrained by SELinux | Dangerous!but may be required for some complex CGI scripts |
| httpd_sys_script_ro_t | Datafiles that may be read (but not written) by CGI scripts | Static CGI script datafiles |
| httpd_sys_script_ra_t | Datafiles that may be read and appended (but not overwritten or truncated) by CGI scripts | Script logfiles, guestbooks, nonrevisable order queues, survey and quiz records |
| httpd_sys_script_rw_t | Datafiles that may be read/written by CGI scripts | User profiles, session status, and other CGI datafiles |
| samba_share_t | Enables sharing of the file by Samba (not required for home directories) | Group Samba shares |
| public_content_t | Enables sharing of the file (read only) by Samba, httpd, NFS, and rsync | Files shared by multiple servers |
| public_content_rw_t | Enables sharing of the file (read/write) by Samba, httpd, FTP, and rsync | Files shared and updatable through multiple servers |
A file label that has been changed manually may be changed back to the default value during a relabeling (discussed in the next section).
For example, if you have created the /var/samba directory and are using it for Samba group shares, it will need to be labeled with the type samba_share_t :
# chcon -R -t samba_share_t /var/samba
To make that the default context label for /var/samba , edit /etc/selinux/targeted/contexts/files/file_contexts.local to contain this line:
/var/samba(/.*)? system_u:object_r:samba_share_t
The first field contains a regular expression specifying that this entry will match any filename starting with /var/samba . The context label in the second field (which must include the system_u:object_r: portion) configures the default label for files that match the regular expression.
Some caution is in order: you may end up with a system where many file labels are wrong if you update your SELinux policy, mount your filesystems without SELinux support enabled (perhaps during rescue mode), or go wild with chcon . To relabel your system, you should create the empty file /.autorelabel and then boot the system:
# touch /.autorelabel
# shutdown -r now
During system startup, your files will be relabeled to default values, except for files labeled with a type listed in /etc/selinux/targeted/contexts/customizable_types . The relabeling operation will typically take a few minutes on a desktop system or small server, and could take much longer on a large server or very old computer.
SELinux policy messages are sent to syslog and usually end up in /var/log/messages . To find them among the other messages, search for the string avc :
# grep avc: /var/log/messages
May 2 16:32:56 laptop3 kernel: audit(1146601976.667:289): avc:
denied { getattr } for pid=23807 comm="httpd" name="public_html" dev=dm-1
ino=192237 scontext=user_u:system_r:httpd_t:s0
tcontext=user_u:object_r:user_home_t:s0 tclass=dir
Here we see that an access request was denied between a subject with an scontext of user_u:system_r:httpd_t:s0 and a tcontext of user_u:object_r:user_home_t:s0 for the tclass dir (a filesystem directory). The additional fields provide a bit more information: the attempted operation was getattr (get attributes), the process ID of the subject was 23807, the command executing was httpd , the directory name was public_html , the storage device was dm-1 , and the inode number was 192237.
The fact that the storage device name starts with dm (which stands for device mapper ) indicates that the directory is stored in a logical volume. You can find the device number from a detailed listing of the device node:
$ ls -l /dev/dm-1
brw-r----- 1 root disk 253, 1 Apr 29 08:57 /dev/dm-1
The output indicates that the device number is 253, 1 . Compare this with the device nodes in /dev/mapper :
$ ls -l /dev/mapper
total 0
crw------- 1 root root 10, 63 Apr 29 08:57 control
brw-rw---- 1 root disk 253, 1 Apr 29 08:57 main-home
brw-rw---- 1 root disk 253, 3 Apr 29 08:57 main-remote
brw-rw---- 1 root disk 253, 0 Apr 29 08:57 main-root
brw-rw---- 1 root disk 253, 4 Apr 29 08:57 main-test
brw-rw---- 1 root disk 253, 2 Apr 29 08:57 main-var
According to this output, /dev/dm-1 corresponds to /dev/mapper/main-home , which refers to the logical volume home within the volume group main . The mount command shows the mount point for this volume:
$ mount
/dev/mapper/main-root on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hdc2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/main-home on /home type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid10695) on /net type autofs (rw,fd=4,pgrp=10695,minproto=2,maxproto=4)
We know that the directory filename is public_html , but we don't know the full pathname of the directory. Passing the mount point and inode number to find will reveal the pathname:
# find /home -xdev -inum 192237
/home/chris/public_html
The -xdev argument limits the search to a single filesystem.
So now we know that httpd (Apache) was unable to access the directory /home/chris/public_html .
The command audit2why will attempt to decode SELinux error messages:
# grep avc: /var/log/messages|audit2why
May 2 16:32:56 laptop3 kernel: audit(1146601976.667:289): avc: denied { getattr } for pid=23807 comm="httpd" name="public_html" dev=dm-1 ino=192237 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=dir
Was caused by:
Missing or disabled TE allow rule.
Allow rules may exist but be disabled by boolean settings; check boolean settings.
You can see the necessary allow rules by running audit2allow with this audit message as input.
This explanation is not very informative, but it does tell us that there is no type enforcement rule to allow this access, and that may be because of a boolean setting. Viewing the manpage for httpd_selinux gives information about the necessary boolean setting, along with the required context label:
httpd by default is not allowed to access users home directories. If you want to allow access to users home directories you need to set the httpd_enable_homedirs boolean and change the context of the files that you want people to access off the home dir.
setsebool -P httpd_enable_homedirs 1
chcon -R -t httpd_sys_content_t ~user/public_html
Issuing the commands given in the manpage fixes the problem. Here I've substituted the actual user's name into the chcon argument:
# setsebool -P httpd_enable_homedirs
# chcon -R -t httpd_sys_content_t ~chris /public_html
Fedora Core 6 includes the first release of the setroubleshoot tool, which provides a desktop notification of AVC denials as well as a GUI program for analyzing AVC messages. To use this tool, install the setroubleshoot package.
The Linux kernel provides the Linux Security Module (LSM) interface to enable additional access controls to be added to operations. These interfaces provide connections, or hooks , into the system call code used by processes to request that the kernel perform an operation, such as opening a file, sending a signal to another process, or binding to a network socket.
SELinux uses these hooks to permit or deny requests made by a process ( subject ) on a resource (such as a file, network socket, or another process, called an object ). These controls are called mandatory access controls (MAC) because they enforce a consistent security policy across the entire system. This stands in contrast to the traditional Unix/Linux file permissions, which are considered discretionary access controls (DAC) because the access settings are left to each user's discretion.
SELinux does not override permissions; access to a resource must be permitted by all security mechanismsincluding SELinux, permission modes, ACLs, mount options, and filesystem attributesbefore it will be granted.
An SELinux policy defines the rules used to make each access decision. There are three inputs into each decision: the security context of the source subject, and the security context and class of the target object.
Each security context consists of four parts: a user , a role , a type , and a sensitivity . In order to track this information, SELinux assigns a label to each subject and object.
You can view the context of processes by using the -Z (or --context ) argument with the ps command:
$ ps -e -Z
LABEL PID TTY TIME CMD
system_u:system_r:init_t 1 ? 00:00:02 init
system_u:system_r:kernel_t 2 ? 00:00:00 ksoftirqd/0
system_u:system_r:kernel_t 3 ? 00:00:00 watchdog/0
system_u:system_r:kernel_t 4 ? 00:00:00 events/0
...Lines snipped...
user_u:system_r:unconfined_t 24168 pts/2 00:00:00 bash
user_u:system_r:unconfined_t 24228 pts/2 00:00:00 ps
user_u:system_r:unconfined_t 24229 pts/2 00:00:00 tail
This information is also displayed by the GNOME System Monitor, as shown in Figure 8-7 .
If you've added the System Monitor applet to your GNOME panel, clicking on it will start the GNOME System Monitor. You can also start it using the menu entry ApplicationsSystem ToolsSystem Monitor, or by typing the command gnome-system-monitor.
Figure 8-7. GNOME System Monitor display showing the security contexts of processes
The label on the init process (highlighted in Figure 8-7 ) indicates that the user is system_u , the role is system_r , and the type is init_t . The sensitivity is not shown in this output. This label defines the source security context ( scontext ) because the init process is a source of system access requests.
_t indicates a type, _r indicates a role, and _u indicates a user
When init attempts to read the configuration file /etc/inittab , the label on that file defines the target security context ( tcontext ):
$ ls -Z /etc/inittab
-rw-r--r-- root root system_u:object_r:etc_t /etc/inittab
Context labels on files are stored in the file's attributes, and therefore SELinux can be used only on filesystems that support these attributes: ext2, ext3, and XFS. Other filesystems, such as ReiserFS, JFS, ISO9660, and VFAT do not support these attributes yet.
You can view the context labels as a file attribute using the getfattr command, specifying the security.selinux attribute name:
# getfattr -n security.selinux /etc/hosts
getfattr: Removing leading '/' from absolute path names
# file: etc/hosts
security.selinux="system_u:object_r:etc_t:s0\000"
The last portion of the security.selinux attribute is the sensitivity level, which is used only for multilevel security (MLS) and multicategory security (MCS). The \000 at the end of the attribute indicates an ASCII NUL character, used to delimit the end of the attribute in traditional C style.
The target class ( tclass ) associated with the object being accessed is determined by the type of object (and in some cases, how it is being accessed); in this example, where init is attempting to access /etc/inittab , the tclass is file . Therefore the SELinux policy is checked to see if access is permitted for an scontext of system_u:system_r:init_t , a tcontext of system_u:object_r:etc_t , and a tclass of file . To speed access, SELinux rules are cached in an area of memory called the access vector cache which explains why SELinux error messages are labeled avc .
The Fedora project has three policies available:
targeted
The default policy installed with Fedora Core. This policy is targeted for the protection of the most frequently attacked portions of the system, including most network services. Programs that are not targeted are unconstrained by SELinux.
strict
This policy denies every action except those explicitly permitted. Although this should be more secure than the targeted policy, it's hard to create a policy that encompasses all possible configurations of all programs that can be installed on a Fedora system, and attempting to use this policy has frustrated many system administrators into turning off SELinux altogether. In other words, the targeted policy is often more secure simply because it's more likely to be used.
MLS
Experimental policy to support multilevel security ( MLS). This is important for some government certifications and is not widely used outside of government. (The future MCS framework appearing in the targeted policy will use specific features of MLS for a type of discretionary access control).
In the default targeted policy, the role element of the security context is not used (all subjects are system_r, and all objects are object_r), and very few users are defined (just system_u , user_u , and root ).
SELinux policies are difficult and time-consuming to write, and even more difficult to write well. Nonetheless, they have to be customized to suit the particular needs of each site. The SELinux booleans provide a compromise between complexity and flexibility, by enabling policy options to be configured without editing, compiling, and retesting the policy code.
The SELinux technology was originally developed by the U.S. National Security Agency (NSA), with several partner organizations. The kernel components of SELinux have been incorporated into the main Linux kernel releases. The Fedora project utilizes those kernel components along with customized policy and some user tools (such as versions of ls and ps that include the -Z options, and SELinux-specific tools such as chcon and getenforce , and the graphical configuration tool system-config-securitylevel ). Red Hat is a major contributor to SELinux development.
These alternate policies are provided as RPM packages and are installed using yum :
# yum install selinux-policy-strict selinux-policy-mls
Switch between the installed policies using the graphical configuration tool ( system-config-securitylevel from the command line, or System→Administration→"Security Level and Firewall" from the menu). When more than one policy is installed, a drop-down menu for Policy Type appears on the SELinux tab, as shown in Figure 8-8. When you change the policy, the warning dialog shown at bottom left of Figure 8-8 will appear, informing you that the policy change will cause the filesystem to be relabeled. Click Yes to approve the relabeling, and then click OK in the Security Level Configuration window. Reboot to activate the new policy.
Figure 8-8. Selecting policy using the Security Level Configuration tool
To change the policy from the command prompt, edit /etc/selinux/config and change the SELINUXTYPE value to the policy of your choice ( targeted , strict , or mls ):
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=mls
# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0
Then create the empty file /.autorelabel to ensure that the filesystem will be relabeled when the system is booted:
# touch /.autorelabel
Reboot to activate the change.
Fedora development is focused on the targeted policy. Changing the policy may lead to a number of unexpected system problems!
If you have SELinux enabled, but your system cannot boot successfully due to an SELinux problem, you may need to temporarily disable it while you investigate.
To boot with SELinux disabled, append selinux=0 to the boot options.
The manpages for selinux , getsebool , setsebool , getenforce , setenforce , sestatus , semanage , selinuxenabled , restorecon , getfattr , and audit2why
The manpage for <subsystem>_selinux (for example, the manpage for samba_selinux for details of SELinux protection provided for the Samba server)
The Fedora Wiki SELinux page: http://fedoraproject.org/wiki/SELinux
The setroubleshoot Wiki page: http://fedoraproject.org/wiki/SELinux/setroubleshoot
The NSA SELinux web site: http://www.nsa.gov/selinux/index.cfm
The SELinux project on Sourceforge: http://selinux.sourceforge.net/
The SELinux symposium web site: http://www.selinux-symposium.org/
The NSA SELinux FAQ: http://www.nsa.gov/selinux/info/faq.cfm
The Fedora SELinux FAQ: http://fedora.redhat.com/docs/selinux-faq/
The Unofficial SELinux FAQ: http://www.crypt.gen.nz/selinux/faq.html
The home page of Tresys, a company that has done extensive work on SELinux policy development: http://www.tresys.com/
The Linux Security Modules web site: http://lsm.immunix.org/
Unix/Linux permission modes are very simple; they don't cover all security needs. But, because they are simple, they are actually used , which is more than can be said for many other access control technologies.
But sometimes permissions just don't cut it, and a better system of discretionary access control is needed. Access control lists (ACLs) enable you to specify exactly which users and groups can access a file and in what ways.
In order to use ACLs on a filesystem, that filesystem must be mounted with the acl mount option. To check whether this option is active, use the mount command:
$ mount
/dev/mapper/main-root on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hdc2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/main-home on /home type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid10695) on /net type autofs (rw,fd=4,pgrp=10695,minproto=2,maxproto=4)
If you kept the default volume group and logical volume names during installation, you may see device paths such as /dev/mapper/VolGroup00-LogVol01.
The mount options are shown in parentheses; none of these filesystems were mounted with the acl option.
To add the acl mount option to a filesystem that is already mounted, use the mount command with the remount option:
# mount -o remount,acl /home
# mount -o remount,acl /
# mount
/dev/mapper/main-root on / type ext3 (rw,acl)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hdc2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/main-home on /home type ext3 (rw,acl)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid10695) on /net type autofs (rw,fd=4,pgrp=10695,minproto=2,maxproto=4)
Note that the /home and / filesystems are now mounted with the acl option. To make this option the default for future mounts of these filesystems, edit the file /etc/fstab and add it to the fourth column for these filesystems:
/dev/main/root / ext3 defaults ,acl 1 1
LABEL=/boot /boot ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/main/swap swap swap defaults 0 0
/dev/main/home /home ext3 defaults ,acl 1 2
Once the filesystem has been mounted with the correct option, the getfacl (get file ACL) command can be used to view the ACL of a file:
$ touch test
$ ls -l test
-rw-rw-r-- 1 chris chris 0 May 6 20:52 test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
group::rw-
other::r--
The ACL displayed by getfacl exactly matches the permissions shown by ls : the user who owns the file ( chris ) can read and write the file, users in the group that owns the file ( chris ) can read and write the file, and all of the other users of the system can only read the file.
Each entry in the ACL consists of three components separated by colons:
type
The keyword user , group , mask , or other . This may be abbreviated to u , g , m , or o when setting or changing ACL entries.
qualifier
The name of the user or group affected by this entry. User type entries with an empty qualifier apply to the user that owns the file; group type entries with an empty qualifier apply to the group that owns the file. mask and other enTRies always have an empty qualifier.
permissions
The permissions granted by the entry; any combination of r (read), w (write), and x (execute). When displayed by the getfacl command, the permissions are always shown in rwx order, and permissions that are not granted are replaced with a dash.
To modify the ACL, use the setfacl command with the -m (modify) option. This command will limit the user thomas to just reading the file test :
$ setfacl -m user:thomas:r test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
group::rw-
mask::rw-
other::r--
This additional ACL entry shows up on a line of its own. Notice that a mask entry is now displayed, showing the maximum permission available to users and groups identified by a qualifier; this mask value corresponds to the group permission of the traditional Linux permission mode, as displayed by ls .
When ls is used to display detailed file information, the output is slightly modified:
$ ls -l test
-rw-rw-r--+ 1 chris chris 0 May 6 20:52 test
The + after the file permissions indicates that an ACL is in effect in addition to the permissions shown.
Changing the file mode using the chmod command alters the ACL mask value:
$ chmod 644 test
$ ls -l test
-rw-r--r--+ 1 chris chris 0 May 6 20:52 test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
group::rw- #effective:r--
mask::r--
other::r--
The new group permission has been set to r-- (read-only), and this is also used as the mask value. Because the mask is more limiting than the group value in the ACL, the group permission has effectively changed to r-- , as indicated by the #effective:r-- comment in the output.
This works both ways; changing the mask using setfacl also changes the group permission, as displayed by ls :
$ ls -l test
-rw-r--rwx+ 1 chris chris 0 May 6 20:52 test
$ setfacl -m mask::rw test
$ ls -l test
-rw-rw-rwx+ 1 chris chris 0 May 6 20:52 test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
group::rw-
mask::rw-
other::rwx
On the other hand, changing the default group ACL entry affects both that entry and the mask value:
$ setfacl -m g::r test
$ ls -l test
-rw-r--r--+ 1 chris chris 0 May 6 20:52 test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
group::r--
mask::r--
other::r--
The g::r argument is a short form for group::r.
To change multiple ACL entries at one time, separate them by commas:
$ setfacl -m u:diane:rw,u:jim:r,g::r,m::rw test
$ getfacltest
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
user:diane:rw-
user:jim:r--
group::r--
mask::rw-
other::r--
To set a new ACL, discarding the previous ACL completely, use the --set argument instead of -m :
$ setfacl --set u::rw,u:diane:r,u:thomas:r,u:gord:rw,u:jim:r,m::rw,g::-,o::- test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
user:diane:r--
user:gord:rw-
user:jim:r--
group::---
mask::rw-
other::---
Note the use of - to indicate no permissions in the ACL entries for group and other .
When using --set , it is necessary to specify at least the permission for the file's owner, the file's group owner, and others, because these will be used to construct the legacy permission mode. Leaving one of those entries out results in an error message:
$ setfacl --set u:diane:r,g::- test
setfacl: test: Malformed access ACL \Quser:diane:r--,group::---,mask::r--':
Missing or wrong entry at entry 1
To remove an ACL entry, use the -x option to setfacl and specify one or more ACL entries by the type and qualifier components (leave out the permissions):
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
user:diane:r--
user:gord:rw-
user:jim:r--
group::---
mask::rw-
other::---
$ setfacl -x user:gord test
$ getfacl test
# file: test
# owner: chris
# group: chris
user::rw-
user:thomas:r--
user:diane:r--
user:jim:r--
group::---
mask::r--
other::---
Each file has an access ACL , but directories can additionally have a default ACL that is used as the default for new files and subdirectories created within that directory.
The default ACL is displayed when getfacl is run with the -d option. Initially the default ACL is empty:
$ getfacl .
# file: .
# owner: chris
# group: chris
user::rwx
group::rwx
other::r-x
$ getfacl -d .
# file: .
# owner: chris
# group: chris
To set the default ACL, use the setfacl command with the -d option:
$ setfacl -d --set u::rw,u:thomas:rw,g::r,m::rw,o::- .
$ getfacl -d .
# file: .
# owner: chris
# group: chris
user::rw-
user:thomas:rw-
group::r--
mask::rw-
other::---
This ACL will then be applied automatically to new files:
$ touch trial
$ getfacl trial
# file: trial
# owner: chris
# group: chris
user::rw-
user:thomas:rw-
group::r--
mask::rw-
other::---
To copy an ACL when copying a file, use the -p argument to cp :
$ getfacl demo
# file: demo
# owner: chris
# group: chris
user::rw-
group::rw- #effective:r--
mask::r--
other::---
$ cp -p demo demo2
$ getfacl demo2
# file: demo2
# owner: chris
# group: chris
user::rw-
group::rw- #effective:r--
mask::r--
other::---
When moving a file (with mv ), the ACL is automatically preserved:
$ mv demo2 demo3
$ getfacl demo3
# file: demo3
# owner: chris
# group: chris
user::rw-
group::rw- #effective:r--
mask::r--
other::---
It can be a lot of work setting up a complex ACL with many entries. To simplify the reuse of ACLs, setfacl provides the --set-file option, which sets an ACL from a text file. This file can be created by redirecting the output of getfacl , providing an easy way to copy an ACL from one file to another. This example writes the ACL from the file demo to the file /tmp/acl , and then applies that ACL to the file bar :
$ getfacl demo >/tmp/acl
$ setfacl --set-file /tmp/acl bar
$ getfacl bar
# file: bar
# owner: chris
# group: chris
user::rw-
user:thomas:r--
user:diane:r--
user:gord:rw-
user:jim:rw-
group::rw-
mask::rw-
other::---
Since --set-file accepts the filename - for standard input, you can also pipe the output of getfacl into setfacl to copy an ACL without using an intermediate file:
$ getfacl demo | setfacl --set-file - bar
getfacl provides a --tabular option, which presents the output in a format that is somewhat easier to read than the default output:
$ getfacl bar
# file: bar
# owner: chris
# group: chris
user::rw-
user:thomas:r--
user:diane:r--
user:gord:rw- #effective:r--
user:jim:rw- #effective:r--
group::rw- #effective:r--
mask::r--
other::---
$ getfacl --tabular bar
# file: bar
USER chris rw-
user thomas r--
user diane r--
user gord rW-
user jim rW-
GROUP chris rW-
mask r--
other ---
Notice that permissions that are not effective due to the mask value are shown in (the name inserted into the qualifier column is the file's owner and group owner).
It can be convenient to create an alias for viewing the tabular output:
$ alias showacl=' getfacl --tabular'
Don't name this alias getfacl, or you won't be able to copy ACLs between files; tabular output cannot be used as input to setfacl.
ACLs are stored in a compressed format in a file's extended attributes, just like SELinux context labels. They can be viewed with the command getfattr using the name system.posix_acl_access :
$ getfattr -n system.posix_acl_access yearend.ods
# file: yearend.ods
system.posix_acl_access=0sAgAAAAEABgD/////AgAEAPYBAAACAAQA9wEAAAIABg
D4AQAAAgAGAPoBAAAEAAYA/////xAABgD/////IAAAAP////8=
Obviously, the output of getfacl is much more useful!
Like SELinux labels, ACLs work only on filesystems that support extended attributes, and therefore cannot be used on filesystems such as VFAT and ISO9660.
On an ext2 or ext3 filesystem, all of the extended attributes must fit into one block , as defined at the time that the filesystem was created. To determine the block size of a filesystem, use dumpe2fs :
# dumpe2fs /dev/mapper/main-home | grep 'Block size'
dumpe2fs 1.38 (30-Jun-2005)
Block size: 4096
In this case, the block size is 4,096 bytes (4 KB); the SELinux context, ACL, and any other extended attributes must fit within that 4 KB limit.
When an ACL is changed, a new block is allocated, the new ACL is written to that block, and then the old block is freed. If no blocks are available on the filesystem (or if the user doesn't have access to any more blocks, which may be the case if you have enabled per-user storage quotas), then the ACL cannot be changed.
Modification of an ACL may only be performed by the owner of the file and the superuser ( root ).
Unfortunately, Fedora Core does not include any tools that permits ACLs to be viewed or adjusted graphically.
The -R option to getfacl produces a recursive listing of all files in the named directory. setfacl has a --restore option that will use such a recursive listing to set the ACLs of a group of files. This can be used to save and restore ACLsuseful if a number of files are being transported between systems, or backed up and restored from tape or optical disk.
For example, this command creates a file named acl.txt that contains all of the ACLs for all files and subdirectories in the current directory:
$ getfacl -R . > acl.txt
The entire directory can be copied to a CD or DVD, backed up to tape or a USB flash drive, or saved in a tarball and sent to another system. To restore the ACLs at a later date:
# setfacl --restore acl.txt
If the setfacl command is run as root , the ownerships and group ownerships will also be reset to their original values.
Fedora Core provides the star package, which is an advanced replacement for tar . star can back up and restore ACLs along with files when the exustar archive format is used and the -acl option is specified. For example, to back up the /home directory with ACL information:
# star cvzf /tmp/home-backup.star.gz -acl artype=exustar /home
a /home/ directory
a /home/john/ directory
a /home/john/.bash_logout 24 bytes, 1 tape blocks
a /home/john/.bash_profile 191 bytes, 1 tape blocks
a /home/john/.bashrc 124 bytes, 1 tape blocks
a /home/john/.gtkrc 120 bytes, 1 tape blocks
...(Lines snipped)...
To restore from this archive:
# star xvzf /tmp/home-backup.star.gz artype= exustar -acl
star: WARNING: skipping leading '/' on filenames.
Release star 1.5a69 (i386-redhat-linux-gnu)
Archtype exustar
Dumpdate 1146974078.733347 (Sat May 6 23:54:38 2006)
Volno 1
Blocksize 20
x home/ directory
x home/john/ directory
x home/john/.bash_logout 24 bytes, 1 tape blocks
x home/john/.bash_profile 191 bytes, 1 tape blocks
x home/john/.bashrc 124 bytes, 1 tape blocks
x home/john/.gtkrc 120 bytes, 1 tape blocks
...(Lines snipped)...
The manpages for acl(5) , getfacl , and setfacl
The manpages for star and spax
Because the root user can override permissions, file permissions alone are not enough to ensure that a file will not be changed. But when a file is made immutable , it cannot be changed by anyone.
To make a file immutable, use the chattr (change attribute) command to add the i attribute to the file:
# chattr +i foo
# date >> foobash: foo: Permission denied
# mv foo baz
mv: cannot move \Qfoo' to \Qbaz': Operation not permitted
# rm foo
rm: cannot remove \Qfoo': Operation not permitted
You can find out if the i attribute has been set by using the lsattr (list-attribute) command:
# lsattr foo
----i-------- foo
The presence of the i in the output indicates that the file foo has been made immutable.
Removing the i attribute causes the file to act normally again:
# chattr -i foo
#
date>>foo
#
mvfoo baz
#
rmbaz
# 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:
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 [email protected]
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:
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
session required pam_loginuid.so
Authentication is carried out by the first line, which includes all of the auth lines from the file /etc/pam.d/system-auth , which looks like this:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
The first line highlighted in bold executes the pam_env.so module ( /lib/security/pam_env.so ), which sets up environment variables according to the configuration file /etc/security/pam_env.conf . The next lines use the pam_unix.so module to perform traditional Unix password checking, then deny access if the password check does not succeed.
In this configuration, the pam_succeed_if.so lines do nothing! (They are used when a network authentication scheme is in effect, though.)
These are the account entries, as included into the sshd configuration file from the system-auth file:
account required pam_nologin.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
The pam_nologin.so module checks for the existence of the file /etc/nologin and, if present, prevents anyone except root from logging in. This is useful during periods of system maintenance.
The contents of /etc/nologin will be displayed as a message to the user in a dialog box when he attempts to log in using the graphical user interface. In the case of a character-mode login, the file will be displayed but the screen will be cleared immediately, making it nearly impossible to read the message. The SSH daemon will not display the message at all.
The pam_unix.so module (in this account mode) performs password maintenance checking, to see if the user should be forced to change her password, warned of imminent expiry, or locked out of the system. Finally, the pam_permit.so module sets up a default action of permit for the account section of the file.
The password portion of the configuration controls password changes:
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
The first line executes pam_cracklib.so to ensure that any newly set password is sufficiently complex, and the second line updates the password files on the system. The last line ensures that a failure is recorded if the password update is not successful.
Finally, we have the session entries, which set up the environment and perform logging after the user has authenticated:
session required pam_limits.so
session required pam_unix.so
session required pam_loginuid.so
The first two lines are included from /etc/pam.d/system-auth , while the last line is from /etc/pam.d/sshd .
The pam_limits.so module can be used to configure ulimit values according to /etc/security/limits.conf , but the default version of that file contains only comments. You can use this module to limit the amount of memory, CPU time, simultaneous logins, or other resources available to specific users.
The pam_unix.so module (in session mode) simply logs the fact that the user has authenticated using the syslog facility. The last module, pam_loginuid.so , records the fact that this is an initial login (as opposed to a switch of user ID performed using su or sudo ).
Fedora can authenticate against an authentication server instead of (or in addition to) the local user and password database ( /etc/passwd , /etc/shadow , /etc/group , and /etc/gshadow ). Usable authentication and user information services include Kerberos, LDAP, Hesiod (DNS), Winbind (local Windows domain), and SMB (Windows domain server).
To use an established authentication server, select the desktop menu option System→Administration→Authentication or run the command system-config-authentication. The window shown in Figure 8-9 will appear. Select the User Information or Authentication tab, and then select the checkbox for the server type you wish to use. Click the Configure button to the right of the server type to enter the parameters specifically required by that server type (for example, for NIS you will need to enter the NIS domain and the server name).
Click OK. system-config-authentication will then write a new version of the file /etc/pam.d/system-auth .
Figure 8-9. Authentication Configuration window
Using the Authentication Configuration tool will undo any customization that you have made in /etc/pam.d/system-auth.
Authentication can also be configured from the command line using authconfig .
We can tighten up the security of the system by adding additional modules into the configuration file. For example, you can restrict SSH access to certain times of day using the pam_time.so module.
Before editing any PAM configuration file, make a backup copy. You should also keep a root shell open in a virtual terminal or terminal window in case your changes accidentally lock you out of the system. Test the new configuration thoroughly before closing the root shell!
Edit /etc/pam.d/sshd to add pam_time.so in the account section:
#%PAM-1.0
auth include system-auth
account required pam_time.so
account include system-auth
password include system-auth
session include system-auth
session required pam_loginuid.so
Notice that the sequence of the lines is critical; if you place the pam_time.so line after the file system-auth is included, it will be ignored for users with IDs less than 500 (such as root) due to the pam_succeed_if.so line in system-auth.
The pam_time.so module restricts access based on the contents of the file /etc/security/time.conf , which is a text file with four semicolon-delimited fields per line. The fields are:
service
Must match the name of the service file in /etc/pam.d ( sshd in this example).
tty
Terminal device names (not useful in this context, so we'll use * to match all terminals).
users
A list of usernames, combined using ! (not), & (and), or | (or).
times
A list of days (any combination of Su , Mo , Tu , We , Th , Fr , or Sa or Wk for weekdays, Wd for weekends, or Al for all days) concatenated to a range of times, expressed in 24-hour format (such as 0600-1800 for 6 a.m. to 6 p.m., local time).
The default /etc/security/time.conf contains extensive notes on the line format.
To prevent all users other than root from connecting via SSH during evenings and weekends, place these lines in /etc/security/time.conf :
# Limit ssh for non-root users to 8 am to 5 pm on weekdays
sshd;*;!root;Wk0800-1700
Note that if there is no line in /etc/security/time.conf that applies to a particular connection, it is permitted by default. These restrictions also apply only when a user logs in; once logged in, the user may stay connected for as long as he chooses.
To place a time restriction on all types of loginwhether through SSH, a local character-mode virtual terminal, or the GUIplace the entry for the pam_time.so module in /etc/pam.d/system-auth instead of /etc/pam.d/sshd :
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_time.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
You can then create separate rules for each type of user access in /etc/security/time.conf :
# Character-mode login - Only root is permitted (any time).
login;*;!root;!Al0000-2400
# Remote login via ssh - Root is always permitted, other
# users are permitted 8 am to 5 pm on weekdays.
sshd;*;!root;Wk0800-1700
# Graphical-mode login - Not available to root.
gdm;*;root;!Al0000-2400
# Switching user via 'su' command - not permitted unless
# switching -to- the root user. Note that the root user
# can switch to any other user because of the pam_rootok.so
# module line in /etc/pam.d/su
su;*;!root;!Al0000-2400
The PAM module pam_abl.so from Fedora Extras provides the ability to blacklist (block access from) users and hosts that repeatedly send an incorrect password. This is useful in guarding against brute-force password attacks, where a remote system will simply try to log in over and over again with different password guesses until it is successful.
This module will not work successfully with gdm (graphical logins), so it must not be added to system-auth . To protect SSH logins (the best use of this module), add an entry for pam_abl.so module to /etc/pam.d/sshd :
#%PAM-1.0
auth required pam_abl.so config=/etc/security/pam_abl.conf
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
session required pam_loginuid.so
The file /etc/security/pam_abl.conf is installed by the pam_abl RPM and contains this configuration:
# /etc/security/pam_abl.conf
# debug
host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:10/1h,30/1d
user_db=/var/lib/abl/users.db
user_purge=2d
user_rule=!root:10/1h,30/1d
The host_rule line controls which hosts may be blacklisted and the number of failed login attempts that must be registered before blacklisting; the default configuration specifies that any host ( * ) may be blacklisted for more than 10 login failures in one hour ( 10/1h ), or more than 30 login failures in one day ( 30/1d ). The user_rule line similarly blacklists any user except root ( !root ) who has 10 failed login attempts in one hour or 30 failed login attempts in one day.
The host_purge and user_purge lines configure how quickly a blacklist entry is revoked; the default for both is two days.
When a login failure is recorded, the pam_abl.so module updates its database. You can query the database using the pam_abl command:
# pam_abl
Failed users:
<none>
Failed hosts:
<none>
Initially, no failed login attempts are recorded. As login failures occur, pam_abl will count and report them (in parenthesis):
# pam_abl
Failed users:
jane (1)
Not blocking
Failed hosts:
darkday (1)
Not blocking
Eventually, access from the host or user will be blocked:
# pam_abl
Failed users:
jane (11)
Blocking users [!root]
Failed hosts:
darkday (11)
Blocking users [*]
To re-enable access from a specific host or by a specific user, use the --okhost or --okuser arguments to pam_abl :
# pam_abl --okhost darkday
# pam_abl
Failed users:
jane (11)
Blocking users [!root]
Failed hosts:
<none>
Fedora uses the consolehelper program to control access to a number of system administration tools. It's consolehelper that asks you for the root password when you use many of the configuration menu options such as System→Administration→Network (or, equivalently, run system-config-network from the shell).
If you examine the system-config-network file, you'll see that it is actually a symbolic link to consolehelper :
$ type system-config-network
system-config-network is /usr/bin/system-config-network
$ ls -l /usr/bin/system-config-network
lrwxrwxrwx 1 root root 13 Mar 20 14:57 /usr/bin/system-config-network -> consolehelper
When consolehelper is invoked with another command name, it uses the PAM configuration in /etc/pam.d with the same name as the command entered. If the user runs system-config-network , then the PAM configuration /etc/pam.d/system-config-network is invoked, which looks like this:
#%PAM-1.0
auth include config-util
account include config-util
session include config-util
This includes /etc/pam.d/config-util , which contains these lines:
#%PAM-1.0
auth sufficient pam_rootok.so
auth sufficient pam_timestamp.so
auth include system-auth
account required pam_permit.so
session required pam_permit.so
session optional pam_xauth.so
session optional pam_timestamp.so
The auth configuration will succeed if the current user is root ( pam_rootok.so ) or there is a recent timestamp file present ( pam_timestamp.so ). Failing that, the traditional Unix password authentication is performed (via the included system-auth file).
The timestamp file that pam_timestamp.so checks is created by the last line, which invokes the pam_timestamp.so module in session mode. In other words, if the user successfully authenticates to the system as root in order to use one tool, she is permitted to run other tools without typing in her password for the next few minutes.
Once the authentication has succeeded, consolehelper consults the file with the same name as the originally entered command in the directory /etc/security/console.apps ; in this example, the file would be /etc/security/console.apps/system-config-network , which contains:
USER=root
PROGRAM=/usr/sbin/system-config-network
SESSION=true
This instructs consolehelper to run /usr/sbin/system-config-network as the root user after performing the PAM session initialization (using the session lines in the PAM configuration file).
You can adjust the PAM configuration to suit your needs. For example, to allow regular users to run system-config-network without entering the root password, edit the auth line in /etc/pam.d/system-config-network to use the permissive pam_permit.so module instead of including the config-util file:
#%PAM-1.0
auth sufficient pam_permit.so
account include config-util
session include config-util
It's often convenient to enable the console userthe person physically logged on to the system keyboard and displayto run any of the programs controlled by consolehelper without entering the root password. To do this, edit /etc/pam.d/config-util and add this line:
#%PAM-1.0
auth sufficient pam_rootok.so
auth sufficient pam_timestamp.so
auth sufficient pam_console.so
auth include system-auth
account required pam_permit.so
session required pam_permit.so
session optional pam_xauth.so
session optional pam_timestamp.so
This will permit the current console owner to execute the configuration tools regardless of where he is executing them. For example, if the user joe is logged in on the console (either graphically or using a character-mode login), then joe can execute configuration tools both at the console and through a remote connection.
PAM is simply a group of libraries used by applications. Each PAM-aware application uses those libraries to perform authentication, account control, the management of passwords (or other tokens), and session setup.
Each PAM module is a shared object ( .so ) file conforming to the PAM specification. These files are stored in /lib/security and are accessed when needed according to the configuration files in /etc/pam.d .
There are many PAM modules included in Fedora Core. For documentation, refer to the PAM Administrator's manual in /usr/share/doc/pam-*/html/. Some PAM modules not documented in that manual have their own manpages; use apropos pam_ to see a list of all of them.
There are also a number of PAM modules available on the Internet and from hardware vendors, designed to support authentication using biometric devices, smart tokens, and more.
Edit /etc/pam.d/su to add this line:
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth sufficient pam_console.so
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
Then create the file /etc/security/console.apps/su :
# touch /etc/security/console.apps/su
You can now use su at the console without entering the root password.
This is, obviously, a security risk.
The manpages for pam , consolehelper , userhelper , and authconfig
The PAM administrator's guide: /usr/share/doc/pam*/html
The manpages for the PAM modules (use the command apropos pam_ to see a list of all of them); not all of the PAM modules have a manpage
It's important to know what is going on on your system. Fedora provides a standardized, network-based logging system and tools to automatically monitor and trim logfiles. Understanding and using these tools effectively will allow you to keep your finger on the pulse of your system with minimal effort.
The syslog facility collects and routes messages in a Fedora system. The file /etc/syslog.conf configures the message routing; the default version of the file looks like this:
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* -/var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log
local7.* /var/log/boot.log
On the left side of each entry is a pattern that consists of selectors. Each selector contains one or more facilities (separated by commas), then a period, and then one or more levels (again, separated by commas).
The facility indicates the origin of the log entry. Possible values are shown in Table 8-3 .
Table 8-3. Facility values to indicate the origin of the log entry
| Value | Description |
|---|---|
| authpriv | Security, authentication, or authorization systems. |
| cron | Task scheduler (crond and atd). |
| daemon | Server daemons that don't have a category of their own. |
| ftp | File-transfer-protocol daemon. |
| kern | Kernel messages. |
| local0, local1, local2, local3, local4, local5, local6, and local7 | Reserved for custom use on a distribution-by-distribution or site-by-site basis. Fedora uses local7 to log boot messages. |
| lpr | Printing system. |
| Electronic mail. | |
| news | Net news (Usenet). |
| syslog | Messages from syslogd itself. |
| user | User-level messages. |
| uucp | Unix-to-Unix copy messages (rarely used). |
The level consists of a priority level and can be any of the values listed in Table 8-4 , in increasing order of severity.
Table 8-4. Priority-level values, in order of severity
| Value | Description |
|---|---|
| debug | Informational software debugging messages. |
| info | General informational messages. |
| notice | Important normal messages that do not indicate an error or problem. |
| warning | Information about an unusual or impending situation. |
| err | Error messages, indicating that something is wrong. |
| crit | Critical conditions indicating imminent danger. |
| alert | Serious, emergency problems. |
| emerg | Emergency situation: the system is in crisis and failing. |
Specifying a level means any message of that level or higher (more severe), so the selector kern.crit would match messages from the kernel with a priority of crit , alert , or emerg . To match only crit , an equal sign is added: kern.=crit . An exclamation mark negates a match: kern.!crit matches kernel messages with a priority below crit , while kern.!=crit matches all kernel messages except those with a priority of crit .
An asterisk indicates that the facility or level should be ignored. Therefore, authpriv.* matches messages from the authpriv facility regardless of the priority, and *.info matches messages from any facility which are at the info level or higher. Multiple facilities or priorities can be matched using commas (indicating an OR operation), so mail,local3.* matches any message from the mail or local3 facilities.
Multiple selectors may be included in one entry, separated by semicolons, which indicates an AND operation. The special priority none matches no messages from the specified facility. Therefore *.crit;kern.none matches all messages that are of crit priority or higher, unless they come from the kernel.
On the right side of each entry in /etc/syslog.conf is a destination for the messages. The destination may be:
An absolute pathname
Messages are placed in the specified file. The pathname may also point to a named pipe, providing a method for passing messages to another program, or to a device such as a terminal (such as /dev/tty3 ) or a printer ( /dev/lp0 ). Adding a hyphen in front of a pathname will prevent syslogd from flushing the buffers to disk after each write, a performance-eating behavior that increases the chance that a message describing the cause of a crash will make it onto the disk.
@ host
Messages are forwarded to syslogd on the remote host .
user,user,user,...
Messages are written to the terminals of any of these users who are currently logged in.
*
Messages are written to the terminals of all logged-in users.
The order of the lines in the configuration file does not matter; every line is checked against each incoming message, so messages may be sent to multiple destinations.
The default configuration file routes messages according to Table 8-5 ; as you can see, /var/log/messages is the prime source of information about the state of the system.
Table 8-5. Message routing as configured in the default syslog configuration file
| Type of message | Destination |
|---|---|
| Everything except mail, authentication, and cron messages, with a priority of info or higher | /var/log/messages |
| Authentication messages (which may contain private information) | /var/log/secure |
| /var/log/maillog | |
| Cron | /var/log/cron |
| All messages of emerg level or higher | The terminals of all logged-in users |
| UUCP and news messages of crit level or higher | /var/log/spooler |
| Boot messages | /var/log/boot.log |
The /var/log/messages logfile contains entries similar to this:
May 31 10:40:58 laptop3 dhclient: DHCPREQUEST on eth0 to 172.16.97.254 port 67
May 31 10:40:58 laptop3 dhclient: DHCPACK from 172.16.97.254
May 31 10:40:58 laptop3 dhclient: bound to 172.16.97.100 -- renewal in 34387 seconds.
May 31 20:14:05 laptop3 dhclient: DHCPREQUEST on eth0 to 172.16.97.254 port 67
May 31 20:14:05 laptop3 dhclient: DHCPACK from 172.16.97.254
May 31 20:14:05 laptop3 dhclient: bound to 172.16.97.100 -- renewal in 41631 seconds.
Each entry consists of a date, time, hostname ( laptop3 in this example), program name or other prefix ( dhclient ), and a text message. Note that the facility and priority are not recorded in the logfile.
Since the /var/log/message file can be very large, it's worthwhile using a tool such as grep to search for specific records. For example, you can view all of the kernel messages with the command:
$ grep kernel /var/log/messages
May 30 04:23:08 bluesky kernel: SELinux: initialized (dev hdd, type iso9660), uses genfs_contexts
May 31 20:48:40 bluesky kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x85 on isa0060/serio0).
May 31 20:48:40 bluesky kernel: atkbd.c: Use 'setkeycodes e005 <keycode>' to make it known.
May 31 21:14:54 bluesky kernel: cdrom: This disc doesn't have any tracks I recognize!
You can generate syslog messages using the logger command-line tool. Simply provide your text as arguments:
$ logger Added host lightning to /etc/hosts
The message recorded in /var/log/messages contains the username as the prefix:
Jun 1 02:32:59 darkday chris: Added host lightning to /etc/hosts
It's convenient to log information about changes you have made on the system in this way, entering them as you work. Your notes will be interleaved with system-generated log messages, making it easy to see the relationship between the changes that you have made and any messages that start or stop appearing in the log as a result.
By default, logger uses the facility user and the priority notice . You can override this using the -p option, and you can override the insertion of the username by supplying an alternate tag with the -t option:
$ logger -p local1.crit -t cooling Stopped water pump
Which would result in this message being logged:
Jun 1 09:54:49 darkday cooling: Stopped water pump
An alias can be used to simplify logging from the command line:
$ alias note='logger -p local4.notice '
$ note Ran yum update
If you are logging a message that contains metacharacters, surround the message with quotation marks.
By adding a custom rule to /etc/syslog.conf , the messages sent to the local1 facility can be placed in their own file (in addition to being logged in /var/log/messages ):
local1.* /var/log/cooling
The security context of any new logfiles must be set to the same context as /var/log/messages :
# touch /var/log/cooling
# ls -Z /var/log/messages /var/log/cooling
-rw-r--r-- root root user_u:object_r:var_log_t /var/log/cooling
-rw------- root root system_u:object_r:var_log_t /var/log/messages
# chcon system_u:object_r:var_log_t /var/log/cooling
# chmod 0600 /var/log/cooling # Optional!
# ls -Z /var/log/messages /var/log/cooling
-rw------- root root system_u:object_r:var_log_t /var/log/cooling
-rw------- root root system_u:object_r:var_log_t /var/log/messages
The -f option to tail provides a convenient way to watch messages that are being appended to a file and is perfect for use with logfiles:
# tail -f /var/log/messages
Jun 1 08:47:14 darkday kernel: hub 1-0:1.0: over-current change on port 1
Jun 1 08:47:14 darkday kernel: hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
Jun 1 08:47:14 darkday kernel: hub 1-0:1.0: over-current change on port 2
Jun 1 08:47:14 darkday kernel: usb 1-2: USB disconnect, address 4
Jun 1 08:47:14 darkday kernel: usb 1-2: new low speed USB device using uhci_hcd and address 5
Jun 1 08:47:14 darkday kernel: usb 1-2: configuration #1 chosen from 1 choice
Jun 1 08:47:14 darkday kernel: input: Logitech USB-PS/2 Optical Mouse as /class/input/input4
Jun 1 08:47:14 darkday kernel: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1f.2-2
Jun 1 09:54:49 darkday cooling: Water temperature exceeds 70C
Jun 1 09:54:49 darkday cooling: Water temperature exceeds 85C
...(Additional lines are displayed as they are added to the logfile)...
/var/log/messages is normally readable only by root. Although making it readable by other users may reveal a small amount of information about your system (reducing security), it can also reduce the amount of time spent in superuser mode (which, in turn, increases security). To make the messages file accessible to everyone:
# chmod a+r /var/log/messages
This tail command will display the last 10 lines in the file, and then additional lines within a second of the time that they are appended to the file. It can be left running in a terminal window in the corner of the screen while you perform system administration tasks.
The syslog service was designed to facilitate remote logging. This is very useful in two circumstances:
In the event of a successful system intrusion, an attacker will often edit or delete logfiles to erase any record of his presence. If messages are logged to a remote server, it becomes more difficult to erase the trail because the attacker then needs to successfully attack the machine recording the log in addition to the system originally compromised.
In a network, it is convenient to gather logs in one place for centralized analysis. This lets you stay on top of the state of many systems from one location.
To configure a syslog network server, edit that host's /etc/sysconfig/syslog file, which initially looks like this:
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-m 0"
# Options to klogd
# -2 prints all kernel oops messages twice: once for klogd to decode, and
# once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
#
SYSLOG_UMASK=077
# set this to a umask value to use for all logfiles, as in umask(1).
# By default, all permissions are removed for "group" and "other".
Change the SYSLOGD_OPTIONS line to include -r (remote logging):
SYSLOGD_OPTIONS="-m 0 -r"
Then restart syslogd :
# service syslog restart
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Ensure that your firewall configuration permits connections on UDP port 514.
Next, edit the file /etc/syslog.conf on the machines that will be forwarding log messages to the syslog server, and add this line:
*.* @ syslogserver
This will forward all messages to the remote host syslogserver (which may be an IP address or hostname). Restart syslogd to activate the changes.
It's important to leave local logging turned on in case the syslog server is unavailable, so don't remove the lines that write to the local logfiles.
The result will be a combined log containing entries from both the syslog server and the host that is forwarding its log messages:
Jun 1 02:52:33 darkday named[13255]: starting BIND 9.3.2 -u named
Jun 1 02:52:33 darkday named[13255]: found 1 CPU, using 1 worker thread
Jun 1 02:52:33 darkday named[13255]: loading configuration from '/etc/named.conf'
Jun 1 02:52:33 darkday named[13255]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 1 02:52:33 darkday named[13255]: listening on IPv4 interface eth0, 172.16.97.100#53
Jun 1 02:52:33 darkday named[13255]: command channel listening on 127.0.0.1#953
Jun 1 02:52:33 darkday named[13255]: zone 0.in-addr.arpa/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Jun 1 02:52:33 darkday named[13255]: zone 255.in-addr.arpa/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700
Jun 1 02:52:33 darkday named[13255]: zone localdomain/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: zone localhost/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: running
Jun 1 02:57:22 bluesky chris: VNC service configured, restarting xinetd
Jun 1 02:57:29 bluesky xinetd[15394]: Exiting...
Jun 1 02:57:29 bluesky xinetd[15452]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in.
Jun 1 02:57:29 bluesky xinetd[15452]: Started working: 1 available service
Notice that this log contains entries from darkday (the syslog server) as well as from bluesky (which is forwarding log messages to darkday ). Notice also the system administrator's note on bluesky , stating the reason that xinetd was being restarted.
There's not much point in collecting all this information if the logs are never read, but reading logfiles is boring, tedious work. Fortunately, the logwatch package automates this process, sending a daily summary email to alert you to important log entries.
The daily summary is emailed to root on the local machine. Email to the root user should be redirected to a specific user or users by the /etc/aliases file. Edit this file and uncomment the entry for root found at the the end, inserting the name of a user who is responsible for administering the system (or a list of people separated by commas). In this example, all mail for root is redirected to [email protected] :
# Person who should get root's mail
root: [email protected]
Here is a typical daily logwatch summary:
From: root <[email protected]>
Subject: LogWatch for bluesky.fedorabook.com
Date: Wed, 31 May 2006 04:02:17 -0400
################### LogWatch 7.1 (11/12/05) ####################
Processing Initiated: Thu Jun 1 02:52:14 2006
Date Range Processed: yesterday ( 2006-May-31 )
Period is day.
Detail Level of Output: 10
Type of Output: unformatted
Logfiles for Host: bluesky.fedorabook.com
##################################################################
--------------------- httpd Begin ------------------------
A total of 3 unidentified 'other' records logged
GET /level/16/exec/-///pwd HTTP/1.0 with response code(s)
2 404 responses
POST /garethjones/photos/--WEBBOT-SELF-- HTTP/1.0 with response code(s)
1 404 responses
GET http://bluesky.fedorabook.com/foo HTTP/1.1 with response code(s)
1 404 responses
---------------------- httpd End -------------------------
--------------------- SSHD Begin ------------------------
Users logging in through sshd:
chris:
172.16.97.2: 3 times
--------------------- SSHD End -------------------------
--------------------- Disk Space Begin ------------------------
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/main-root 9.5G 2.9G 6.1G 33% /
/dev/hda1 99M 9.7M 84M 11% /boot
/dev/mapper/main-home 4.9G 24M 4.7G 1% /home
---------------------- Disk Space End -------------------------
###################### LogWatch End #########################
This report will vary according to the services you have installed, but it provides a simple, easy-to-scan summary of log entries that may warrant attention. It also provides a summary of free disk space; if you methodically review these email messages, you won't be caught unaware when your storage needs start to inch upward.
Logfiles can grow to be massive. The Fedora logrotate package automatically moves historical log data into history files and keeps a limited number of history files on hand.
logrotate is configured through the master configuration file /etc/logrotate.conf :
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) logfiles after rotating old ones
create
# uncomment this if you want your logfiles compressed
#compress
# RPM packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
# system-specific logs may be also be configured here.
The most frequently altered lines are highlighted in bold: logrotate is initially configured to rotate logs every week and to save the last four historical logfiles in addition to the current log. If you have a lot of storage and wish to keep more history, edit the rotate line to increase the number of history files maintained, or change the weekly line to monthly to reduce the frequency of history snapshots (which can make it easier to analyze patterns over a longer period of time without merging data from several files).
The default configuration results in five separate message files being present on the system:
$ ls -l /var/log/messages*
-rw------- 1 root root 86592 Jun 1 02:49 /var/log/messages
-rw------- 1 root root 85053 May 30 02:03 /var/log/messages.1
-rw------- 1 root root 105491 May 26 23:51 /var/log/messages.2
-rw------- 1 root root 74062 May 7 04:12 /var/log/messages.3
-rw------- 1 root root 286194 May 2 13:00 /var/log/messages.4
logrotate also uses per-logfile configuration files in /etc/logrotate.d. These files are installed by various RPM packages that generate logfiles.
The main system logging utility is named syslog . It is network-based and uses a server daemon, syslogd , which receives messages from all sorts of system programs through the Unix domain socket /var/log . These messages are matched against the lines in /etc/syslog.conf and written to the selected destinations.
Kernel messages are stored in a buffer that is read by a helper daemon named klogd , either by reading the file /proc/kmesg or by using a kernel system call. klogd then forwards these messages to syslogd for inclusion in the system logs.
A syslog network server listens to UDP port 514 and processes any messages received there through the normal routing decisions.
One significant problem with the syslog implementation is that there is absolutely no authentication performed. Any application can log any message with any facility and priority. Therefore it is relatively easy to spoof log messages or to create a denial-of-service attack by sending huge numbers of logfile entries, eventually filling all available disk space and making it impossible to log further events. (For this reason, it is a good idea to use a separate filesystem for /var/log ).
The logwatch and logrotate programs are activated by cron through their entries in /etc/cron.daily .
The standard Fedora syslog program does not support output to a program such as a mailer. However, you can easily write a script that reads a logfile using the tail command and outputs new log entries to a program.
This example emails log messages to a pager or cell phone text service:
#!/bin/bash
DESTINATION=[email protected]
tail -0f /var/log/messages|
while read LINE
do
echo $LINE|
mail $DESTINATION
done
To use this script, place it in the file / usr/local/bin/log-mail and add read and execute permissions:
# chmod u+rx /usr/local/bin/log-mail
# log-mail
You may want to use this script with a lower-volume logfile than /var/log/messages, especially if you pay for each pager message.
To filter messages by content, place a grep command between the tail and while lines in the script.
You can also have log output read to you over the system's speakers:
#!/bin/bash
logger -t log-speak "Starting log reading."
sleep 0.3
tail -1f /var/log/messages|
while read LINE
do
# The sed expressions remove the date/time and PIDs
# from messages to shorten the text.
echo $LINE|
sed -e "s/^.\{17\}[^ ]*//" -e "s/\[.*\]//g"|
festival --tts
done
A named pipe is a special type of file that can be used to pass messages between two programs. While syslog supports writing to named pipes, the default SELinux security policy prohibits it.
To output to a named pipe, you must first disable SELinux protection for syslogd by setting the syslogd_disable_trans boolean and then create the named pipe with mkfifo :
# setsebool -P syslogd_disable_trans=1
# mkfifo /var/log/messagepipe
Next, create an entry in /etc/syslog.conf , placing a pipe symbol in front of the destination pathname:
*.* |/var/log/messagepipe
Restart syslogd . You can then follow the message output with a simple file read:
# service syslog restart
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
# cat /var/log/messagepipe
...(Messages appear as they are logged)...
Most network hardware offers the option of logging messages to a syslog server. Simply enter the IP address of your syslog network server into the configuration settings of the device.
The syslog-ng package from Fedora Extras can be used in place of the standard syslogd and klogd programs. It uses a different configuration file syntax, and it supports message-text matching and message routing to programs.
The original syslogd and klogd programs are from the package sysklogd.
The manpages for syslogd , syslog.conf , klogd , logrotate , and logwatch
The home page for logwatch : http://www.logwatch.org
The Advanced Intrusion Detection Environment (AIDE) is a program that takes a "fingerprint" of system files so that changes in those files can be detected. You can use it to detect a system intrusion, accidental file overwrites, and file corruption.
To initialize the AIDE fingerprint database, execute it with the --init option:
# aide --init
AIDE, version 0.11
### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
It will take several minutes to run. When it is finished, a fingerprint database will be saved as /var/lib/aide/aide.db.new.gz . Rename it to /var/lib/aide/aide.db.gz to make it the active AIDE database:
# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Once the fingerprint database is configured, you can check for file changes using the --check argument:
# aide --check
AIDE found differences between database and filesystem!!
Start timestamp: 2006-06-01 12:50:01
Summary:
Total number of files: 127172
Added files: 2
Removed files: 0
Changed files: 4
---------------------------------------------------
Added files:
---------------------------------------------------
added:/root/.xauth0VekVw
added:/root/.xauthcvqPrt
---------------------------------------------------
Changed files:
---------------------------------------------------
changed:/root
changed:/root/.lesshst
changed:/bin
changed:/bin/date
--------------------------------------------------
Detailed information about changes:
---------------------------------------------------
Directory: /root
Mtime : 2006-06-01 09:51:05 , 2006-06-01 11:43:23
Ctime : 2006-06-01 09:51:05 , 2006-06-01 11:43:23
File: /root/.lesshst
Mtime : 2006-06-01 10:57:21 , 2006-06-01 12:47:34
Ctime : 2006-06-01 10:57:21 , 2006-06-01 12:47:34
Directory: /bin
Mtime : 2006-03-21 00:18:37 , 2006-06-01 12:49:18
Ctime : 2006-03-21 00:18:37 , 2006-06-01 12:49:18
File: /bin/date
Size : 54684 , 2003
Bcount : 128 , 16
Permissions: -rwxr-xr-x , -rws--x--x
Mtime : 2006-02-11 01:43:13 , 2006-06-01 12:49:18
Ctime : 2006-03-21 00:11:18 , 2006-06-01 12:49:32
Inode : 1986165 , 1977386
MD5 : sGkOBZz1ixmfifDWyS5PNw== , RUhh+HqFShK4bABDxePEtw==
SHA1 : mY4z3oD64L+e36a7s2LQ32E4k+8= , NAkwd0kI05k8svWFerYN5k8C1t0=
A copy of this report is automatically saved in /var/log/aide.log.
In this case, AIDE has detected a change in /bin/date and in /root/.lesshst (the history for the less command). The change to date is of particular note because that is a commonly used program, and the new version is configured with the set-user-ID bit set, meaning that any user typing date will execute a program with superuser privileges.
Since some files are expected to change in specific ways, the qualities that AIDE checks for each file and directory are configurable. Table 8-6 summarizes the default configuration.
Table 8-6. Default AIDE fingerprint configuration
| Pathnames | Fingerprint qualities |
|---|---|
| /boot/bin/sbin/lib/opt/usr /root/etc/exports/etc/fstab/etc/passwd/etc/group/etc/gshadow/etc/shadow | Permissions inode number Number of links UserGroupSize Time of last modification Time of creation or last inode modification Block count MD5 checksum SHA1 checksum |
| All other files in /etc (except /etc/mtab, which is not checked) | Permissions inode number UserGroup |
| /var/log | Permissions Number of links UserGroup |
AIDE is configured using the text file /etc/aide.conf ; the default contents of this file are:
# Sample configuration file for AIDE.
@@define DBDIR /var/lib/aide
# The location of the database to be read
database=file:@@{DBDIR}/aide.db.gz
# The location of the database to be written
#database_out=sql:host:port:database:login_name:passwd:table
#database_out=file:aide.db.new
database_out=file:@@{DBDIR}/aide.db.new.gz
# Whether to gzip the output to database
gzip_dbout=yes
# Default
verbose=5
report_url=file:/var/log/aide.log
report_url=stdout
#report_url=stderr
#NOT IMPLEMENTED report_url=mailto:[email protected]
#NOT IMPLEMENTED report_url=syslog:LOG_AUTH
# These are the default rules
#
#p: permissions
#i: inode:
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#md5: md5 checksum
#sha1: sha1 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#haval: haval checksum
#gost: gost checksum
#crc32: crc32 checksum
#R: p+i+n+u+g+s+m+c+md5
#L: p+i+n+u+g
#E: Empty group
#>: Growing logfile p+u+g+i+n+S
# You can create custom rules like this
NORMAL = R+b+sha1
DIR = p+i+n+u+g
# Next decide what directories/files you want in the database
/boot NORMAL
/bin NORMAL
/sbin NORMAL
/lib NORMAL
/opt NORMAL
/usr NORMAL
/root NORMAL
# Check only permissions, inode, user and group for /etc, but
# cover some important files closely
/etc p+i+u+g
!/etc/mtab
/etc/exports NORMAL
/etc/fstab NORMAL
/etc/passwd NORMAL
/etc/group NORMAL
/etc/gshadow NORMAL
/etc/shadow NORMAL
/var/log p+n+u+g
# With AIDE's default verbosity level of 5, these would give lots of
# warnings upon tree traversal. It might change with future versions.
#
#=/lost\+found DIR
#=/home DIR
Most of this file consists of selection lines , which contain two fields. The first field is used to specify files to process or, if prepended with ! , files to exclude from processing. This field is evaluated as a regular expression, so the pattern /lib will match any filename starting with /lib , including files such as /lib/lsb/init-functions .
These regular expressions are treated as if they have ^ prepended (they match only at the start of filenames). To exactly match one filename, append $:
/var/log/messages$ >
The $ prevents this selection line from matching the logrotate history files (such as /var/log/messages.1).
The second field is a list of fingerprint qualities, drawn from the list included in the file as comments, separated with + characters. The values NORMAL and DIR are configured as group definitions, permitting easy reference to commonly used combinations of fingerprint qualities. In this case, NORMAL is defined as R+b+sha1 , meaning the predefined fingerprint-qualities group R , block count, and SHA1 checksums. R in turn means permissions, inode number, number of links, user, group, size, modification time, creation/inode change time, and MD5 checksum.
To add additional files to be fingerprinted, append entries to this file. For example, to verify that your web pages have not changed, append:
/var/www/html NORMAL
AIDE works by recording the fingerprint qualities in its database file as plain text (though the file is normally compressed using gzip ). Here is a sample of a fingerprint database:
@@begin_db
# This file was generated by Aide, version 0.11
# Time of generation was 2006-06-01 10:57:23
@@db_spec name lname attr perm bcount uid gid size mtime ctime inode lcount md5 sha1
/etc 0 541 40755 0 0 0 0 0 0 713153 0 0 0
/sbin 0 4029 40755 32 0 0 12288 MTE0MjkxODMyMg== MTE0MjkxODMyMg== 1880129 2 0 0
/root 0 4029 40750 16 0 0 4096 MTE0OTE2OTg2NQ== MTE0OTE2OTg2NQ== 1296641 8 0 0
/usr 0 4029 40755 16 0 0 4096 MTE0Mjg5MjIzOA== MTE0Mjg5MjIzOA== 1782881 14 0 0
...(Lines snipped)...
/boot/grub/grub.conf 0 16317 100600 4 0 0 599 MTE0Mjg5NTcwNw== MTE0Mjg5NTcwNw== 2011 1 zvjoV7HEEv/lHBdWPRNK9g== xJ2OrD9u9dqn9n3M2y/iKgxzoHk=
/boot/grub/reiserfs_stage1_5 0 16317 100644 20 0 0 9056 MTE0Mjg5NTcwOA== MTE0Mjg5NTcwOA== 2022 1 3QMuqfoxpKu/nMsBGE554Q== 6fWY3Yrk7M4+aW0voaqzOIxyQY8=
/boot/grub/jfs_stage1_5 0 16317 100644 18 0 0 8032 MTE0Mjg5NTcwOA== MTE0Mjg5NTcwOA== 2020 1 6favoJt1WCIN/dnckuHbfQ== aIlm2nFM9bVJSaE/rwLYehLgpRQ=
@@end_db
When run with the -C option, aide simply calculates a new fingerprint and compares the value with the old fingerprint, reporting any discrepancies.
This is a very real possibility. To guard against this, the fingerprint database should be recorded on read-only media (such as a CD-R), stored on a different system, or stored on removable media that the system administrator can secure against alteration.
To automate daily AIDE scans, create the file /etc/cron.daily/50aide with these contents:
#!/bin/bash
/usr/sbin/aide --check 2>&1|mail -s "AIDE scan results" root
Make the file executable by root :
# chown root /etc/cron.daily/50aide
# chmod u+rx /etc/cron.daily/50aide
An AIDE scan will then be performed daily, and the results will be mailed to root on the local system (or the user who receives root mail, as defined in /etc/aliases ).
The manpages for aide and aide.conf
The AIDE online manual: http://www.cs.tut.fi/~rammer/aide/manual.html