Confining Privileged Processes

Flaws in privileged processes are often exploited to subvert the security of a system. The example configuration confines such processes by defining separate domains for them and restricting their accesses to least privilege. One example of such a process is sendmail. The following excerpt shows some of the permissions granted to the sendmail_t domain in which sendmail runs:

allow sendmail_t smtp_port_t:tcp_socket name_bind;
allow sendmail_t mail_spool_t:dir 
      { read search add_name remove_name };
allow sendmail_t mail_spool_t:file 
      { create read write unlink };
allow sendmail_t mqueue_spool_t:dir 
      { read search add_name remove_name };
allow sendmail_t mqueue_spool_t:file 
      { create read write unlink };

The first statement allows sendmail to bind to the SMTP port. The next two statements allow sendmail to manage the mail spool directory. The last two statements allow sendmail to manage the mail queue directory. Even if a flaw in sendmail is exploited, the set of accesses granted to the attacker is strictly limited to what is specified in the configuration.

Another example of a privileged process is ftpd. The following excerpt shows some of the permissions granted to the domain for this daemon:

allow ftpd_t wtmp_t:file append;
allow ftpd_t var_log_t:file append;
allow ftpd_t ls_exec_t:process execute;

The first statement allows ftpd to append to the wtmp file. The second statement allows ftpd to append to /var/log/xferlog. For even better protection, a separate type could be defined for this particular log file, e.g. xferlog_t, to strictly limit the daemon to that file. The last statement allows ftpd to execute the ls program. As with the sendmail example, an attacker who subverts ftpd can only perform the actions authorized by the configuration.