Authored by:
Brad Frank & Emily Lawrence
Harvard-MIT Data Center
This document instructs administrators and staff on using the level 5 workstations with regard to proper handling and processing of data, and user management.
Note: When substituting for placeholders, i.e. [variable], make sure not to include the brackets.
Administrators belong to a built-in system group called wheel. The group has sudo privileges and can execute commands that normal users cannot. Never add a user to this group unless they have been properly cleared by EdLabs processes for administrator rights. See Section A.1.3. to grant administrator privileges to a user.
All EdLabs users should be joined to the general edlabs group. This provides access to all datasets, unless a dataset has been specifically assigned to a different group. A dataset will be assigned to a different group in the event that access needs to be restricted to a subset of users.
For stricter access to a dataset, a new group should be created. A good practice is to use the same name as the data for the group name, prefixed with "edlabs". For example, a dataset /mnt/edlabs_data/govdata would belong to a group edlabs_govdata. For setting up a new dataset, see Section A.2.1.
Use a descriptive name for the group; it's recommended that if you're adding a new project, to use the same name of the project directory for the group. Groups can include numbers, but avoid spaces and symbols.
sudo groupadd [group]
To add a user that already exists to a group:
sudo usermod -aG [group] [username]
To add the existing user to multiple groups at once, comma separate (no space) the group names:
sudo usermod -aG [group],[group] [username]
To remove a user from a group:
sudo gpasswd -d [username] [group]
All new user accounts must be approved by an EdLabs administrator. Account usernames should follow the pattern first initial plus last name (e.g. "Pat Smith" becomes "psmith").
By default, all accounts must expire in one year. If the staff needs access beyond that, an administrator must extend the account. Both the administrator and user will receive notices beginning at 30 days before expiration, after which the account will become locked. The account can be extended at any point before or after expiration.
Account passwords do not expire once set, although users can reset his or her password at any time (passwd from the terminal); if an administrator needs to reset a user’s password, follow the steps in Section A.1.2.3.
If making a new user an administrator, see Section A.1.3.
To create a new user belonging to the edlabs group:
sudo useradd –G edlabs [username]
The user can also be added to additional groups, which are comma separated (no spaces):
sudo useradd –G [group],[group] [username]
If the user is not added to a group at this time, see Section A.1.1.2. for adding a group membership later.
Set the account to expire after one year. This step must not be skipped, and must be applied to all accounts.
extend [username]
Note: The extend command is a global alias for sudo chage -E `date -d "1 year" +%Y-%m-%d`.
All new users must change their password on first log in. These commands set a temporary password that is safe to give to the user, and expires the password which forces a reset.
sudo mkpasswd [username]frpasswd [username]
Note: The frpasswd command is a global alias for sudo chage -d 0.
After creating the account, the new user should log in; they will be prompted to reset their password. Once the desktop environment has loaded, click through the intro screens, then the user should configure Thunderbird to receive system mail, see Section B.1.2.1.
The "wheel" group is a built-in group that has administrator privileges.
- To add a user to the admin group:
sudo usermod -aG wheel [username] - To remove a user from the admin group:
sudo gpasswd -d [username] wheel
A new administrator should also get a copy of the mail that is sent to the root user. This functionality is a requirement of level 5 machines.
- Add the user to aliases file:
- Open the aliases config file for editing:
sudo gedit /etc/aliases - Add a new alias entry (usually bottom of file: "Person who should get root’s mail") or remove the appropriate username. When adding additional usernames, separate with a comma and space ([username], [username]). You're looking for the line
root: [username]. - Save and close the file.
- Commit the change:
sudo newaliases
- Open the aliases config file for editing:
- Modify root’s mail forwarding:
sudo gedit /root/.forward- Add or remove users as necessary. Multiple accounts are separated by only spaces. The format is
[username]@localhost. - Save and close the file.
- Make sure you have saved any files from the user's home directory that you want to keep.
pseudouserdel -r [username]
Datasets exist on a separate hard drive and is mounted to the path /mnt/edlabs_data/. The data is encrypted, but unlocked at boot time. The automatic mount is configured in /etc/fstab; but please consult a Systems Administrator.
If the data should be restricted to a subset of users, first see Section A.1.1. to create a new group, and then add selected users to that group. Otherwise, just execute the steps below. If permissions ever need to be fixed or "refreshed" on a dataset, execute steps A.2.1.2. and A.2.1.3.
Create the directory, substituting [dataset] for a name of your choice (keep to alphabetical characters and replace spaces with underscores).
sudo mkdir /mnt/edlabs_data/[dataset]
Copy the data into the new directory (note the directory slashes):
rsync –rv /path/to/data/ /mnt/edlabs_data/[dataset]/
Before copying, set ownership on the directory. Usually the group will be edlabs, but if you created a new group for the dataset, use that group instead.
sudo chown -R root:[group] /mnt/edlabs_data/[dataset]
Set default permissions on the directory. This gives read/write/execute access to the owner and group, and denies access to any other account.
sudo chmod -R 2770 /mnt/edlabs_data/[dataset]
If the project directory should be available to users outside the group assigned to the project, use 2777.
A dataset should be securely erased (as root) when it’s no longer needed. (This may take some time depending on the amount of data.)
pseudosrm -rf /mnt/edlabs_data/[dataset]exit
To remove users from a group, see Section A.1.1.3. To remove users from the system, see Section A.1.4.
Both the operating system and data are encrypted by default, each with their own passphrase. The disks are unlocked at boot and remain unlocked until shutdown or reboot. The passphrases can be changed independent of each other at any time, by an administrator. You will need to specify the encrypted partition to change the passphrase; the defaults are:
- Operating System (e.g. applications, user home directories):
/dev/sda2 - Data:
/dev/sdb1
Confirm (if desired) the encrypted partitions, using one or both of the following methods:
sudo blkid -p /dev/[partition] | grep -q "LUKS" && echo "encrypted device"sudo cryptsetup -v isLuks /dev/[partition]
sudo cryptsetup luksAddKey /dev/[partition]
sudo cryptsetup luksDeleteKey /dev/[partition]
Besides user accounts, there are several instances where passwords are used to secure aspects of the system.
The built-in administrator account. The system is configured so that the root account is inaccessible at the login screen or console. For purposes of managing the system, it’s available for elevating privileges within a user sessions.
Several hardware settings are configured in BIOS, such as disabling network cards. A password helps prevent accidental or malicious changes. Although the BIOS can be reset from the system mainboard, the physical lock on the workstations prevent tampering.
GRUB is the Linux bootloader. It sets parameters for what and how the operating system should boot. For example, booting into a special mode called "single user" or "rescue mode" allows the root password to be reset. Password protecting GRUB prevents accidental or malicious changes to the boot parameters.
The LUKS passphrases are for disk encryption. There are two separate passphrases, one for the operating system, and another for the data. See Section A.3.1. for more information.
The firewall is configured to block all traffic, except local web applications (i.e. RStudio). If a new application requires adding firewall rules, please contact HMDC.
The AIDE utility scans the system for changes. It can report any differences between a baseline and a separate independent scan. This allows administrators to flag suspicious changes for review. Some system changes, like adding new users for example, will be reported by AIDE, but should not be flagged as it is a user-initiated change. For reviewing AIDE logs, see Section A.4.3.
An original baseline is created at the time the systems are delivered to EdLabs, but may need to be updated periodically as more work is done. If the AIDE logs become too long, create a new baseline as follows:
- Become root (use the custom alias):
pseudo - Initialize a new AIDE database (can take a few minutes):
aide --init - Copy the new database into place:
cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
The Audit daemon is configured to log all root commands and access to data. The audit log is found at /var/log/audit/auditd.log.
- To display all root commands:
ausearch -ua 0 - To display access to data:
ausearch -f /etc/edlabs_data
All logs are archived to /var/log/logs_archive/ within monthly directories. They are available at any point for review.
The AIDE log is found at /var/log/aide/aide.log. It is created nightly by a cronjob that runs aide --check on the system. The resulting log is then emailed to the administrators. Interacting directly with the log file is usually not necessary.
To securely erase individual files, see Section B.3.1. For disk erasure, please contact a system administrator (currently HMDC). The nwipe program installed on the system should only be used by a knowledgeable IT staff member. EdLabs staff should not attempt to erase a disk without consulting HUIT or HMDC.
In the event a disk needs to be wiped of data, it should be removed from the RAID group and re-mounted as a stand-alone drive, as to not destroy any other critical data. If possible, the disk should be transported to HUIT or HMDC for proper wiping and destruction.
All accounts expire after one year, and require an administrator to extend by another year. You will receive mail notices starting one month before expiration. You can check mail via the command line with the mail package, or setup Thunderbird; see Section B.1.2.
All accounts receive mail; regular users, for example, will be notified of pending account expiration. Administrators receive logs and account expiration notices as well. Users can read mail through the Thunderbird application.
- Applications → Internet → Thunderbird
- Select "I think I’ll configure my account later."
- Menu → Preferences → Account Settings
- Account Actions → Add Other Account
- Choose "Unix Mailspool (Movemail)"
- Identity information
- Enter your first and last name under "Your Name"
- Replace "(none)" with "localhost" so it reads
[username]@localhost
- Outgoing Server Information
- Outgoing Server:
localhost - Outgoing User Name:
[username]
- Outgoing Server:
- Account Name can be renamed if desired
Mail is usually delivered by the system, but it is also possible to write mail person to person by sending to [username]@localhost.
Custom installed applications and packages are grouped together and can be found under Applications → EdLabs in the upper-left menu. Other applications are organized by function.
Software Collections is a special repository of newer packages than what ship standard with CentOS 7. There are several installed; list them with scl -l. See https://www.softwarecollections.org/en/scls/ for reference. Activate an environment with scl enable [collection] bash. To exit, just type exit.
To open the default 2.7 interpreter, use the EdLabs menu and select "Python 2.7", or from a command line type python. Python 3.4 is also available. Using the newer version of Python requires activating the 3.4 environment (scl enable python34 bash). (If you select "Python 3.4" from the EdLabs menu, a terminal running the python34 environment will open, it’s simply a shortcut.) Then run python like you normally would.
You can check the version of Python you’re using with python --version.
Any modules not already installed need to be downloaded from an internet connected machine and copied over to the level 5 workstation. See https://github.com/IQSS/Basket-Helper.
Once copied over, install with pip install --user [module_name].
Use the srm package to securely erase a file. Deleting a file with rm or through the file manager will not properly overwrite the data. The full command is srm [file]. For multiple files, separate the filenames with spaces. For directories with sub-directories and/or files, you can secure delete it all at once with srm -R [directory].
Note: srm is an alias for srm -D to ensure a 7-pass overwrite. If file permissions do not allow for deletion, see Section B.3.2.1.
When copying and creating files under /mnt/edlabs_data, files (and folders) will automatically inherit the group ownership "edlabs", which (usually) all users will belong to. This allows for collaborative work.
Note that if files are cut/pasted, or moved into edlabs_data, the original ownership and permissions will persist, which may preclude access by other team members. It is recommended to copy data only (or use rsync without the ‘archive’ or ‘retain ownership/permissions’ flags, see Section A.2.1.3.) when moving it onto the system.
An administrator is required to fix permissions. For folders, run sudo chmod -R 2770 [folder] or sudo chmod 770 [file] for files.
CentOS 7 has a new default location for mounting flash drives: /run/media/[username]/[drive]. Upon inserting a flash drive, a popup will appear at the bottom of the screen to indicate that the system has automatically mounted the drive. A new icon will also appear on the desktop. Right-click to eject and/or remove the drive.
Once the IronKey has been inserted, an unencrypted partition will automatically mount. This partition contains utilities for managing the IronKey, such as unlocking the encrypted data partition. Once unlocked, the data partition will also automatically mount.
Old style IronKey:
- Unlock:
/run/media/[username]/IronKey/linux/ironkey - Lock:
/run/media/[username]/IronKey/linux/ironkey --lock
New style IronKey:
- Unlock:
run/media/[username]/IRONKEY/linux/ironkey.exe - Lock:
/run/media/[username]/IRONKEY/linux/ironkey.exe --lock
After locking the IronKey, you will still need to unmount the drive (both data and utility partitions) by clicking the eject button, or right-clicking and selecting unmount/eject/remove (depending on partition).
A system script automates the entire process, no matter which version IronKey you are using. From a terminal:
sudo ironkey
Use the menu to:
- Option 1: unlock the IronKey
- Option 5: re-lock the IronKey
- Option 9: exit the script