NT also allows the creation of groups. Groups are created by command, rather than by file editing, using:

net group groupname /ADD

Users may then be added with the syntax,

net group groupname username1 username2... /ADD

They can also be edited with the GUI on a local host. NT distinguishes global groups (consisting only of domain registered users) from local groups, which may also contain locally registered users. Some standard groups are defined by the system, e.g.

Administrators

Users

Guest

The Administrators group has privileged access to the system.

5.3 Account policy

Most organizations need a strict policy for assigning accounts and opening the system for users. Users are the foremost danger to a computing system, so the responsibility of owning an account should not be dealt out lightly. There are many ways in which accounts can be abused. Users can misuse accounts for villainous purposes and they can abuse the terms on which the account was issued, wasting resources on personal endeavors. For example, in Norway, where education is essentially free, students have been known to undergo semester registration simply to have an account, giving them essentially free access to the Internet and a place to host their web sites.

Policy rules are required for guiding user behavior, and also for making system rules clear.

Experience indicates that simple rules are always preferable, though this is so far unsubstantiated by any specific studies. A complex and highly specific rule, that is understood only by its author, may seem smart, but most users will immediately write it off as being nonsense. Such a rule is ill advised because it is opaque. The reason for the rule is not clear to all parties, and thus it is unlikely to be respected.

Principle 20 (Simplest is best). Simple rules make system behavior easy to understand. Users tolerate rules if they understand them and this tends to increase their behavioral predictability.

What should an account policy contain?

1.Rules about what users are allowed/not allowed to do.

2.Specifications of what mandatory enforcement users can expect, e.g. tidying of garbage files.

Any account policy should contain a clause about weak passwords. If weak passwords are discovered, it must be understood by users that their account can be closed immediately. Users need to understand that this is a necessary security initiative. Closing Unix accounts can be achieved simply by changing their default shell in /etc/passwd to a script such as

#!/bin/sh

echo "/local/bin/blocked.passwd was run" | mail sysadm /usr/bin/last -10 | mail sysadm

message=’

Your account has been closed because your password was found to be vulnerable to attack. To reopen your account, visit the admin office, carrying some form of personal identification.

’

echo "$message"

sleep 10 exit 0

Although this does not prevent them from doing simple things on an X-windows console running a login manager, like xdm, it does prevent them from logging in remotely, and it gets their attention. A more secure method is to simply replace their encrypted password with NP or *, which prevents them from being authenticated.

It is occasionally tempting to create guest accounts for visitors and transient users. NT has a ready-made guest account, which is not disabled by default on some versions of NT. Guest accounts are a bad idea, because they can be used long after a visitor has gone, they usually have weak or non-existent passwords and therefore are an open invitation to attack the system. Shared accounts are also a bad idea, since they are inherently more fragile from a security perspective, though the use of shared Unix accounts, in which users could not log in as a shared user, are described in ref. [32]. This is similar to the ability in Unix to set a password on a group.

5.4 Login environment

When a new user logs in for the first time, he or she expects the new account to work straight away. Printing should work, programs should work and there should be no strange error messages about files not being found or programs not existing. Most users want to start up a window environment. If users will be able to log on to many different kinds of operating system, we have to balance the desire to make systems look alike, with the need to distinguish between different environments. Users need to understand the nature of their work environment at all times in order to avoid hapless errors. The creation of default login environments has been discussed in refs. [288, 15, 326] though these are now somewhat out of date.

5.4.1Unix environment

Unix and its descendents have always been about the ability to customize. Everything in Unix is configurable, and advanced users like to play around; many create their own setups, but many users simply want basics. The use of multitudinous ‘dot’ files for setting defaults in Unix has led to its being criticized for a lack of user-friendliness. Various attempts have been made to provide interfaces which simplify the task of editing these configuration files [125, 99], though the real problem is not so much the fact that one has to edit files, as the fact that every file has its own syntax. A system administrator has to ensure that everything works properly with acceptable defaults, right from the start. Here is a simple checklist for configuring a user environment. Gradually, the appearance of newer and better user interfaces like KDE and GNOME is removing the need for users to edit their own window configuration files.

•.cshrc If the default shell for users is a C-shell or derivative, then we need to supply a default ‘read commands’ file for this shell. This should set a path which searches for commands, a terminal type and any environment variables that a local system requires.

•.profile or .bashrc If the default shell is a Bourne-again shell like bash or ksh, then we need to supply this file to set a PATH variable, terminal type and environment variables that the system requires.

•.xsession This file is read by the Unix xdm login service. It specifies what windows and what window manager will be used when the X-windows system is started. The file is a shell script which should begin by setting up applications in the background (with a & symbol after them) and end up exec-ing a window manager in the foreground. If the window manager is called as a background process, the script will be able to exit immediately and users will be logged out immediately. Some systems use the file called .xinitrc though this file is officially obsolete. The official way to start the X11 window system is through the xdm program, which provides a login prompt window. GNU/Linux seems to have revived the use of the obsolete command startx which starts the X-windows system from a tty-shell. The older startx system used the .xinitrc file, whereas xdm uses .xsession. Most GNU/Linuxes hack this so that one only needs a .xsession file.

•.mwmrc This file configures the default menus etc. for the mwm window manager and the Common Desktop Environment (CDE) window manager, IIRC

A shell setup should define a terminal type, a default prompt and appropriate environment variables, especially a command path.

