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 sysctl
s have been modified
to block super user access.
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.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.