From c399c5040860ae445a5436cd614ab453feba75d5 Mon Sep 17 00:00:00 2001 From: Dru Lavigne Date: Mon, 31 Mar 2014 17:01:17 +0000 Subject: [PATCH] White space fix only. Translators can ignore. Sponsored by: iXsystems --- .../books/handbook/mac/chapter.xml | 303 +++++++++--------- 1 file changed, 152 insertions(+), 151 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml index d7c13ede94..61436bb259 100644 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml @@ -1414,15 +1414,13 @@ test: biba/low This section demonstrates the steps that are needed to implement the Nagios network - monitoring system in a MAC environment. - This is meant as an example which still requires the administrator - to test that the implemented policy meets the security - requirements of the network before using in a - production environment. + monitoring system in a MAC environment. This + is meant as an example which still requires the administrator to + test that the implemented policy meets the security requirements + of the network before using in a production environment. - This example requires - to be set on each file system. It also - assumes that + This example requires to be set + on each file system. It also assumes that net-mgmt/nagios-plugins, net-mgmt/nagios, and www/apache22 are all installed, configured, @@ -1459,12 +1457,13 @@ test: biba/low :ignoretime@:\ :label=biba/10(10-10): - Then, add the following line to the default user class section: + Then, add the following line to the default user class + section: :label=biba/high: - Save the edits and issue the following command to rebuild the - database: + Save the edits and issue the following command to rebuild + the database: &prompt.root; cap_mkdb /etc/login.conf @@ -1478,22 +1477,21 @@ test: biba/low &prompt.root; pw usermod root -L default All user accounts that are not root will now - require a login class. The login class is required, otherwise - users will be refused access to common commands. - The following sh script should - do the trick: + class="username">root will now require a login + class. The login class is required, otherwise users will be + refused access to common commands. The following + sh script should do the trick: &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ /etc/passwd`; do pw usermod $x -L default; done; - Next, drop the nagios - and www accounts into - the insecure class: + Next, drop the nagios and www accounts into the insecure + class: &prompt.root; pw usermod nagios -L insecure &prompt.root; pw usermod www -L insecure - @@ -1528,8 +1526,8 @@ test: biba/low # For apache /usr/local/etc/apache(/.*)? biba/10 - This policy enforces security by setting restrictions - on the flow of information. In this specific configuration, + This policy enforces security by setting restrictions on + the flow of information. In this specific configuration, users, including root, should never be allowed to access Nagios. @@ -1537,14 +1535,14 @@ test: biba/low Nagios will be completely self contained or jailed. - This file will be read after running + This file will be read after running setfsmac on every file system. This example sets the policy on the root file system: &prompt.root; setfsmac -ef /etc/policy.contexts / - Next, add these edits - to the main section of /etc/mac.conf: + Next, add these edits to the main section of + /etc/mac.conf: default_labels file ?biba default_labels ifnet ?biba @@ -1557,15 +1555,16 @@ default_labels socket ?biba To finish the configuration, add the following lines to /boot/loader.conf: - + mac_biba_load="YES" mac_seeotheruids_load="YES" security.mac.biba.trust_all_interfaces=1 - And the following line to the network card configuration stored - in /etc/rc.conf. If the primary network - configuration is done via DHCP, this may - need to be configured manually after every system boot: + And the following line to the network card configuration + stored in /etc/rc.conf. If the primary + network configuration is done via DHCP, + this may need to be configured manually after every system + boot: maclabel biba/equal @@ -1580,13 +1579,13 @@ security.mac.biba.trust_all_interfaces=1 First, ensure that the web server and Nagios will not be started on system initialization and reboot. Ensure that root cannot access any of - the files in the Nagios - configuration directory. If root can list the contents of - /var/spool/nagios, something - is wrong. Instead, a permission denied error - should be returned. + class="username">root cannot access any of the + files in the Nagios configuration + directory. If root + can list the contents of + /var/spool/nagios, something is wrong. + Instead, a permission denied error should be + returned. If all seems well, Nagios, Apache, and @@ -1597,9 +1596,9 @@ setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl star setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart Double check to ensure that everything is working - properly. If not, check the log files for error messages. - If needed, use &man.sysctl.8; to disable the &man.mac.biba.4; security - policy module and try starting everything again as + properly. If not, check the log files for error messages. If + needed, use &man.sysctl.8; to disable the &man.mac.biba.4; + security policy module and try starting everything again as usual. @@ -1633,141 +1632,143 @@ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart - The flag does not stay + The flag does not stay enabled on the root (/) partition: - - The following steps may resolve this transient - error: + + The following steps may resolve this transient + error: - - - Edit /etc/fstab and set the - root partition to for - read-only. - + + + Edit /etc/fstab and set the + root partition to for + read-only. + - - Reboot into single user mode. - + + Reboot into single user mode. + - - Run tunefs on /. - + + Run tunefs on /. + - - Reboot the system. - + + Reboot the system. + - - Run mount - / and change the - back to in - /etc/fstab and reboot the system - again. - + + Run mount + / and change the + back to in + /etc/fstab and reboot the system + again. + - - Double-check the output from - mount to ensure that - has been properly set on the - root file system. - - - - + + Double-check the output from + mount to ensure that + has been properly set on + the root file system. + + + + After establishing a secure environment with - MAC, - Xorg no longer starts: - - 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: + MAC, Xorg no + longer starts: + + 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. - + + + 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 that the label policies - are set correctly for the user, Xorg, - and the /dev - entries. - + + Double-check that the label policies are set + correctly for the user, + Xorg, and the + /dev entries. + - - If neither of these resolve the problem, send the - error message and a description of the environment to - the &a.questions;. - - - - + + If neither of these resolve the problem, send the + error message and a description of the environment to + the &a.questions;. + + + + The _secure_path: unable to stat .login_conf error appears: - - This error can appear when a user attempts to switch from the root user to another user in - the system. This message usually occurs when the user has a higher - label setting than that of the user they are attempting to - become. For instance, if joe has a default label of - and root has a label - of , root 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. - - + + This error can appear when a user attempts to switch + from the root + user to another user in the system. This message + usually occurs when the user has a higher label setting + than that of the user they are attempting to become. + For instance, if joe has a default label + of and root has a label of + , root 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 root: - - When this occurs, - whoami returns 0 and - su returns who are - you?. + + When this occurs, whoami returns + 0 and su returns + who are you?. - This can happen if a labeling policy has been disabled - by &man.sysctl.8; or the policy module was - unloaded. If the policy is disabled, the login capabilities - database needs to be reconfigured. Double check - /etc/login.conf to ensure that all - options have been removed and rebuild - the database with cap_mkdb. + This can happen if a labeling policy has been + disabled by &man.sysctl.8; or the policy module was + unloaded. If the policy is disabled, the login + capabilities database needs to be reconfigured. Double + check /etc/login.conf to ensure + that all 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 &man.sysctl.8; and - everything should return to normal. - - - + 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 &man.sysctl.8; and everything should return + to normal. + + +