![[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 (phone: 907-450-8602 or
e-mail: 
).
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.
When ARSC resets your passphrase, it uses your "default" passphrase. At any time, if you feel that your default passphrase has been compromised, contact User Services immediately and we will issue you a new one. ARSC will not communicate passphrases via phone or e-mail.
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:
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 ARSC consulting (907-450-8602) 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 | csh/tcsh/ksh initialization files, executed only on login | 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 |
| .sgisession | console startup | 400, 440, 600, or 640 |
| .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 the security considerations discussed below, and until further notice, ARSC is disallowing the execution of Java and related code downloaded from the Internet. Such code includes:
The SGI system copy of Netscape has had the world execute permissions of the associated Java interpreter removed. Use of JavaScript, however, cannot be globally disabled, and since it is not possible to know in advance whether a requested web page contains JavaScript, when using Netscape you are required to disable JavaScript locally:
Use of other Java-enabled browsers for viewing downloaded Java related code is similarly disallowed. World execute permissions have also been removed from the SGI system copy of appletviewer.
If you wish to use Netscape and/or appletviewer to view locally developed code, you may apply to be added to the SGI java group. The java group has execute permissions for the system copies of the Netscape Java interpreter and appletviewer. To apply you need to contact User Services. You do not need to be a member of the java group to execute locally developed standalone java applications.
Java applets and javascript enable web page developers to include within a web page snippets of JavaScript, or make java applet calls. When executed by a web browser, the java applet or javascript snippet dynamically generates content for that web page. As more web pages make use of this feature, more web browsers appear with the ability to accommodate them.
When you download a web page containing java applets or javascript, and your browser has java or javascript enabled, that code is automatically executed. It is not possible to know in advance the presence, or purpose of the code. Although java applets and javascript were specifically designed to disallow certain actions, such as modifying or deleting files, reports regularly reach ARSC of newly discovered exploitable security holes and bugs found in both of them. Some of these security holes enable hostile applets to execute arbitrary commands to modify or delete important system or user files.
Java and related languages are relatively new and are undergoing rapid development. It is hoped that as they mature these security holes will be firmly plugged. ARSC is monitoring their development.
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.
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 ARSC
User Services (phone: 907-450-8602 or e-mail: ).
Arctic Region
Supercomputing Center
PO Box 756020, Fairbanks, AK 99775 | voice: 907-450-8600 | email:
home | search | about | support | news | science | resources