3.4. Installing OpenBSD

3.4. Installing OpenBSD

One of the hallmarks of OpenBSD is the incredibly low number of remotely exploitable vulnerabilities in the default install. As a method to this madness, the OpenBSD team has built the install process to achieve this goal: the options provided during the install are few, and security options are enabled where possible by default. What this all means is that the OpenBSD install is simple, swift, and painless. Following the prompts will get you from zero to fully functional in very little time. That said, let's move quickly through the steps.

3.4.1. Preparing the Disk

The first step in an OpenBSD installation is to indicate that you are, in fact, installing and not upgrading or in need of a shell for maintenance or recovery. Enter I for install, pick your terminal and keyboard emulation, confirm, and it's time to pick a disk and slice it up.

If you have no maintenance partition and do not plan to dual boot, you can use your entire disk for OpenBSD. Create your partitions according to the decisions you made before starting the install process, quit, and write the new disk label.

Remember, if at any time you feel lost, provide the installer ? as input. You will be provided help. You may also get the entire manpage for fdisk(8) and disklabel(8) by typing in manual or M for each application respectively.

If you have chosen to separate the most common filesystems, the installer will automatically flag your filesystems as shown in Table 3-3. This saves you a little bit of work later.

Table 3-3. Default flags for mount(8) set by the OpenBSD install

The nodev option may cause you a little grief later on if you are running a chrooted process within /var . A DNS server like named(8) for instance, chrooted in /var/named , will want to use devices like /var/named/dev/null and /var/named/dev/log . If you plan to chroot daemons in /var , you may want to remove this flag.

3.4.2. Configuring Your Network

Network connectivity during the install process is really your call, as described previously in this chapter. If you are building a server, you are unlikely to be using DHCP to configure your network interface. Provide values at the prompts and proceed.

During network setup, you will be prompted for a nameserver and whether that nameserver should be used immediately. Be sure this is a trusted resolver. The last thing you need is to be a victim of a MITM attack and directed to a malicious site when you try to download patches via FTP or cvs !

After network configuration, you are prompted to enter a root password. Make it a strong password. OpenBSD does not prompt for the creation of a new user ; we'll do that soon.

3.4.3. Choosing Your Distribution Sets

Here we are at the meat of the OpenBSD install process. At this point, you choose which file sets to install. Each set is a portion of the OpenBSD distribution and it is named according to its contents and version. Figure 3-5 shows file sets of the OpenBSD 3.5 distribution. The only required sets are the kernel ( bsd ), the base OpenBSD system ( base35.tgz ), and the files from the /etc filesystem ( etc35.tgz ). You may also want to install the compilers ( comp35.tgz ) and the manpages ( man35.tgz ).

Figure 3-5. Choosing OpenBSD 3.5 file sets

If you are building an infrastructure server, you will probably want to avoid installing any X file sets. In the case of a development server, the base install for XFree86 ( xbase35.tgz ) may be appropriate.

3.4.4. Activating sshd

After installing file sets, you are asked if you want to enable sshd(8) . The convenience of enabling sshd at this stage is high. It means you will not need to sit with a console attached to the system while you configure it. If you have been paying attention to the security mailing lists and checked the OpenBSD Errata page to ensure that sshd listening on your newly installed server is safe, leave it on.

3.4.5. An Innocuous Question About X

You are subsequently asked if you plan to run X on the system. If you're building a workstation or, heaven forbid , a multipurpose machine that might serve as someone's desktop, the answer to this may be yes. If you're building a development server so that users can launch X programs from the server but have them displayed on their system, you do not need to enable this.

Answering this question in the affirmative will modify /etc/sysctl.conf such that mdachdep.allowaperture is set to either 1 or 2 (depending on your platform). When your OpenBSD system boots after the install, the system's securelevel (7) is incremented to 1. This restricts, among other things, applications from being able write to the physical address space and I/O ports corresponding to your VGA adapter and some general PCI configuration registers. The aperture driver (see the xf86(4) manpage) /dev/xf86 was introduced to OpenBSD so that the X server can have the access it needs to this address space and these registers even when the system is running in a securelevel higher than 0.

From a security standpoint, it's important to know that the aperture driver will allow any one process to bypass the restrictions imposed by the system's security level. Usually this process is the X server, but before the X server is able to load, a malicious user or application could use this driver to do some damage. Granted, this is a not very easily exploitable window, but if you want to get rid of it altogether, answer no to this question, and do not run X.

3.4.6. Finishing Up

Finally, it is time to set your time zone and prepare to reboot your system. Before you do so however, do you know what services will be running at the end of the reboot? To find out, there are two files you will need to look at: your startup configuration file, rc.conf , currently in /mnt/etc and your system startup script /mnt/etc/rc . If you run:

#

cat /mnt/etc/rc.conf  egrep "(_flags=YES)"  grep -v =NO

You will get a list of directives that may spawn services. Results from the command above, however, do not necessarily mean a service will start. A given service may be disabled in the same configuration file by a later directive set to NO, or the service's start is dependent upon some other factor, such as the existence of a configuration file or directory in the filesystem. To determine if this is the case, look through /mnt/etc/rc for the flags directive in question and determine under which conditions the service will start.

Don't bother trying to disable syslogd(8) . By default, the system logger will not accept incoming UDP datagrams unless running with the - u ( insecure ) flag.