Use sysctl security settings to lock down a FreeBSD system

Among the many resources provided by FreeBSD's sysctl utility are a series of security settings. Learning something about them can help you protect your FreeBSD systems.

The sysctl utility on FreeBSD provides a central, simple tool for accessing a wide range of system settings -- kernel state resources, to be precise. Within its copious accessible settings is a series of a few dozen security resources. Knowing what these do can help the conscientious sysadmin lock down a system to protect it from malicious security crackers and malware. Three key examples follow.

  • security.bsd.map_at_zero: When active (set to 1), this allows user processes to map memory to address 0, which can allow users to execute code with kernel privileges through the use of a NULL pointer reference. Deactivating this capability by setting it to 0 is safer, but some older software may rely on the ability to map memory at address zero. Note that changing the map_at_zero capability off only affects processes started after it is set, so it should be set at boot for maximum protection. The sysctl description says:

    Permit processes to map an object at virtual address 0.
  • security.bsd.suser_enabled: This (set to 1) is what allows the superuser, also known as the root user, to operate with elevated privileges. Turning this off (setting it to 0) is likely to break quite a lot of expected behavior on your system, and is inadvisable. The sysctl description says:

    processes with uid 0 have privilege
  • security.bsd.see_other_uids: This is actually offered as the commented-out example setting in the sysctl.conf file; simply uncommenting it turns off the ability of user accounts to see processes owned by other user IDs at boot. Turning it off while the system is running involves setting that resource to 0; turning it on involves setting it to 1. Many consider turning off this capability a critical part of setting up a secure multiuser system, though it may also provide some insulation against privilege escalation if a malicious security cracker gains unauthorized access to a system on a system with only one authorized user. There is a group ownership equivalent called security.bsd.see_other_gids as well. The sysctl description says:

    Unprivileged processes may see subjects/objects with different real uid

The discerning reader may notice that the third of these actually discusses two resources -- security.bsd.see_other_uids and security.bsd.see_other_gids. In most cases, sysadmins are likely to either leave both turned on or turn both off, and they are very similar options, so they have been combined into a single explanation here.

To see more about the security options available on a FreeBSD system through the sysctl utility, enter this command:

sysctl security

There are two major subcategories of sysctl security resources: BSD resources, identified by bsd, and FreeBSD jail resources, identified by jail. If you are not using FreeBSD jails on your system, you can filter out the set of resources that pertain specifically to jails, reducing the number of displayed resources from around forty to only about ten (depending on your FreeBSD release version), by using this command:

sysctl security.bsd

The sysctl.conf file is mentioned above. It is located at /etc/sysctl.conf on FreeBSD systems, and can be used to specify sysctl settings that should be made during the boot process. Be careful about making changes here, however; setting something that will interfere with the operation of your system may result in the task of recovering needed functionality being very difficult indeed.