Document revision history
Click the “Details” toggle below for the revision history.
Details
-
1.2.2 — Add how to allow operators to use reboot and shutdown
-
1.2.1 — Simplify code block for copying root public key to AUID account
-
1.2.0 — Minor release
-
1.1.10 — Add collapsible box for document revision history
-
1.1.9 — Add reference to AUID customization document
-
1.1.8 — Remove setting ownership of AUID customization
rc
files. -
1.1.7 — Consolidate AUID setup into FSL11; set ~oper and ~prog to be readable/searchable by others; add .bashrc sudo customization scripts; make sudo customization scripts owned by the
SUDO_USER
; don’t set sysadmin's prompts to use host alias; clarify running X11 applications as root; fix automatic numbering of AUID installation steps -
1.1.6 — Correct host alias setup for refresh_spare_usr2 and backup_usr2 yet again, use ssh-keyscan to set known_hosts, make the spare system a known host for root on the operational system, add link for updating host alias in .bashrc for subsequent AUID accounts
-
1.1.5 — Cleanup: change chage
-M
parameter to-1
, explain operational and spare changes for using hostalias, fix path to ~fsl11/AUID/install_RAID script, move copying root ssh key to setting up backup_usr2, explain running X applications as root, warn about benign ./root_tmp error message, move removing AUID account time-outs to AUID account setup, wording fixes -
1.1.4 — Remove CIS password aging/expiration for desktop
-
1.1.3 — Disable oper and prog password expiration, they don’t have passwords
-
1.1.2 — Correct responses to adduser; create ~AUID/.ssh in case it doesn’t already exist
-
1.1.1 — Use backup_user2 to run refresh_spare_usr2 for CIS hardening, removing enable_spare and disable_spare; add copying key for backup_usr2
-
1.1.0 — Add installing AUID use of refresh_spare_usr2; add new section on AUID use of refresh_spare_usr2 section using enable_spare and disable_spare; restructure installing sudo access for rotation scripts and root account; remove UID/GID parallelism; correct use of computer when system is correct
-
1.0.5 — Limit AUID options for refresh_secondary
-
1.0.4 — Remove shutdown, reboot, and refresh_spare_usr2 from sudoers; cleanup refresh_spare_usr2 only for root
-
1.0.3 — Optionally disable oper/prog shell time-out
-
1.0.2 — Add no GUI login and other new remediations
-
1.0.1 — Fix typo in desktop setup
-
1.0.0 — Initial release
1. Introduction
These notes detail adding extra security features to Field System Linux 11, FSL11, as advised by Center for Internet Security (CIS). This is provided as an option for sites that might need additional security.
At the time of this writing, there is no CIS security benchmark for Debian 11, which is what FSL11 is based on. Instead, the latest benchmark for Debian 10 was used. Although this is not technically correct, the changes in the benchmark for Debian 10 compared to Debian 9 were relatively minor; primarily removal of items. It seems plausible that the Debian 10 benchmark will be adequate for Debian 11. In fact, all of the items that fail for FSL11 are either things that are required for FS operation, items that appear to actually be secure despite the benchmark not recognizing them as such, and one change since Debian 10 that we worked around. However, we don’t know what additional checks will be in the Debian 11 benchmark.
Note
|
Additional steps needed to use the benchmark:
|
With the exception of the partition configuration, all actions are to be performed post-installation (see the FSL11 Installation document). Applying the remediations, the exceptions that are still present, all tests that failed, and problems with the benchmark remediations are provided in separate sections below. An appendix covers additional setup that is needed for FS operations after the remediations have been applied.
This document is based on the results for the “CIS Debian Linux 10 Benchmark v1.0.0 - Level 2 - Server”.
2. Applying CIS remediations
2.1. Installation partition configuration
During installation, be sure to create the logical volumes marked optional in the partition setup section.
2.2. Post-installation remediations
All commands need to be run as root.
2.2.1. Scripted remediations
As many remediations as possible are implemented by the remediate script. The script is intended to be run after the “Third Stage Installation” steps in the FSL11 instructions, before any further changes have been made to the system (however initializing and adding other disks to the RAID can intervene).
To apply these remediations, execute the commands:
cd /root/fsl11 script ../remediate.txt ./remediate exit
Important
|
This script should not be run more than once on a system. |
Tip
|
The use of the script command causes the output to be recorded
in the specified file. This can be very helpful for understanding what
went wrong if the script fails. The script itself uses the -x option
to echo the commands as they are executed to make it easy to match the
output with the commands being executed.
|
2.2.2. Reboot
The system should be rebooted to make sure all the remediations have been applied. Some aren’t enforced until a reboot.
After the reboot, all the CIS remediations that can applied at this point have been completed. The Additional CIS policies subsection below describes some other policies that can be considered.
2.2.3. Additional remediations
The subsection applies a second round of scripted remediations and an unscripted remediation that both go beyond the CIS benchmark. Before applying the scripted remediations, an account must be created that will have the ability to promote to root. Please see the Enabling user promotion to oper/prog and root and Adding AUID accounts sections of the Additional items for FS operations appendix for the details of configuring such an account.
Run the script
To apply the scripted remediations, execute the commands:
Important
|
These scripted remediations including disabling direct root login. If there is no account that is able to promote to root before they are applied, it will become impossible to get root access. |
cd /root/fsl11 script ../remediate2.txt ./remediate2 exit
Important
|
This script should not be run more than once on a system. |
This script will place a backup of all the original files modified by the script in the directory /root/remediate2_backups.
Unscripted remediation
This remediation is to specify a FQDN for a server in the
/etc/ntp.conf file. The server must be within the same second-level
domain as the system being hardened. If you using the recommended FS
NTP configuration, you can add lines for the FQDN
after the lines
for the alias
of the server. There must be exactly one space (no
tabs) between server
and the FQDN
. The result would be something
like:
# if you update this one, also update the FQDN version below server alias iburst minpoll 4 restrict alias kod notrap nomodify nopeer noquery # # if you update this one, also update the aliased version above server FQDN iburst minpoll 4 restrict FQDN kod notrap nomodify nopeer noquery
The lines for the alias may still work to locate the server if there is a DNS problem. The comments may help get the correct result if this server changes.
Second remediation reboot
The system should be rebooted to make sure all the remediations have been applied. Some aren’t enforced until a reboot.
Note
|
After this reboot, the GUI login on the console will be disabled. Locally, it will only be possible to login on a text console. |
2.3. Additional CIS policies
This section lists further topics related to the benchmark that should be discussed. The items are listed by benchmark section numbers.
1.5.2 Ensure bootloader password is set
You may wish to create an encrypted password with grub-mkpasswd-pbkdf2:
grub-mkpasswd-pbkdf2 Enter password: <password> Reenter password: <password> Your PBKDF2 is <encrypted-password>
Add the following into a custom /etc/grub.d configuration file (don’t use /etc/grub.d/00_header as it can be overwritten by a package update):
cat <<EOF set superusers="<username>" password_pbkdf2 <username> <encrypted-password> EOF
If there is a requirement to be able to boot/reboot without entering
the password, edit /etc/grub.d/10_linux and add --unrestricted
to the
line CLASS=
Important
|
It is strongly recommended that booting without a password be permitted. Otherwise, if a reboot is required to continue operations it will not be possible unless some one with the password is available. If they aren’t available, this could lead to a safety issue or loss of VLBI data. |
Example:
CLASS="--class gnu-linux --class gnu --class os --unrestricted"
Run the following commands to update the grub2 configuration and reset the grub.cfg permissions:
update-grub chmod go-rwx /boot/grub/grub.cfg
1.8.1.2 Ensure the local login warning banner is configured properly
You may want to update /etc/issue to have a more tailored message
with sterner warnings. The message must not include use of \m
, \r
,
\s
, \v
, or references to the OS platform.
1.8.1.3 Ensure the remote login warning banner is configured properly
You may want to update /etc/issue.net to have a more tailored
message with sterner warnings. The message must not include use of
\m
, \r
, \s
, \v
, or references to the OS platform.
1.8.2 Ensure GDM login banner is configured properly
You may want to update /etc/gdm3/greeter.dconf-defaults to have a more tailored message with sterner warnings.
If desired, you can remove the Debian logo from the GUI login page by
renaming the file specified for the logo
option of the
[org/gnome/login-screen]
section in
/etc/gdm3/greeter/dconf-defaults. For example, if appropriate, you
might use:
cd /usr/share/images/vendor-logos mv logo-text-version-64.png logo-text-version-64.png.bak
If desired, you can remove the Debian logo from the grub menu by
renaming the file specified for in the if
clause for the
background_image
file in the /etc/grub.d/05_debian_theme
section
of /boot/grub/grub.cfg. For example, if appropriate, you might use:
cd /usr/share/desktop-base/homeworld-theme/grub mv grub-4x3.png grub-4x3.png.bak
Important
|
Caveat Emptor! The changes below in this IMPORTANT section may not be safe. Even if they appear to be successful, they may case problems later. The problems may include failure of automatic updates. They may also need to be reinstalled after updates. After making any or all of these changes, it is necessary to execute: update-grub for them to take effect.
|
2.2.1.4 Ensure ntp is configured
This needs the FS NTP configuration. That is more secure than the
benchmark since it uses ignore
by default.
4.1.2.3 Ensure system is disabled when audit logs are full
This may not be appropriate for an operational system.
4.2.1.5 Ensure rsyslog is configured to send logs to a remote host
To set a remote log host, edit the /etc/rsyslog.conf and/or the
/etc/rsyslog.d/*.conf files and add lines like the following
(replace angle bracket items, <…>
, with your values):
<files to sent to the remote log server> action(type="omfwd" target="<FQDN or ip of loghost>" port="<port number>" protocol="tcp" action.resumeRetryCount="<number of re-tries>" queue.type="linkList" queue.size=<number of messages to queue>")
or
*.* @@<FQDN or ip of loghost>
Run the following command to reload the rsyslog configuration:
systemctl reload rsyslog
5.2.16 Ensure SSH Idle Timeout Interval is configured
Five minutes is too short and is not commensurate with the recommended 15 minute auto-logout interval.
5.3.1 Ensure password creation requirements are configured
Should the minimum be reduced to 12 characters?
5.3.2 Ensure lockout for failed password attemtps is enabled
The number of login failures before lock-out can cause a problem if it is set too low. The main issue is for an operator working at odd hours, alone, at a remote location, and dealing with multiple issue, which might include: power failures, equipment problems, and logistical issues. It can be a chaotic situation. Typing long and complicated passwords in the heat of battle, particularly if they vary between machines, can be error-prone. Being locked-out will make the situation more difficult and may increase the amount of data that will be lost.
If you find that the number of login failures before lock-out is too
small, you can increase it by increasing the value of the deny
parameter (5
in the example below, other typical parameters are
omitted and should not be changed) in:
auth required pam_faillock.so deny=5
Small integer values (20
or less) should not be a significant risk
with long and complicated passwords and a unlock time of several
minutes.
5.4.1.4 Ensure inactive password lock is 30 days or less
This is too short for developers/troubleshooters. A value of 60
would be commensurate with the password reset interval.
2.4. Other policies
This subsection describes other policies beyond the CIS benchmark that may be desirable.
2.4.1. TCP wrappers configuration
You may wish to configure TCP wrappers.
/etc/hosts.deny
Add:
ALL:ALL
/etc/hosts.allow
Add:
sshd:ALL
It is recommended that you further restrict sshd to specific hosts and/or sub-domains.
2.4.2. Set log retention period
You may want to set the retention period of system logs by editing /etc/logrotate.conf and/or /etc/logrotate.d/*, as appropriate.
3. CIS Exceptions
This section addresses the tests that failed in the CIS benchmark after all the remediations in this document were applied. The items are listed by benchmark section numbers.
1.4.2 Ensure filesystem integrity is regularly checked
The AIDE system now performs a check daily and generates a report, so this is no longer needed.
1.5.2 Ensure bootloader password is set
This must be set later by the system administrator.
2.2.2 Ensure X Window System is not installed
The X11 Window system is required for FS use.
2.2.4 Ensure CUPS is not enabled
The CUPS printing systems is required for operations.
3.5.2.5 Ensure firewall rules exist for all open ports
There is a ufw rule for Openssh (port 22), but the benchmark doesn’t accept that. Additional openings can be added as needed.
3.5.3.7 Ensure nftables service is enabled
Although the benchmark also uses ufw, which is enabled and uses nftables, for some reason this is not recognized.
3.5.3.8 Ensure nftables rules are permanent
Although the benchmark also uses ufw, which has permanent rules and uses nftables, for some reason this is not recognized.
4.2.1.5 Ensure rsyslog is configured to send logs to a remote log host
A remote log server must be configured later by the system administrator.
5.2.6 Ensure SSH X11 forwarding is disabled
Using ssh X11 forwarding is required for for remote FS operations and testing.
5.3.2 Ensure lockout for failed password attempts is configured
The benchmark, which is for Debian 10, uses pam_tally2.so for this. However pam_tally2.so is not available in Debian 11, having been replaced with pam_faillock.so. The remediate script implements the intent of the recommended pam_tally2.so configuration with pam_faillock.so.
Note
|
To reset a locked-out user after CIS hardening, as root use
faillock --user username --reset where username is the
user account. Leave off the --reset to see what the current failure
count is.
|
4. CIS Remediation problems
This section details problems with the recommended remediations. The items are listed by benchmark section numbers.
Some problems were worked around by adding a boot time systemd
service CISfix
to correct changes that occur on a reboot.
1.1.10 Ensure noexec option set on /var/tmp partition
Enforcing this requirement for the currently running system before all
the other remediations have been applied can interfere with execution
of apt-get install …
to install packages needed for the
remediation. Instead, although /etc/fstab is updated in sequence,
remounting the file systm is deferred to the end.
1.4.2 Ensure filesystem integrity is regularly checked
The /etc/crontab entry that should be added is missing the user (root) field. Additionally Debian no longer provides aide.wrapper. However, the AIDE system now performs a check daily and generates a report, so this is no longer needed.
1.5.1 Ensure the permissions on the bootloader are configured
The permissions are reset every time update-grub is run, e.g., for a
kernel update. Fixing them was added to the CISfix
systemd
service at boot.
2.2.1.4 Ensure ntp is configured
The remediation makes it less secure. A default policy of ignore
is
better.
3.3.4 Ensure suspicious packets are logged
The remediation lines added in /etc/sysctl.d/* for this issue are
not respected at boot (unlike all others). To overcome this, the
following lines are used in the CISfix
systemd service at boot.
sysctl -w net.ipv4.conf.all.log_martians=1 sysctl -w net.ipv4.conf.default.log_martians=1 sysctl -w net.ipv4.route.flush=1
4.1.5 Ensure events that modify the system’s network environment are collected
The 64-bit remediation had the b64
and the b32
rules concatenated
on one line.
4.1.16 Ensure kernel module loading and unloading is collected
The 64-bit remediation was missing the b32
rule.
4.2.3 Ensure permissions on all logfiles are configured
There are two issues:
-
The recommended remediation makes the entire directory tree /var/log unsearchable by everyone except root. This breaks some functionality, in particular email. As a result, the remediation was scaled back to just the minimum required to pass the test, which was to just set the permission on the files themselves instead changing the directory permissions as well. This could be made more targeted. For example to allow email use, just /var/log and /var/log/exim4 could be made searchable.
-
The permissions for some logfiles are reset each time the system reboots. Fixing them was added to the
CISfix
systemd service at boot.
6.1.6 Ensure permissions on /etc/passwd- are configured
The permissions are reset each time the system reboots. Fixing them
was added to the CISfix
systemd service at boot.
6.1.7 Ensure permissions on /etc/shadow- are configured
The permissions are reset each time the system reboots. Fixing them
was added to the CISfix
systemd service at boot.
6.1.8 Ensure permissions on /etc/group- are configured
The permissions are reset each time the system reboots. Fixing them
was added to the CISfix
systemd service at boot.
6.1.11 Ensure no unowned files or directories exist
After each boot, the file /var/cache/private/fwupdmgr has no owner.
Fixing that was added to the CISfix
systemd service at boot.
6.1.12 Ensure no ungroup files or directories exist
After each boot, the file /var/cache/private/fwupdmgr has no group.
Fixing that was added to the CISfix
systemd service at boot.
Appendix A: Additional items for FS operations
After the CIS hardening is completed, some additional set-up is needed. In addition, one item below gives the procedure for running refresh_spare_user with CIS hardening.
A.1. Fix-ups
There are two issues that may need to be corrected after the CIS hardening.
-
Using the
noexec
option for /tmp causes a problem for the package management system. The dpkg-preconfigure program places and executes scripts on /tmp as part of package installation. Thenoexec
option prevents the execution of the scripts. To work around this issue, you can exeucte:cd /root/fsl11/ ./root_tmp
NoteThe error message:
Failed to disable unit: Unit file root_tmp.service does not exist.
is benign.
The root_tmp script performs three actions:
-
Creates a one time service at boot to clean the /root/tmp directory
-
Sets dpkg-preconfigure to use /root/tmp for temporary files
-
Creates an initial /root/tmp directory
There may be other issues with using the
noexec
option for /tmp, but we don’t have any specifics at this time. -
-
Sometimes the firewall (ufw) does not work properly after rebooting. This has been noticed for remote access to gromet for met. data on port 50001. There are no other known issues. An apparent fix for this is to disable and re-enable the firewall. If you have this problem and the same solution works, a one-time service at start-up can be created to perform this action:
cd /root/fsl11 ./create_ufw_re-enable
The new service will run at the next reboot. It is configured to run after ufw has been started.
A.2. Enabling user promotion to oper/prog and root
The model used in the FS assumes oper and prog accounts will be used for operations and programming respectively. However, some organizations may have security and auditing restrictions that mean operators must login using their own account (possibly named with their Agency User ID, or AUID). As the FS currently operates, users will then need to switch, i.e., promote, to the oper or prog account after login. Likewise, if a user is allowed to promote to root, they will need to do so after logging into their own account. This subsection covers how to enable this capability. The next subsection, Adding AUID accounts, covers how to add an AUID account.
For oper and prog, we suggest creating two groups that can sudo to the accounts. Run visudo, then add at end:
%operators ALL=(oper) ALL %programmers ALL=(prog) ALL %programmers ALL=(oper) ALL
To allow operators to use shutdown and reboot add (respectively):
%operators ALL=(ALL) /sbin/shutdown %operators ALL=(ALL) /sbin/reboot
To use these commands the operators will need to enter (respectively) from their AUID accounts:
sudo shutdown sudo reboot
A password will be required. Trailing options can be used with the commands, as appropriate.
If they don’t already exist, create the needed groups:
addgroup operators addgroup programmers
If they don’t already, set oper and prog to have bash as their login shells:
chsh -s /bin/bash oper chsh -s /bin/bash prog
Important
|
When promoting to oper and prog (and root), the only supported login shell for the target accounts is bash. It would be possible to support tcsh. That would require adding promotion machinery to the ~/.login files that is equivalent to what is in the current ~/.profile files. Please contact Ed for more information. |
Optionally, to disable shell inactivity time-outs for the oper and prog accounts, edit their respective .bashrc files and uncomment the line:
unset TMOUT
If the accounts, and desktop, haven’t been disabled for login already, do so:
usermod -L oper usermod -L prog usermod -L desktop
Disable password aging and account inactivity expiration for those accounts. Execute:
chage -I -1 -M -1 oper chage -I -1 -M -1 prog chage -I -1 -M -1 desktop
To prevent connecting with ssh using a key, create (or add oper
and prog to an existing) DenyUsers
line in /etc/ssh/sshd_config:
Note
|
If you used the CIS remediate script, you should comment out
the line: DenyGroup rtx as well.
|
DenyUsers desktop oper prog
And restart sshd with:
systemctl restart sshd
Authorized users can then switch to oper with (similarly for prog and root):
sudo -i -u oper
The sudo command will prompt for the AUID account’s password. Within a session, sudo will not prompt again for 15 minutes after its last successful use.
The following example steps are used to ensure that X11 authorization works. This example is for user oper and works analogously for prog and root (but see the paragraph at the end of step (1) for more information about root's configuration). After the steps are presented, there is information on a script that implements these changes for all three accounts in one step.
-
.profile: Add this to the following file:
~oper/.profile# # authorise XCOOKIE for remote users if ! [ -z ${XCOOKIE+x} ]; then xauth add $XCOOKIE fi # set .Xresources/window-manager coming from AUID accounts if ! [ -z ${DISPLAY+x} ]; then # NOT no DISPLAY defined, do something (otherwise do nothing) if echo $DISPLAY |grep -q localhost; then # ssh from remote host with X display xrdb -merge ~/.Xresources else # login shell (because this is .profile) on the local X console xrdb -merge ~/.Xresources setsid fvwm --replace >/dev/null 2>&1 & fi fi # # include AUID user's .profile_SUDO_USER if [ -n "$SUDO_USER" ]; then if [ -f "$HOME/.profile_$SUDO_USER" ]; then . "$HOME/.profile_$SUDO_USER" fi fi
This will also set the Xresources to those of oper, replace the current window manager with one owned by oper (protected from Ctrl+C by setsid) for a local console X11 session, and run a bash script (if present) to apply customizations for the sudo user in a login shell. Additional customization may be run (earlier) from the .bashrc file, which is also executed for non-login shells; see the .bashrc step below. (For root only the first clause would be used since Xresources would not be set, the window manager would not be replaced, and there would not be sudo user customization.)
-
Create the following file:
/usr/local/bin/oper_accountset -e if [ "$USER" = "prog" ]; then echo "ERROR: Cannot promote to oper from $USER account. Promote from $SUDO_USER instead." exit 1 elif [ "$USER" = "oper" ]; then echo "ERROR: Already in $USER account." exit 1 fi if [ -z ${DISPLAY+x} ]; then # no DISPLAY set sudo -u oper -i "$@" elif echo $DISPLAY |grep -q localhost; then # remote user sudo -u oper XCOOKIE="$(xauth list $DISPLAY)" -i "$@" else # on console X server if ! xhost|grep -q 'SI:localuser:oper'; then xhost +SI:localuser:oper >/dev/null fi sudo -u oper -i "$@" fi
-
Execute:
chmod a+rx /usr/local/bin/oper_account
-
Create the following file:
/usr/local/bin/oper_x11set -e if [ $USER = "prog" ]; then echo "ERROR: Cannot promote to oper from $USER account. Promote from $SUDO_USER instead." exit 1 elif [ $USER = "oper" ]; then echo "ERROR: Already in $USER account." exit 1 fi if tty|grep -q ^/dev/tty ;then export AUID_PROMOTE_ACCOUNT=oper startx >/dev/null 2>&1 else echo "Only text console users are allowed to run the X server, use 'oper_account'." fi
-
Execute:
chmod a+rx /usr/local/bin/oper_x11
-
.bashrc: Add this to the following file:
~oper/.bashrc# # include AUID user's .bashrc_SUDO_USER if [ -n "$SUDO_USER" ]; then if [ -f "$HOME/.bashrc_$SUDO_USER" ]; then . "$HOME/.bashrc_$SUDO_USER" fi fi
This provides a way to run a bash script (if present) to apply customizations for the sudo user for non-login shells. This script is also run for login shells; see the .profile step above.
To execute the six numbered steps above for oper and prog and the first three for root (for the latter only those three are needed), enter:
~/fsl11/AUID/install_AUID
The script will also set ~oper and ~prog directories to be readable and searchable by other users. This will allow AUID users to access their customization scripts (and allow all users to read the parts of the directories they have read access to), which will be owned by them,
The oper_account, prog_account, and root_account scripts can be used to promote any AUID session that is enabled in /etc/sudoers to those accounts. If the Additional remediations have been applied, the oper_x11 and prog_x11 scripts can be used on a text console to start an X11 session and promote.
Note
|
If the Additional remediations have been applied, the process to run X11 applications (e.g., nm-connection-editor) as root depends on how you logged in. You must login with an AUID account that is enabled in /etc/sudoers to promote to root.
|
A.3. Adding AUID accounts
This subsection describes how to add AUID accounts to be used with the ability to promote to oper, prog, and root as described in the previous subsection. The method described here uses dhorsley as an example AUID account name.
-
Add the user account:
adduser dhorsley --home /usr2/dhorsley
Enter a suitable password when prompted and confirm it. Answer all other questions with Enter.
ImportantIf you are configuring a spare system, you will need to make sure the same accounts and groups for the owners of files on /usr2 exist on both systems (but the UIDs and GIDs don’t need to be the same) for the system-to-system backup of /usr2 to work properly. NoteFor normal operations, AUID users' home directories should be on /usr2. However, for some maintenance accounts, it may make sense to have the home directory some where else, typically on /home. In that case, use this command instead:
adduser dhorsley
The step for setting the contents of the home directory below will need to be adjusted accordingly; see the NOTE farther below.
-
Add the user to these groups as appropriate, e.g.:
NoteThis step assumes that the operators and programmers groups have been created as described in the previous subsection Enabling user promotion to oper/prog and root. adduser dhorsley operators
and/or:
adduser dhorsley programmers
-
If the user should be able to manage printers, use:
adduser dhorsley lpadmin
-
If the user is allowed to elevate to root, use visudo to add:
dhorsley ALL=(root) ALL
-
If the account will be used by an operator and/or programmer with the GUI, the X11 environment needs to be set-up. The following command will move an existing /usr2/dhorsley to /usr2/dhorsley.FSL11COPY and create a new /usr2/dhorsley with useful skeleton files (you will be prompted for the account name):
~/fsl11/AUID/AUID_update
It will also create ~oper/.profile_dhorsley, ~oper/.bashrc_dhorsley, ~prog/.profile_dhorsley, and ~prog/.bashrc_dhorsley scripts for per AUID user customization of oper and prog sessions. The initial versions of these files just print a message as a reminder that they are being used, e.g.:
~oper/.profile_dhorsleyecho "Applying customizations from ${BASH_SOURCE}"
~oper/.bashrc_dhorsleyecho "Applying customizations from ${BASH_SOURCE}"
For information on customizing these files and FS window placement for AUID users, please see the AUID Account Customization document.
NoteNOTE: If the user’s home directory is not on /usr2, but is for example on /home, the following commands should be used instead:
cd /home mv dhorsley dhorsley.FSL11COPY cd ~/fsl11/AUID/skel find . -print|cpio -pmdu /home/dhorsley chown -R dhorsley.dhorsley /home/dhorsley chmod 0750 /home/dhorsley
No oper/prog customization scripts are included. It is assumed that since these accounts aren’t on /usr2 that they aren’t used for operations.
-
Optionally, to disable shell inactivity time-outs for the AUID account, edit their .bashrc file and uncomment the line:
unset TMOUT
-
Set default desktop
To set the correct default desktop (it is remembered per user):
cat > /var/lib/AccountsService/users/dehorsley <<EOF [User] Language= XSession=default Icon=/usr2/dehorsley/.face SystemAccount=false EOF
Normally, the GUI login is disabled if the security remediations of this document have been applied. If the GUI login is available and you have access to the console, an alternative means for setting the desktop is:
-
Press Ctrl+Alt+F1 to get to the GUI login.
-
Enter
dhorsley
as theUsername
. -
Select the “gear” icon in the lower right-hand corner.
-
Select
System X11 Default
. -
Complete logging in with the password.
-
Logout with
exit
.
-
-
If you have previously created a system alias, then follow the sub-steps in the Use the new alias in .bashrc step (in the Setting hostname alias section below) for this user.
-
If you have operational and spare systems and have already installed the backup_usr2 script on the operational system, you may want to follow the steps in the sub-step Copy root ssh key for running backup_usr2 (in the Installing backup_usr2 with CIS hardening section below) for this user.
A.4. Enable operators group accounts to rotate disks
-
Allow operators to use the sudo scripts rotation_shutdown (with any options) and refresh_secondary (but only with no options or with the
-h
or-p
options individually), by adding (respectively) with visudo:%operators ALL=(ALL) /usr/local/sbin/rotation_shutdown %operators ALL=(ALL) /usr/local/sbin/refresh_secondary "" %operators ALL=(ALL) /usr/local/sbin/refresh_secondary -h %operators ALL=(ALL) /usr/local/sbin/refresh_secondary -p
NoteA user who can elevate to root will be able to run refresh_secondary with any options if they use sudo explicitly. -
Install AUID scripts to allow
operators
group accounts to run the sudo scripts without explicitly entering sudo:~/fsl11/AUID/install_RAID
NoteThe scheme here uses scripts that are run with sudo (the so-called sudo scripts) for steps that require elevated privileges. These are installed in /usr/local/sbin. For ease of use with the
operators
group (typically AUID) accounts, additional scripts (the so-called AUID scripts) with the same names that run the sudo scripts are installed in /usr/local/bin. The AUID scripts verify that the oper and prog accounts are not in use before running the sudo versions with sudo. This cuts down on error messages from sudo and saves AUID users from needing to enter sudo.This works for root (and sudo) users because /usr/local/sbin appears before /usr/local/bin in users'
PATH
variables. It works for non-root (and non-sudo) users because the versions in /usr/local/sbin are only executable by root.
A.5. Setting hostname alias
These steps set a more user friendly alias for the systems of the form fs1-<xx> and fs2-<xx> where <xx> is the station’s two letter code. This provides a compact alias for local usage, even for sites with more than one system, and makes the system identifiable for remote users in a systematic way. Except as noted below, these steps should be executed for both the operational and spare systems.
-
Edit /etc/hosts and add the new aliases to the appropriate lines.
If you have two systems, add the aliases for both to the file on each system.
-
Create a file /etc/hostname_alias that contains the new alias.
-
Execute
cd /etc cp hostname hostname_alias chmod a+r hostname_alias
-
Edit the new file and change the contents to the new alias.
-
-
Change the system’s mailname
NoteTo allow mail to mailman mail lists to work, you may need to make a use a fake FQDN name, perhaps by appending .net to your alias, for use in /etc/mailname and /etc/exim4/update-exim4.conf.conf. The two files should be consistent. -
Edit the file /etc/mailname and change its contents to the new name, without a domain name unless that is required by remote mail hosts or mail lists. If so, Generate FQDN in HELO for outgoing mail in the FSL11 Installation document may also be helpful.
-
Edit /etc/exim4/update-exim4.conf.conf, change the value of
dc_other_hostnames=
to the new alias -
Execute
update-exim4.conf systemctl restart exim4
-
-
Use the new alias in .bashrc: Except for the sysadmin's AUID account (unless they want it) set user prompts and xterm titles for oper, prog, and all AUID accounts. In each .bashrc file to be changed:
-
Before the
if
block that setsPS1
add:hostalias_file=/etc/hostname_alias if [[ -f "$hostalias_file" ]]; then hostalias=$(cat $hostalias_file) else hostalias=$(hostname) fi
-
In the two statements setting
PS1
in theif
block, change the use of\h
to$hostalias
. -
In the statement setting
PS1
in thecase
block that sets the xterm window title, change the use of\h
to$hostalias
. -
Unless the sysadmin wants to use the alias, copy the following lines from their AUID .bashrc file:
# set a fancy prompt (non-color, unless we know we "want" color) case "$TERM" in xterm-color|*-256color) color_prompt=yes;; esac # uncomment for a colored prompt, if the terminal has the capability; turned # off by default to not distract the user: the focus in a terminal window # should be on the output of commands, not on the prompt #force_color_prompt=yes if [ -n "$force_color_prompt" ]; then if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then # We have color support; assume it's compliant with Ecma-48 # (ISO/IEC-6429). (Lack of such support is extremely rare, and such # a case would tend to support setf rather than setaf.) color_prompt=yes else color_prompt= fi fi if [ "$color_prompt" = yes ]; then PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ' else PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ ' fi unset color_prompt force_color_prompt # If this is an xterm set the title to user@host:dir case "$TERM" in xterm*|rxvt*) PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1" ;; *) ;; esac
and add them to the end of their ~oper/.bashrc_SUDO_USER and ~prog/.bashrc_SUDO_USER files.
-
-
If you have previously installed refresh_spare_usr2 and have now updated the operational system alias, then on the spare system:
-
Update /usr/local/sbin/refresh_spare_usr2 to use the new alias of the operational system for the
remote_node
variable. -
You will need to make the new alias for the operational system be recognized as a known host for the root account on the spare system. You can do that, as root, by using:
ssh-keyscan -H operational >>~/.ssh/known_hosts
where
operational
is the value you used for theremote_node
variable in the refresh_spare_usr2 script.
-
-
If you have previously installed backup_usr2 and have now updated the spare system alias, then on the operational system:
-
Update /usr/local/sbin/backup_usr2 to use the new alias of the spare system for the
remote_node
variable. -
You will need to make the new alias for the spare system be recognized as a known host for the root account on the operational system. You can do that, as root, by:
ssh-keyscan -H spare >>~/.ssh/known_hosts
where
spare
is the value you used for theremote_node
variable in the backup_usr2 script.
TipNot performing this step will just require answering yes
to a prompt to accept the spare machine fingerprint on the next use of backup_usr2. -
A.6. Installing backup_usr2 with CIS hardening
Foe CIS hardened systems, the backup_usr2 script is used on the operational system to backup its /usr2 partition to the spare system. To do this, it invokes refresh_spare_usr2 on the spare system. This is useful if to want the spare system to be a reasonably up-to-date backup system for operations. All steps for installation must be performed as root on the specified system. You should read all of the procedure before using it.
Tip
|
Read the introduction of the refresh_spare_usr2 section of the RAID Notes for FSL11 document for important information on the refresh_spare_usr2 script. |
Note
|
Please see the NOTE in the Enable operators group accounts to rotate disks step in this appendix for an explanation of how the so-called sudo and AUID scripts, also used here, interact. |
-
On the operational system:
-
Create spare account. Execute:
adduser spare
Enter a suitable password when prompted and confirm it. Answer all other questions with Enter.
NoteThe user’s home directory is on /home (by default), not /usr2.
-
-
On the spare system:
-
Make sure the operational system is represented in the /etc/hosts file.
If it is not already there, add it. It is recommended that it be given a simple alias for routine use.
-
Install the sudo script refresh_spare_usr2:
-
Move the script into position:
~/fsl11/RAID/install_refresh_spare_usr2
-
Customize /usr/local/sbin/refresh_spare_usr2, following the directions in the comments in the script (repeated here):
-
Comment-out the lines (add leading
#
s):echo "This script must be customized before use. See script for details." exit 1
-
Change the
operational
in the line:remote_node=operational
to the alias (preferred), FQDN, or IP address of your operational system.
-
Uncomment the line for CIS hardened systems. The commented out form is:
#remote_user=spare
-
-
For operators, Enable running the sudo script with either no options or just
-h
. Use visudo to add:%operators ALL=(ALL) /usr/local/sbin/refresh_spare_usr2 "" %operators ALL=(ALL) /usr/local/sbin/refresh_spare_usr2 -h
-
-
Create a key for root:
If root already has a key, you should skip this sub-step.
CautionYour should not set a passphrase. ssh-keygen
-
Copy the key:
ssh-copy-id spare@operational
where
operational
is the value you used for theremote_node
variable in the refresh_spare_usr2 script.NoteYou may need to accept the fingerprint of the operational system if this is the first time root has connected to it.
-
-
On the operational system:
-
Set the spare account to only allow a forced command with ssh by replacing the
ssh-rsa
at the start of the first (and only) line of ~spare/.ssh/authorized_keys line with:command="sudo --preserve-env rrsync -ro /usr2" ssh-rsa
TipIf your spare system is registered with DNS, you can provide some additional security by adding from="node"
(note the trailing space) at the start of the line, wherenode
is the FQDN or IP address of the spare system. It may be necessary to provide the FQDN, IP address, and/or alias of the spare system in a comma separated list in place ofnode
to get reliable operation. -
Setup the spare account to run rrsync with sudo with a password (which will make refresh_spare_usr2 fail unless it is used with the procedure in the Using backup_usr2 with CIS hardening section below) and with passing environment variables. Use visudo to add:
spare ALL=(ALL) SETENV: /usr/bin/rrsync
-
Setup sudo on the operational machine to allow
operators
to run the backup_usr2 script with:%operators ALL=(ALL) /usr/local/sbin/backup_usr2
-
Install the sudo script backup_usr2:
-
Move the script into position:
~/fsl11/RAID/install_backup_usr2
-
Customize /usr/local/sbin/backup_usr2 following the directions in the comments in the script (repeated here):
-
Comment-out the lines (add leading
#
s):echo "This script must be customized before use. See script for details." exit 1
-
Change the
spare
in the line:remote_node=spare
to the alias (preferred), FQDN, or IP address of your spare system.
-
-
-
Install the AUID script that runs the sudo script:
~/fsl11/AUID/install_backup_usr2
-
Lock-out the spare account from normal login (but it must have a shell). This will disable password login, but not ssh login with keys, for this account. Execute:
usermod -L spare
-
Disable password aging and account inactivity expiration for the spare account. Execute:
chage -I -1 -M -1 spare
-
Make the spare system a known host to the root account.
ssh-keyscan -H spare >>~/.ssh/known_hosts
where
spare
is the value you used for theremote_node
variable in the backup_usr2 script.TipNot performing this step will just require the prompt to be answered on the first use of backup_usr2. -
Copy root ssh key for running backup_usr2:
For each AUID account on the operational system that will use backup_usr2, copy the ssh key from root on the operational system to the AUID account on the operational system. The AUID account must have been created on both systems before using this method.
-
Create a key:
If the root account already has a key, you should skip this step.
CautionYour should not set a passphrase. ssh-keygen
-
Copy the key to to the authorized_keys for each AUID user that will use backup_usr2.
NoteThe first command below will generate an error File exists
if the directory already exists. That is benign and can be ignored.cd ~AUID mkdir .ssh cat /root/.ssh/id_rsa.pub >>~.ssh/authorized_keys chown -R AUID.AUID .ssh
where
AUID
is the AUID account that will use backup_usr2.
NoteThe key now stored in the AUID account on the operational system will be copied to that account on the spare system the next time backup_usr2 is run. Until then, any user would need to enter their password to connect to the spare system when running backup_usr2. -
-
A.7. Using backup_usr2 with CIS hardening
To use backup_usr2 as part of a monthly backup, you first should perform a disk rotation on both systems. The disk rotation procedure is described in the Disk rotation section of the RAID Notes for FSL11 document. You should start a disk rotation on the spare system (e.g., fs2) first. Once this is successfully refreshing, log out of the spare system. Then start a disk rotation running on the operational system (e.g., fs1). Once that is successfully refreshing, don’t log out. Proceed directly to the instructions below.
You can also use the procedure below to “freshen” the /usr2 on the spare system at other times.
Note
|
For CIS hardened systems, the backup_usr2 script is used on the operational system to backup its /usr2 partition to the spare system. To do this, it invokes refresh_spare_usr2 on the spare system. |
-
Start with no one logged into either system.
ImportantBefore proceeding, make sure that no one is logged into either system and that no processes are running on /usr2 on either system, particularly the FS.
TipIf the only session logged on the systems is the AUID session you used to start the disk refresh on the operational system, and there is no other activity on /usr2, you can use that session in the directions below without logging out first. -
On the operational system:
-
Login to your AUID account if you aren’t already logged in.
-
Run:
backup_usr2
NoteYou may be prompted for your AUID password on the operational system in order to run the script if it has been more than 15 minutes since you used sudo in that session, e.g., to start a refresh. NoteYou may be prompted for your AUID password for the spare system in order to connect to that system.
TipYou can eliminate this password prompt by copying the ssh key from the root account on the operational system to your AUID account on the spare system (and to the operational system). See the sub-step Copy root ssh key for running backup_usr2 in the Installing backup_usr2 with CIS hardening section above for instructions. The refresh_spare_usr2 script will be run on the spare system automatically.
NoteYou will be prompted for your AUID password for the spare system in order to run refresh_spare_usr2 on that system with sudo. It is not possible to eliminate this prompt. Answer the question
y
if it is safe to proceed.
-
-
Log out of the operational system.
-
Wait until the refresh_spare_usr2 script on the spare system has finished before logging in again and resuming other activities on the systems.
This step (and procedure) continues at the Wait step in the Using refresh_spare_usr2 subsection of the refresh_spare_usr2 subsection of the RAID Notes for FSL11 document.