This example considers a relatively small, fewer than fifty users, storage system.
Users would have login capabilities, and be permitted to not only store data but access
resources as well.
For this scenario, the mac_bsdextended(4)
mixed with mac_seeotheruids(4)
could co-exist and block access not only to system objects but to hide user processes as
well.
Begin by adding the following lines to /boot/loader.conf:
mac_seeotheruids_enabled="YES"
The mac_bsdextended(4)
security policy module may be activated through the use of the following rc.conf
variable:
ugidfw_enable="YES"
Default rules stored in /etc/rc.bsdextended will be loaded
at system initialization; however, the default entries may need modification. Since this
machine is expected only to service users, everything may be left commented out except
the last two. These will force the loading of user owned system objects by default.
Add the required users to this machine and reboot. For testing purposes, try logging
in as a different user across two consoles. Run the ps aux
command to see if processes of other users are visible. Try to run ls(1) on another users
home directory, it should fail.
Do not try to test with the root user unless the specific
sysctls have been modified to block super user access.
Note: When a new user is added, their mac_bsdextended(4)
rule will not be in the ruleset list. To update the ruleset quickly, simply unload the
security policy module and reload it again using the kldunload(8) and kldload(8)
utilities.
