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:
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.
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.
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/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>.