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.
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
0is safer, but some older software may rely on the ability to map memory at address zero. Note that changing the
map_at_zerocapability off only affects processes started after it is set, so it should be set at boot for maximum protection. The
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
processes with uid 0 have privilege
security.bsd.see_other_uids: This is actually offered as the commented-out example setting in the
sysctl.conffile; 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_gidsas well. The
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_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:
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.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.