Securelevels

securelevel(7) is a kernel setting to restrict actions the system can perform. The kernel behaves slightly differently as you raise the securelevel. For example, at low securelevels, the file flags discussed in the previous section can be removed; a file might be marked immutable, but you can remove the marker, delete or edit the file, and restore the flag. When you increase the securelevel, however, you can no longer remove the flag. Similar changes take place in other parts of the system. Taken as a whole, these changes might frustrate or stop an intruder.

Securelevel settings range from -1 to 2. Though OpenBSD runs at securelevel 1 by default, you can change this setting to fit your environment.

Higher securelevels make system maintenance difficult. Many actions taken during normal upgrades and administration are also things that intruders might do to cover their tracks. It might make sense for you to run a highly secure, stable server at securelevel 2, and run your experimental machine at -1. On the other hand, the OpenBSD folks don’t encourage changing from the default securelevel. Running your system at -1 may leave you open to attacks, while running at 2 complicates management and maintenance. Which securelevel you choose depends on your environment.

Despite the name, a securelevel is not an all-purpose general security dial. Arbitrarily increasing the securelevel will do nothing but annoy you and your users. While you can increase the securelevel at any time, you cannot reduce the securelevel without rebooting the system, so don’t experiment blindly.

Setting the System Securelevel

Set the boot-time securelevel in /etc/rc.securelevel. In that file, you’ll find a line like this:

securelevel=1

Change the 1 to your preferred securelevel. On your next reboot, the system will go to this securelevel when it enters multiuser mode. If you need to run a process before the boot process raises the securelevel, put the command to start the process in this file.

If you want to raise the securelevel without rebooting, adjust the kern.securelevel sysctl(3) to the desired value.

# sysctl kern.securelevel=2
kern.securelevel: 1 -> 2

Remember that you cannot lower the securelevel of a running system. If a sysadmin could lower the securelevel, so could an intruder.

Securelevel Definitions

OpenBSD has four securelevels: -1, 0, 1 and 2. We’ll cover each in turn.

Securelevel -1

Securelevel -1 is also called permanently insecure mode. The system isn’t necessarily insecure—it’s just that none of the securelevel protections are in place. I use securelevel -1 only to remove file flags that I never should have used in the first place.

Securelevel 0

Securelevel 0 is used only when the system is first booting. It offers no special features. When the system reaches multiuser mode, however, the securelevel is automatically raised to 1. Setting securelevel=0 in /etc/rc.securelevel is functionally equivalent to setting securelevel=1.

Securelevel 1

At securelevel 1, OpenBSD’s default, things become interesting.

The securelevel affects certain kernel configuration settings, called sysctls (covered in Chapter 18). Early in the boot process, OpenBSD uses the settings in /etc/sysctl.conf to set sysctls. When I say that a particular sysctl cannot be changed, read that as “without altering the configuration and rebooting.”

