![[Menu Bar]](/images/header.gif)
Every user of ARSC systems can rightfully expect his or her e-mail, programs, data, documents, etc., to be inaccessible to others, secure against arbitrary loss or alteration, and available for appropriate use, at all times.To help achieve this goal of protecting system security, ARSC system administrators reserve the right to routinely examine certain features of user accounts, such as the permissions set on environment files, the contents of specific environment files, and encrypted passphrases. ARSC also reserves the right, in cases of suspected security incidents, to inactivate and examine the contents of user accounts, without prior notification.
This policy affects all authorized users of ARSC resources.
A violation of standards, procedures, or guidelines established pursuant to these policies may result in disciplinary action, including loss of system privileges and, in the case of criminal activity, legal prosecution.
ARSC employs several mechanisms to enforce its user security policies, including:
In order to minimize the exposure of remote login sessions to session hijacking vulnerabilities, ARSC has instituted a timeout daemon that limits both the total amount of time a user can stay logged in to a system and the amount of time that a login session can be idle*.
* From the man page for the timeout daemon tool:
"A session is considered idle if it has not received any tty activity (i.e. the user hasn't actively sent any data or
typed any commands, and the system hasn't sent any data back to the user)."
ARSC operates an unclassified and non-sensitive computing environment. Do not introduce classified or sensitive work on ARSC systems.
Report your suspicions. For instance, if a file in your directory seems to have changed, but you don't remember having changed it, contact User Services.
To protect the security of your account and the system in general, please guard your SecurID Card as closely as your driver's license and memorize your PIN.
)
immediately. We can provide you with temporary access to your
account and block anyone else who might attempt to use your
card.
Please read the following requirements for your Kerberos password (or passphrases). For suggestions on choosing a good passphrase, see our passphrase guidelines document.
To enforce the above requirements, ARSC analysts periodically run passphrase cracking programs. If your kerberos passphrase is vulnerable, we will attempt to contact you to change it. If you are unreachable, we will reset it and/or inactivate your account.
If you feel that your default passphrase has been compromised, contact User Services immediately and we will issue you a new one.
While collaboration is important, and we would like to make it as easy as possible, the following policies are designed to:
You may not share your account with anyone under any circumstances.
This requirement makes every user solely accountable for all actions from his or her account. Two examples of account sharing are listed here, both are considered violations:
Please note that appropriate methods for sharing data exist, such as project accounts and group access granted by Unix permissions. Contact us for assistance.
(This section does not apply to home directories, which are a special case. For our home directory policy see the following section.)
Permissions in Unix grant three types of access (read,write,execute) to three different groups (account owner,people in the same group,the world). Giving write access to the world is incompatible with the concept of a secure system.
World-write permissions are not allowed on any directories or files in any area of your account. World-write permissions are automatically removed from all user files and directories on all filesystems. Files and directories with world-write permissions:
Group permission grants access to a known set of users. As this implies a far greater level of control, this is the recommended method of collaboration. Quite frequently read (and possibly execute) group permission is all that is required. However, when members of a group are trading information (a two-way interchange, as opposed to a one-way dissemination) granting group-level write permission for a specific group of files within the subset of directories that must be write-enabled should be sufficient. This exposes your data to change by a known set of people. We will be glad to work with you to manage group memberships.
| Recommended Permissions For File Sharing | |
|---|---|
| Non-home directories/files | 770 or 750 |
Your home directory must never be group-writable or world-writable. This is a special case because those who can make changes in your home directory can do so many things to destroy the integrity of your account. However, group-read or group-execute permission is acceptable. Collaborators may read the contents of your home directory (with the exception of the dot files listed below) and they may cd through to subdirectories with the appropriate permissions.
| Recommended Permissions | |
|---|---|
| Home Directory | 700, 710, or 750 |
Because of the potential security risk presented by environment, or "dot" files, ARSC routinely checks the permissions set on all .login, .profile, .cshrc, .kshrc, and other such files to see that they are safe.
Environment files are executed automatically as a consequence of some normal, frequent activity on your part (like logging on). They are a prime target for anyone trying to compromise your account. Thus they must never be group-writable or world-writable. Also, symbolic links that take the place of dot files are not permitted. Further restrictions are described in the table below.
We will attempt to contact you to make the required permission changes in the case of a violation of these dotfile policies. However, because of the seriousness of the exposure that some permissions can impose on the entire system, your account may be inactivated without notice until you call User Services to acknowledge the required change.
| Dot File/Directory | Description | Recommended Permissions |
|---|---|---|
| .Xauthority | contains xauth magic cookie | 600 only |
| .Xdefaults, .Xresources, .xinitrc, .xsession | X Window System environment files | 400, 440, 600, or 640 |
| .cshrc, .tcshrc, .kshrc, .login, .profile, .bashrc,.bash_login, .bash_profile, .bash_logout, .logout | csh/tcsh/ksh/bash initialization files, executed only on login or logout | 400, 440, 600, or 640 |
| .exrc | ex, vi resource file | 400, 440, 600, or 640 |
| .forward | mail forwarding file | 400, 440, 600, or 640 |
| .netrc | file with configuration information for ftp access to a remote machine. | 400, 440, 600, or 640 |
|
.pgp directory Files in this directory |
information for PGP encryption |
700 600 or 400 |
| .shosts | file of trusted remote hosts and account names for SSH | 400 |
|
.ssh directory Files in this directory |
information for SSH encrypted connections |
700 600 or 400 |
.rhosts files are unnecessary. We recommend the use of ssh and the Kerberized versions of the various r-commands (krlogin,krcp, etc.) instead of the commands which utilize the .rhosts file.
If .rhosts files are used, ARSC policies are:
.netrc files contain login information and configuration data for ftp access to remote machines. When ftp opens a connection to a specified remote machine, it checks for this file in the user's home directory on the machine initiating the file transfer.
ARSC policies on .netrc files are:
An .Xauthority file contains keys (magic cookies) used by xauth to authenticate X Window System requests to initiate processes on remote systems. If someone could read this file, they could obtain a key and circumvent the security provided by xauth.
ARSC policies on .Xauthority files are:
When a user executes a file that has the SUID bit set, the program runs with the system access permissions of the user who owns that program and not with the permissions of the user who executed it. Similarly, setting the SGID bit causes programs to run with the group permissions of the file's owner. While this behavior is needed to give root permissions to specific files, it can create security problems when used on a regular user file. Thus, ARSC policy does not permit the SUID and/or SGID bits to be set for regular, user files.
ARSC periodically runs tools to check for the presence of SUID and SGID files. We will contact you if these tools find any SUID or SGID files that are owned by your account and assist you in removing those permissions.
Non-printing characters, such as ASCII codes for RETURN or DELETE, are occasionally introduced by accident into in file names.
They present a low-level risk to system security and integity, and are disallowed.
They cause problems retrieving files from system backups, and with scripted verification. Almost invariably, they cause confusion for the owner and group owners of the file, who have trouble renaming, deleting, or using the files because the file names simply aren't as they appear to be.
Techniques for dealing with non-printing characters are described in ARSC's "How-To" document, Removing Non-printing Characters from File Names.
Due to regular security issues with web-based mobile code technologies (e.g. Java Applets, Javascript, etc.), ARSC recommends that these technologies be disabled by default when browsing the web. These technologies should be enabled as needed when accessing trusted websites.
ARSC periodically scans systems for viruses and malware. If viruses or malware are detected on an ARSC system, ARSC will quarantine the suspected file(s) and then notify the owner of the file(s).
Do not try to break passphrases, tamper with system files, look into anyone else's directories, or otherwise abuse the trust implicit in your account. Your privileges do not extend beyond the directories, files, and volumes which you rightfully own or to which you have been given permission.
Access to ARSC systems from locations outside of the US requires that an international access form be filed with ARSC. This form must be processed prior to using ARSC systems outside of the United States.
You may not let your account sit idle for extended periods of time. Log on every two weeks, and do basic user maintenance, particularly, changing your passphrase and checking for suspicious activity. If this is not possible, contact User Services to inactivate your account during your absence.
ARSC enforces this policy by inactivating accounts after 90 days without user activity.
An inactive account is unchanged except that the owner will not be able to access it. When you try to log onto an inactive account, you will be given a message to contact User Services and will then be logged out. To reactivate your account, contact User Services.
Arctic Region
Supercomputing Center
PO Box 756020, Fairbanks, AK 99775 | voice: 907-450-8600 | email:
home | search | about | support | news | science | resources