S 2.32 Establishment of a restricted user environment

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

If users only need to perform certain tasks, it is often not necessary to assign each of them a separate user account with the corresponding scope of rights or even system administrator rights. Examples of such tasks include certain routine system administration tasks like creating backups or setting up new users (a task usually performed using a menu-driven program) or tasks in which a user only needs to use a single application program. It should be ensured that users are only able to use the services and access the data they actually need, especially in the case of temporary employees and external service providers. If such employees are terminated, then their accounts should be deactivated and all access authorisations deleted (see also S 4.17 Blocking and erasure of unneeded accounts and terminals).

A restricted user environment should be created for these users. This can be realised on a Unix system, for example, using the restricted shell (rsh) and by restricting the access paths using the Unix command chroot. For a user who only needs to use a single application program, the restricted shell can be assigned as the user's login shell so that it is started directly after the user logs in and logs the user out automatically after the user exits the program.

The range of functions provided by the IT system can be restricted for individual users or user groups. The use of editor programs or compilers should be prevented if the user does not need these programs to perform his tasks. This can be accomplished on stand-alone systems by removing such programs and on networked systems by assigning the user the appropriate rights.

Microsoft Windows

The following presents security features of different versions of Microsoft Windows that can be used to restrict a user environment by implementing technical safeguards.

Microsoft Windows NT and all later versions offer the ability to use start scripts to restrict the access available to a user to individual applications. It must be ensured in this case that such a user cannot interrupt or otherwise change the execution of the scripts. For example, the scripts run for a user who has logged in could be executed invisibly in the background. The application started must not offer the user any functionality that can be used to start other programs.

In Windows 7 and Windows Server 2008 R2 and higher the access to applications can be blocked by means of AppLocker and enabled by an administrator, if necessary (see S 4.419 Application control in Windows 7 and higher by means of AppLocker).

In Windows Vista and higher the User Account Control (UAC, see also S 4.340 Use of the Windows User Account Control UAC in Windows Vista and higher) makes it easier to work flexibly with restricted user rights for administrators and normal users. Through the UAC, all user operations within the system generally run with standard user rights, even if the user is logged in to an administrator account. For administrative operations such as printer installation or network configuration and for programs which can only run with administrator rights, such as older specialist applications, Windows shows a confirmation window intended to provide additional protection against Trojans and malicious software. The administrator authorisations are not activated until confirmation by the user. They are restricted to the relevant operation or the application. All other and following operations run parallel with restricted user rights. Instead of the confirmation message, standard users receive a protected login screen where they or a member of the IT support can log in to an administrator account. The current user operations are not interrupted in this case. This provides a user-friendly alternative to the runas command.

The Parental Controls can be used by an administrator to specify restrictions for a user when he is using a Windows Vista and Windows Server 2008 system and higher. Parental Controls support the design of usage restrictions based on the following criteria:

Parental Controls are not designed for professional use, though. The restrictions possible using the parental controls should be realised in a professional environment by implementing alternative safeguards.

KDE and GNOME in Linux

The KDE and GNOME Linux user interfaces contain an elevation prompt for administrators within restricted user environments comparable to the Windows User Account Control. This should be used in the same way.

Review questions: