Securelevels


Securelevels are kernel settings that change basic system behavior to disallow certain actions. The kernel will behave slightly differently as you raise the securelevel. For example, at low securelevels the file flags we discussed can be removed. A file might be marked "do not change," but you can remove the marker and then delete or edit the file. When you increase the securelevel, the flag cannot be removed. Similar changes will take place in other parts of the system. Taken as a whole, the behavior changes that result from increased securelevels will either frustrate or stop an intruder. You can set the system securelevel at boot in /etc/rc.securelevel. Securelevel ranges from -1 to 2.

Securelevels make system maintenance difficult. After all, many actions that you might take during normal upgrades and administration are also things that intruders might do to cover their tracks or further compromise a system. You will need to adjust your use of securelevel features to fit your environment.

Despite the name, a securelevel is not an all-purpose general security dial. Turning up securelevel arbitrarily will do nothing but annoy users and administrators. Additionally, securelevels cannot be reduced without rebooting the system, so don't experiment blindly.

Setting Securelevels

Securelevels come in four levels: -1, 0, 1, and 2, with -1 being the least secure; 2 is the most secure. OpenBSD's default securelevel is 1. This value is set at boot time in /etc/rc.securelevel. Look in this file, and you will see a line like this:

 securelevel=1 

Change the 1 to your desired securelevel. The next time you reboot, the system will come back up at this securelevel. If you want to raise the securelevel without rebooting, you can adjust the kern.securelevel sysctl to your desired value.

 # sudo sysctl -w kern.securelevel=1 kern.securelevel: -1 -> 1 # 

Securelevel may not be lowered while the system is running; it can only be raised. After all, if the administrator could lower the securelevel, so could an intruder.

Securelevel -1

Securelevel -1 provides no additional kernel security whatsoever. If you're learning OpenBSD and are frequently experimenting with system features and configuration, you may want to run the system at this securelevel. The standard UNIX security features, such as permissions, are fully functional.

Securelevel 0

The only time securelevel 0 is used is when the system is first booting, and it offers no special features. When the system reaches multi-user mode, however, the securelevel is automatically raised to 1. Setting securelevel=0 in /etc/ rc.securelevel is functionally equivalent to setting securelevel=1. At securelevel 0, no special security features are in place.

Securelevel 1

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

  • Nobody may write to the /dev/mem and /dev/kmem devices. Many old security exploits relied upon being able to write to these devices.

  • The raw disk devices of all mounted file systems are read-only — all disk access must be done via standard devices. Programs should only access mounted file systems through the standard devices, anyway, so this doesn't change day-to-day operations.

  • The schg and sappnd flags cannot be removed. You will need to reboot into single-user mode to remove these flags.

  • Kernel modules cannot be loaded or unloaded. Why OpenBSD does support kernel modules, by default the kernel is monolithic, so this has very little effect on a legitimate systems administrator.

Securelevel 2

This is the highest securelevel OpenBSD offers, and it disables a variety of features that may be required during normal maintenance. These are also features that an intruder would be greatly interested in, so you may find them worthwhile. Using a high securelevel makes your system less flexible, but prevents many unauthorized changes. Securelevel 2 includes all the effects of securelevel 1, but causes the following additional changes.

  • Raw disk devices are always read-only.

  • The system clock can be set neither backward nor close to the overflow point.

  • pfctl(8) cannot alter PF or NAT rules.

  • The DDB kernel debugger sysctl values cannot be changed (see ddb(4)).

Securelevel 2 can seem irrelevant or tedious to a new systems administrator, but the features it provides can be very important. For example, intruders have used direct access to raw disks to make changes to the file system without paying attention to permissions flags on files, but setting the raw devices read-only prevents this sort of trickery. Intruders have been able to do all sorts of nifty tricks with the kernel debugger, but by making it unavailable except under the conditions the systems administrator desires these techniques are also made less useful. And once your packet filtering rules are in place and properly tuned, you should not need to change them.

Which Securelevel Do You Need?

The securelevel appropriate to your environment will depend on your situation. If you've just put an OpenBSD machine into your test environment to see what you can make it do, you might want to run at securelevel -1. I frequently run "crashboxes" at securelevel -1 just so I can make any desired change. These machines are not in production use, however.

If your system has been newly placed into production use, securelevel 1 is probably what you want. This eliminates many popular intruder techniques, but leaves the system mostly flexible.

If your system is highly secure and well tuned, use securelevel 2. Be well aware of the administrative details of this decision, however. If you're using OpenBSD as your corporate firewall, your management might not take it well if you must reboot the entire system just to make a minor rule change.

Living with Securelevels

If you've been liberal with the schg flag, you will find that you cannot upgrade or even patch your system without incurring downtime. (In many enterprise environments, network managers would rather you brought your troupe of plague-carrying rats into the office than incur downtime.) The same conditions that make an intruder's life difficult will make your job a living hell, if you don't know how to work around them.

If you've protected /etc/rc.conf and /etc/rc.securelevel with schg, you'll first have to lower the securelevel to edit your configuration. Of course, the securelevel is set in /etc/rc.securelevel, so you'll need to take control of the system before /etc/rc runs in order to edit that file. Boot into single-user mode, mount the file systems you need, and use "chflags noschg" to gain the ability to edit the files in multi-user mode. Once you finish your maintenance, you can reset the flags.




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net