17.17. Troubleshooting the MAC Framework
Prev | Chapter 17. Mandatory Access Control | Next

## 17.17. Troubleshooting the MAC Framework

This section discusses common configuration issues.

- The `multilabel` flag does not stay enabled on my root (`/`) partition!

  The following steps may resolve this transient error:

  1. Edit `/etc/fstab` and set the root partition to `ro` for read-only.

  2. Reboot into single user mode.

  3. Run `tunefs` `-l enable` on `/`.

  4. Reboot the system.

  5. Run `mount` `-urw` `/` and change the `ro` back to `rw` in `/etc/fstab` and reboot the system again.

  6. 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:

  1. 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.

  2. Double-check the label policies. Ensure that the policies are set correctly for the user, the Xorg application, and the `/dev` entries.

  3. 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.

- The error: _secure_path: unable to stat .login_conf shows up.

  When a user attempts to switch from the `root` user to another user in the system, the error message _secure_path: unable to stat .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.

- The system no longer recognizes the `root` user.

  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.

Prev | Up | Next
17.16. User Lock Down | Home | Chapter 18. Security Event Auditing

This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.