Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

16.17 Troubleshooting the MAC Framework

During the development stage, a few users reported problems with normal configuration. Some of these problems are listed below:

16.17.1 The multilabel option cannot be enabled on /

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

It seems that one out of every fifty users has this problem, indeed, we had this problem during our initial configuration. Further observation of this so called “bug” has lead me to believe that it is a result of either incorrect documentation or misinterpretation of the documentation. Regardless of why it happened, the following steps may be taken to resolve it:

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

  2. Reboot into single user mode.

  3. Run tunefs -l enable on /.

  4. Reboot the system into normal mode.

  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 the mount to ensure that multilabel has been properly set on the root file system.

16.17.2 Cannot start a X11 server after MAC

After establishing a secure environment with MAC, I am no longer able to start X!

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 the cap_mkdb command. 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 in question, the X11 application, and the /dev entries.

  3. If neither of these resolve the problem, send the error message and a description of your environment to the TrustedBSD discussion lists located at the TrustedBSD website or to the FreeBSD general questions mailing list mailing list.

16.17.3 Error: _secure_path(3) cannot stat .login_conf

When I attempt to switch from the root to another user in the system, the error message “_secure_path: unable to state .login_conf”.

This message is usually shown when the user has a higher label setting then that of the user whom they are attempting to become. For instance a user on the system, 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 regardless if root has used the su command to become joe, or not. In this scenario, the Biba integrity model will not permit root to view objects set at a lower integrity level.

16.17.4 The root username is broken!

In normal or even single user mode, the root is not recognized. The whoami command returns 0 (zero) and su returns “who are you?”. What could be going on?

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 being disabled or has been temporarily disabled, then the login capabilities database needs to be reconfigured with the label option being removed. Double check the login.conf file to ensure that all label options have been removed and rebuild the database with the cap_mkdb command.

This may also happen if a policy restricts access to the master.passwd file or database. 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 via a sysctl(8) and everything should return to normal.


 
 
  Published under the terms of the FreeBSD Document Project