This section discusses common configuration issues.
multilabel cannot be enabled on /Themultilabel flag does not stay enabled on my root
(/) partition!
The following steps may resolve this transient error:
Edit /etc/fstab and set the root partition to ro for read-only.
Reboot into single user mode.
Run tunefs -l enable
on /.
Reboot the system.
Run mount -urw / and change the ro back to rw in /etc/fstab and reboot the
system again.
Double-check the output from mount to ensure that
multilabel has been properly set on the root file
system.
After establishing a secure environment with MAC, I am no longer able to start Xorg!
This could be caused by the MAC partition policy or by a mislabeling in one of the MAC labeling policies. To debug, try the following:
Check the error message; if the user is in the insecure class, the partition policy may be the culprit. Try setting the user's class back to the default class and rebuild the database with cap_mkdb. If this does not alleviate the problem, go to step two.
Double-check the label policies. Ensure that the policies are set correctly for the user, the Xorg application, and the /dev entries.
If neither of these resolve the problem, send the error message and a description of the environment to the FreeBSD general questions mailing list mailing list.
When a user attempts to switch from the root user to another user in the system, the error message “_secure_path: unable to state .login_conf” appears.
This message is usually shown when the user has a higher label setting than that
of the user they are attempting to become. For instance, joe has a default label of biba/low. The root user, who has a
label of biba/high, cannot view joe's home directory. This will happen whether or not root has used su to become joe as the Biba integrity model will not permit root to view objects set at a lower integrity level.
In normal or even single user mode, the root is not recognized, whoami returns 0 (zero), and su returns “who are you?”.
This can happen if a labeling policy has been disabled, either by a sysctl(8) or the
policy module was unloaded. If the policy is disabled, the login capabilities
database needs to be reconfigured with label removed.
Double check login.conf to ensure that all label options have been removed and rebuild the database with
cap_mkdb.
This may also happen if a policy restricts access to master.passwd. This is usually caused by an administrator altering the file under a label which conflicts with the general policy being used by the system. In these cases, the user information would be read by the system and access would be blocked as the file has inherited the new label. Disable the policy using sysctl(8) and everything should return to normal.