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 line to /boot/loader.conf:
mac_seeotheruids_load="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.