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 and the contents of specific environment files. ARSC also reserves the right, in cases of suspected security incidents, to inactivate and examine the contents of user accounts, without prior notification.

• Scope
• Enforcement
• Workstation Console Login Sessions
• Security Level
• Security Awareness
• SecurID Cards
• University of Alaska Passwords
• Access to directories and environment files
  • Account Sharing
  • Non-Home Directory/File Permissions
  • Home Directory Permissions
  • Environment (or "Dot") Files/Directories
  • rhosts policy
  • netrc policy
  • Xauthority policy
  • Executables with SUID/SGID Bits Set
• Non-printing Characters in File Names
• Web-Based Mobile Code
• Viruses and Malware
• Tampering
• International Access
• Sabbaticals & Other Absences
• Additional Policies for Academic Systems
  • SSH Public Keys

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:

• Contacting the user and asking him/her to correct the problem
• Changing the permissions on the user's home directory to 700
• Inactivating accounts on individual ARSC systems
• Disabling access to all ARSC systems
• Inactivating and/or recalling the user's SecurID card

ARSC hosts visualization and access labs on the UAF campus. These labs contain Apple Macintosh computers and/or Linux workstations. The following policies apply to all systems located in the visualization and access labs:

• Physical console logins take priority over remote logins.
• Users must lock their screens when physically leaving the visualization or access lab.
• ARSC may disconnect idle terminal sessions to minimize the exposure of remote login sessions to session hijacking.

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.

This clause only applies to accounts which have been assigned a SecurID.   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.

• Don't let anyone else use your SecurID Card.
• Don't share your PIN, write it down, or let anyone see it as you key it in.
• If you misplace your SecurID Card- Contact ARSC User Services (phone: 907-450-8602 or e-mail: consult@arsc.edu ) immediately.
• If your PIN number is compromised, contact ARSC so we can assign a new PIN number.

Passwords used on ARSC systems are subject to University of Alaska (UA) password guidelines.  We  encourage the use of passwords at least 15 characters in length using multiple character classes.  

Password Recommendations:

• length: passwords should be at least fifteen characters long.
• password composition:  passwords should use a mixture of alphabetic (A-Z, a-z), numeric (0-9), and non-alphabetic characters (digits, punctuation marks, symbols, etc.).
• password aging: passwords should be changed periodically.  We recommend every six months.

If you feel that your default password has been compromised, contact User Services immediately so that we can check the status of your account.   You may change your UA password using the ELMO webpage (https://elmo.alaska.edu).

While collaboration is important, and we would like to make it as easy as possible, the following policies are designed to:

• Ensure access is only given to the parties intended
• Keep access to an account (and its environment) solely in the hands of its owner

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:

• password sharing- Don't give anyone your SecureID Card, PIN, and/or password.
• .rhosts file- Don't give anyone, other than yourself, rlogin permissions via your .rhosts file. (Please review the .rhosts files policies for details. )

Please note that appropriate methods for sharing data exist, such as project accounts and group access granted by Unix permissions. Contact us for assistance.

Non-Home Directory/File Permissions

(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:

• increase the risk of an unauthorized person adding files, modifying file contents, or deleting data.
• decrease our ability to maintain overall data integrity
• are unnecessary in all but a very small set of cases

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.

Home Directory Permissions

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.

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.

rhosts policy

.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:

• .rhosts files may give access only between ARSC systems.
• Host names must be fully qualified domain names, e.g., "system.arsc.edu"
• The userid in the .rhosts file must match the login id of the home directory that contains the .rhosts file.
• .rhosts files must not be writable by anyone : not even the owner.
• file permissions must be 400 or 440.

netrc policy

.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:

• no passwords are permitted in .netrc files unless the username is "ftp" or "anonymous."
• users may not maintain passwords for ARSC systems in .netrc files stored on other computers

Xauthority policy

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:

• The file permission for the .Xauthority file MUST be 600.

Executables with SUID/SGID Bits Set

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 passwords, 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 password and checking for suspicious activity. If this is not possible, contact User Services to inactivate your account during your absence.

Enforcement

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.

The following policies apply to ARSC academic systems only and do not apply to HPCMP resources.

On systems where use of ssh public key authentication is allowed, each key entry in the ~/.ssh/authorized_keys must specify a hostname using the authorized_keys " from= clause. NOTE: HPCMP systems operated by ARSC do not permit the use of this access method. e.g. from="system.arsc.edu" ssh-rsa ...

• Wildcards may not be used within a " from= clause in the ~/.ssh/authorized_keys file without prior approval from User Services.
• ARSC periodically runs checks to verify that the contents of ~/.ssh/authorized_keys are compliant with this policy.
• Sharing of private keys to allow another user to access your ARSC account is not permitted and constitutes account sharing.
• Permissions on the ~/.ssh/authorized_keys must abide by the dot files policy for .ssh directory files.
• Users of ssh public keys are responsible for ensuring that the private key are not accessible by other persons. ARSC encourages the use of a non-null passwords on ssh public keys to avoid use by unintended parties. Private keys should only be generated and stored on systems which you trust.