Securelevels (sysctl kern.securelevel) provide a mechanism to limit the effects of root compromise on a running machine. In theory, the higher the securelevel, the more restricted uid 0 is. However, the current securelevel limits provide little or no protection against a root compromise beyond a single boot, as it is difficult to prevent root from modifying files that are used prior to the raising of the securelevel (such as system libraries and configuration scripts).
As part of the FreeBSD Hardening Project, we hope to identify key points of weakness in the current securelevel implementation, and attempt to make improvements. This will include:
Adding limits to currently unlimited syscalls. This would include preventing remounting of key partitions to allow write-access to read-only mounts, as well as providing a reasonable way to allow mounts of volatile volumes such as CD-ROMs inside of this framework (such as requiring all new mounts to be nosuid, nosgid, nodev). At a sufficient securelevel, possibly disabling some kernel services via /proc to prevent leakage of some runtime information.
Restricting access to configuration scripts and binaries run prior to bumping of the securelevel. The system boot begins with securelevel -1, and the securelevel is raised as the boot continues to restrict further access. The securelevel cannot be lowered. To prevent circumvention of this limitation by modifying these key scripts and binaries, their modification would be limited to securelevels where they are run (or before). For example, file-system mounting binaries run due to fstab entries during rc might be unmodifiable at securelevel 1.
To provide an easier framework for inter-securelevel behavior, it might be desirable to introduce new file flags, such as a flag that restricts write access or read access at or above a particular level. Current flags prevent modification, and cannot be removed at high securelevels. To modify the file at a low securelevel, the flag must be removed, and then reinstated after the modification. Instead, we propose a flag that prevents write at >-1 securelevel. This would reduce the administrative load of securelevels.