Suggestion 3 (Environment). It should always be clear to users which host they are using and what operating system they are working with. Default environments should be kept simple, both in appearance (prompts etc.) and in functionality (specially programmed keys etc.). Simple environments are easy to understand.

We need to aim a default environment at an average user and ensure that basic operating system functions work unambiguously. The visual clarity of a work environment is particularly important. In a windowing environment, this is usually not a problem. Command shells require some extra thought, however. A command shell can, in principle, be opened on any Unix-like host. A user with many windows open, each with a shell running on a different host, could easily become confused. Suppose we wish to copy a newer version of a file on one host to a repository on another host. If we mix the hosts up, we could risk over-writing the new version with an old version, instead of the other way around.

Suggestion 4 (Clear prompts). Try to give users a command prompt which includes the name of the host they are working on. This is important, since different hosts might have different operating systems, or different files. Including the current directory in the prompt, like DOS, is not always a good idea. It uses up half the width of the terminal and can seem confusing. If users want the name of the current directory in the prompt, let them choose that. Don’t assign it as a default.

Some systems offer global shell configuration files which are read for every user. These files are usually located in /etc or /etc/default. The idea of a global default file has attractive features in principle, but it is problematic in practice. The problem has to do with the separation of local modifications from the operating system, and also the standardization of defaults across all hosts. These files could be distributed from a central source to every host, but a better approach is to simply place an equivalent defaults file on the same distributed filesystems which contain users’ home directories. This is easily achieved by simply ignoring the global defaults, and giving every user a default shell configuration file which reads a site-dependent file instead.

Suggestion 5 (Unix shell defaults). Avoid host-wide files for shell setup in /etc. They are mixed up in the operating system distribution and changes here will be lost at upgrade time. Use an overridable include strategy in the user’s own shell setup to read in global defaults. Do not link a file on a different filesystem to these in case this causes problems during system boot-up.

Here is an example of a configuration file for the C-shell, which would be installed for all users in their home directories:

#

# cshrc file (for tcsh)

#

source ../.setupfiles/cshrc-global

#

# Place own definitions below

#

alias f finger alias ed emacs

Note that we use the source directive to read in a file of global C-shell definitions which we have copied into place from a central repository for all important system master files. Notice also that, by copying this onto the same filesystem as the home directory itself (the directory over the user’s home directory), we make sure that the file is always NFS exported to all hosts together with the home directory. This allows us to change the global setup for everyone at the same time, or separately for different classes of user on different partitions. For each separate home partition, we could have a different set of defaults. This is probably not recommended however, unless users are distinguished in some important way.

One of the functions of a local shell configuration is to set up a command path and a library path for software. Since the command path is searched in order, we can override operating system commands with local solutions, simply by placing site-dependent binaries at the start of the path. GNU file utilities and binary utilities can also be placed ahead of operating system standard utilities. They are often more standard and more functional.

5.4.2Example shell configuration

Here is an example shell configuration for the tcsh.

#!/bin/csh -f

##############################################################

#

#C Shell startup file

#System Wide Version.

##############################################################

umask 077 # default privacy on new files

setenv HOSTTYPE ‘uname‘

##############################################################

alias f finger alias h history alias go a.out alias cd.. cd .. alias grant setfacl alias cacls getfacl alias rlogin ssh alias rsh ssh

###############################################################################

#

# Check message of the day

#

###############################################################################

# Not always necessary

if ( -f /etc/motd ) then /bin/cat /etc/motd

endif

###############################################################################

#

# Check whether user has a vacation file

#

###############################################################################

160 CHAPTER 5. USER MANAGEMENT

if ( -f ~/.forward ) then

if ( "‘grep vacation ~/.forward‘" != "" ) then

echo ’*********************************************************’

echo ’*********************************************************’

endif

endif

5.4.3The privileged account’s or superuser’s environment

What kind of user environment should the superuser have? As we know, a privileged account has potentially dangerous consequences for the system. From this account, we have the power to destroy the system, or sabotage it. In short, the superuser’s account should be configured to avoid as many casual mistakes as possible.

There is no harm in giving Unix’s root account an intelligent shell like tcsh or bash provided that shell is physically stored on the root partition. When a Unix system boots, only the root partition is mounted. If we reference a shell which is not available, we can render the host unbootable.

The superuser’s PATH variable should never include ‘.’, i.e. the current directory. This is because it opens the system to a type of security vulnerability that can lead to accidental execution of the wrong command. For instance, suppose an ordinary user left a file called ls in the /tmp directory, and suppose the root account had the path

setenv PATH .:/bin:/usr/bin

If the superuser does the following

host# cd /tmp host# ls

then, because the path search looks in the current directory first, it would find and execute the program which had been left by the user. That program then gets executed with root privileges and could be used to give the user concerned permanent privileged access to the system, for instance by installing a special account for the user which has root privileges. It should be clear that this is a security hazard.

A common mistake that is frequently perpetrated by inexperienced administrators, and which is actually encouraged by some operating systems, is to run X11 applications with root privileges. Root should never run X11 or any other complex applications. There are just too many uncertainties involved. There are so many applications for X11 which come from different sources. There could be a Trojan horse in any one of them. If possible, root should only use a few trusted application programs.

The privileged user should never log in directly (unless the system is in single user mode or on the console). On Unix, one should log in as a user and su to root.