Securelevel 1 implements the following limitations:

  • No one can write to the /dev/mem and /dev/kmem devices. Many security exploits work by writing to these devices.

  • The raw disk devices of all mounted file systems are read-only. (Writing to the raw devices of mounted filesystems would let you change files without regard to permissions.) Programs should access mounted filesystems only through the filesystem anyway, so this won’t change day-to-day operations.

  • The system-level file flags schg and sappnd cannot be removed.

  • Kernel modules cannot be loaded or unloaded. OpenBSD supports kernel modules, but the default kernel is monolithic. There’s no legitimate reason to load a kernel module on a running production system.

  • The sysctl fs.posix.setuid cannot be changed. By default, chown(1) clears the setuid and setgid bits on files when changing file permissions, as per the POSIX standard. You can override this by setting fs.posix.setuid to 0.

  • The sysctl hw.allowpowerdown cannot be changed. This controls the power button’s interaction with the system. When it’s set to 1, briefly pressing the power button shuts down the system cleanly. When it’s set to 0, the power button does not shut down the system. (You can still shut down the system by holding down the power button for several seconds, but that’s not a clean shutdown.) Not all platforms support this kind of shutdown or power management.

  • The sysctl net.inet.ip.sourceroute cannot be changed. Source routing is a technique to permit the sender of a packet to control which route the packet takes across the network. It’s caused many security problems, and its use is generally discouraged. OpenBSD ignores source routing by default. Setting net.inet.ip.sourceroute to 1 forces OpenBSD to pay attention to source routing.

  • The sysctl machdep.kbdreset cannot be changed. When set to 1, machdep.kbdreset allows the system to be cleanly rebooted using CTRL-ALT-DELETE. When this sysctl is set to 0, the system ignores CTRL-ALT-DELETE.

  • The ddb.console and ddb.panic sysctls may not be raised. Raising these sysctls enables certain kernel debugging options. Unauthorized users with physical access could gain unlimited system access through the debugger if they could raise these sysctls.

  • The sysctl machdep.allowaperture cannot be raised. If you want to use the X Window System (discussed in Chapter 17), you must allow X access to specific parts of kernel memory by enabling this sysctl early during the boot process. If you’re not running X, no one legitimately needs this access.

  • General-purpose input/output (GPIO) controllers cannot be further configured. GPIO controllers support a wide variety of special-purpose hardware. See gpio(4) and gpioctl(8) for details on each.

These limitations have little effect on normal day-to-day operations, but they can interfere with debugging. If you’re trying to discover why your GPIO device isn’t working, you probably want to set your securelevel to -1.

Securelevel 2

Securelevel 2 is the highest securelevel in OpenBSD, and it disables a variety of features that you might need during normal maintenance. Use securelevel 2 only on a stable machine that you don’t expect to change much. If you need to change anything restricted by securelevel 2, you must reboot the machine.

Securelevel 2 includes everything from securelevel 1, plus the following:

  • Raw disk devices are always read-only. You cannot format, fdisk, or disklabel disks, even if they’re not in use.

  • The system clock cannot be moved backward, nor close to the overflow point. Make sure your system time is correct before entering multiuser mode!

  • You cannot alter packet-filtering rules (covered in Chapter 21 and Chapter 22). Packet filters, network address translation (NAT), traffic queues, and so on are immutable.

  • Kernel debugger sysctl values (those beginning with ddb) cannot be changed.

So, for example, you don’t want your firewall at securelevel 2 unless you understand that packet filtering rules can change only with a reboot.

What Securelevel Do You Need?

The securelevel appropriate for your environment depends entirely on your situation, but the overwhelming majority of the time, the default of securelevel 1 is most suitable.

If you are debugging and testing features and tools, you might find that you need to use securelevel -1 on a development machine. Once you’ve worked out how to configure your GPIO device or the correct debugger settings for your system, however, use securelevel 1 so that you mirror a production environment.

If you have a very stable system, you could try securelevel 2. In all my years of running OpenBSD, though, I’ve had only one system for which securelevel 2 was the right choice, and several cases where securelevel 2 created more trouble than it was worth.

Securelevel Weaknesses

What can’t securelevels do? Consider a case where someone compromises a web application on your server, uses that to bootstrap himself into a shell, and then uses the shell to bootstrap himself into root access. Securelevels don’t do anything to prevent this.

Unless you’ve made copious use of the schg flag, the intruder can replace system binaries with ones that send your authentication credentials to a free email account registered in a bogus name. So you decide to run around applying the schg flag to the contents of critical directories like /bin and /usr/lib. That will stop the bugger! Well, that will work as long as you make every file immutable, including the system configuration files in /etc —you know, the ones that you need to change in order to do your job. If you leave one file unprotected, the intruder could add a command like chflags -R noschg / to an early part of the system startup, and poof—the next time you reboot your system, you unlock all your files. How often do you exhaustively audit your /etc files? And you’ll need to undo this tangled morass every time you patch or upgrade your system!

This is only one possible path. There are many ways for an intruder to lever himself into the system. Relying on securelevels to protect you is unwise. Use them and consider them a tool in your kit, but don’t think they are a panacea for every problem.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.35.58