Section 14.2. Preparation and Planning

14.2. Preparation and Planning

Before writing our policy module, we need to gather some information about the applications, create a test configuration, and specify our security goals. We also must choose our target platform and policies. For our example, we target an FC4 system and create policy modules for the example strict policy (see Chapter 11) and a strict reference policy (see Chapter 12).

14.2.1. Gathering Application Information

Like all policy modules, our IRC module is primarily about creating a domain for the IRC daemon. Writing the policy module will require as much information as possible about how this daemon is designed and functions. In general, the better we understand the target application, the better the security and functionality of the resulting policy. Of particular importance is the application architecture (for example, number and purpose of processes and resources), administration (for example, documentation of configuration files), and existing security information. Existing information about the security of the applications, including hardening guidelines, can prove helpful. Be warned, however, that security guidelines often do not give the full picture of the application security or necessarily meet your specific security needs.

Here is a sample of the information we collected about the Hybrid IRC daemon, which is standard for FC4:

• The daemon consists of a single process that listens for incoming IRC connections on port 6667.

• The IRC protocol (originally described in RFC 1459) is normally implemented on top of TCP, and there is a single connection per client.

• A number of configuration files are stored, by default, under /etc/ircd/.

• By default, the IRC daemon has private log files stored under /var/log/ircd/.

• The FC4 RPMs create a data directory for the IRC daemon under /var/lib/.

• Like most daemons configured for FC, the IRC daemon creates files in /var/run/ storing the PID of the active daemon process while running.

• Other than the logs, PID, /var/lib/, and configuration files and directories, the IRC daemon does not require any other significant filesystem access.

14.2.2. Creating a Test Environment

Writing policy modules requires testing and (in many cases) experimentation. Therefore, we need a test installation of the service on a system configured for policy development. Like all testing, it is important that the test environment match the deployment environment as closely as possible. For our purposes, we create a basic example IRC daemon installation on FC4. We also need a test system with an IRC client on the same network.

We start with a basic workstation installation of FC4, to which we need to add the example and reference policy source files and the IRC daemon. Appendix A, "Obtaining SELinux Sample Policies," provides instructions on how to obtain and install the required strict example policy and reference policy. The IRC daemon is installed with the following yum command. (As root running with the security root:sysadm_r:sysadm_t, for example, log in and su to root on a standard FC4 system.)

# yum install ircd-hybrid

This installs the IRC daemon, startup scripts, and example configuration files. We are now ready to edit the configuration file /etc/ircd/ircd.conf. We start with the file simple.conf provided in the documentation (/usr/share/doc/ircd-hybrid-7.2.0/simple.conf) and modify it slightly (the server info sid and the operator password options), as shown in Listing 14-1 (changed options are bolded).

Listing 14-1. Modified IRC Daemon Configuration File (ircd.conf)

1      # Hybrid 7 minimal example configuration file 2      # 3      # $Id: simple.conf 33 2005-10-02 20:50:00Z knight $ 4      # 5      # This is a basic ircd.conf that will get your server running with 6      # little modification.  See the example.conf for more specific 7      # information. 8      # 9      # The serverinfo block sets your server's name.  Fields that may 10     # be set are the name, description, vhost, network_name, 11     # network_desc,  and hub. 12 13     serverinfo { 14        name = "irc.example.com"; 15         sid = "1se"; 16         description = "Test IRC Server"; 17         hub = no; 18     }; 19 20     # The administrator block sets up the server administrator 21     # information, that is shown when a user issues the /ADMIN 22     # command.  All three fields are required. 23 24     administrator { 25         description = "Example, Inc Test IRC Server"; 26         name = "John Doe"; 27         email = "[e-mail]"; 28     }; 29 30     # Class blocks define the "privileges" that clients and servers 31     # get when they connect.  Ping timing, sendQ size, and user 32     # limits are all controlled by classes.  See example.conf for 33     # more information 34 35     class { 36         name = "users"; 37         ping_time = 90; 38         number_per_ip = 0; 39         max_number = 200; 40         sendq = 100000; 41      }; 42 43     class { 44         name = "opers"; 45         ping_time = 90; 46         number_per_ip = 0; 47         max_number = 10; 48         sendq = 500000; 49     }; 50 51     # Auth blocks define who can connect and what class they 52     # are put into. 53 54     auth { 55         user = "*@*"; 56         class = "users"; 57     }; 58 59     # Operator blocks define who is able to use the OPER command 60     # and become IRC operators. The necessary fields are the 61     # user@host, oper nick name, and the password, encrypted with 62     # the mkpasswd program provided. 63 64     operator { 65         name = "JohnDoe"; 66         user = "*@*.example.com"; 67         # MD5 encrypted password - "selinux" 68         password = "$1$gv.dyLcq$wr2F.9AqZ/2EKxcsCexKm1"; 69         encrypted = yes; 70         class = "opers"; 71     }; 72 73     # Listen blocks define what ports your server will listen to 74     # client and server connections on. ip is an optional field 75     # (Essential for virtual hosted machines.) 76 77     listen { 78         port = 6667; 79     }; 80 81     # Quarantine blocks deny certain nicknames from being used. 82 83     quarantine { 84         nick = "dcc-*"; 85         reason = "DCC bots are not permitted on this server"; 86     }; 87 88     quarantine { 89         nick = "LamestBot"; 90         reason = "You have to be kidding me!"; 91     }; 92 93     quarantine { 94         nick = "NickServ"; 95      reason = "There are no Nick Services on this Network"; 96     }; 97 98     # The general block contains most of the configurable options 99     # that were once in config.h. The most important ones are below. 100    # For the rest, please see example.conf. Note that variables not 101    # mentioned here are set to the ircd defaults, which are listed in 102    # src/s_conf.c:set_default_conf. 103 104    general { 105        hide_spoof_ips = yes; 106        # Identd is commonly disabled on modern systems 107        disable_auth = yes; 108        # Control nick flooding 109        anti_nick_flood = yes; 110        max_nick_time = 20; 111        max_nick_changes = 5; 112 113        # Show extra warnings when servers connections cannot succeed 114        # because of no "N" line (a misconfigured connect block) 115        warn_no_nline = yes; 116    };

Tip

For policy development, it is important to understand all the files and directories that are part of an application. The command rpm -ql ircd-hybrid will list the files and directories installed as part of the IRC daemon package.

The three changes that we make to this file are to change the unique identifier of the server (line 15), the administrative password (line 68), and disable the use of identd (line 107). After saving this file as /etc/ircd/ircd.conf, we start the server (for now, on a permissive mode SELinux FC4 system) with the following command:

# setenforce 0 # /etc/init.d/ircd start Starting ircd: ircd: version hybrid-7.2.0 ircd: pid 9052 ircd: running in background mode from /usr/lib/ircd [  OK  ]

These commands show the ircd service starting successfully. Once started, the log file /var/log/ircd/ircd.log should contain the following entry (at or near the end):

[2006/2/3 04.25] Server Ready

Note that there may be some access vector cache (AVC) messages generated because we have not yet installed a specific policy for the server. We can ignore them for now.

14.2.3. Specifying Security Goals

The last preparation step is to specify the security goals for our IRC policy module. Without understanding what security means for this application, we have no basis for making security-critical decisions during the development of our policy module proverb. This is our chance to think about the overall security concerns before we become immersed in the many details of the policy language. (Or in the words of the proverbial saying, let's examine the "forest" before we are overwhelmed by the "trees.") We will revisit these security goals after creating our policy module to determine whether we meet our objectives (to determine whether our forest is what we expected after we spend all our time planting trees).

How to correctly determine and specify security goals is a large topic itself, beyond the scope of this book. It comes mostly with experience and the correct mind set. Following are some security goals for a basic policy module for our IRC daemon:

• ircd service confinement Confine the ircd service to the minimum amount of access required to function properly. This will prevent an exploitable flaw in the service from being used to compromise the entire system.

• System protection Protect the system from the IRC service to prevent privilege escalation through exploiting IRC.

• Configuration file protection Protect the configuration files from modification by nonadministrative domains (for example, domains other than sysadm_t) and the service itself.

These security goals are just a starting point. Many other security goals are possible for an IRC daemon or similar applications.