Theoretical OS Admin Defense Model

Document Status

This is a theory alone, there may be implementation details that may not be adequtely addressed.

Preface

Operating systems today have difficulty in maintaining secure due to over-use of administrator accounts. These accounts are conventionally set up to enable the computer owner, primary user or system administrators to perform maintenence with ease. This over-use has been battled by Microsoft with the implementation of UAC to enable people to operate conventionally as conventional users, only elevating privleges as needed, but in general, such a mechanism isn't enough as in general, current systems only have one or more admin accounts that has access to and can change or modify everything.

Definitions

For the intents of this document, definitions are as follows:

Defining an Admin Account

An admin account is an account that posesses abilities to do one or more of:

• Control the system
• Maintain system resources (drivers, answer alerts, etc)
• Control (create, delete, reset passwords of, maintain data of) user accounts
• Install software

Definining a System

A system may consist of a corporate network with a centralized login mechanism (AD and/or LDAP based) or single user computer.

The problem?

Inline with the preface, often times these admin accounts are set up and given to users to make installing software easy or to make accessing whatever system resources there may be simple instead of having definitive divisions in security. This results in scenerios where users affirmate installation of malware or exploits in browsers then escalate or socially engineer and manage to install malware that may damage the system (consider the ZeroAccess trojan).

The solution?

Create two seperate administrator accounts with the following permissions as follows:

• Admin Account 1 (AA1) - May administer user accounts, access user files but may not execute any programs other than those relating to user administration. Antivirus scans of user data and user-installed programs may be performed from this account. To open user files for inspection purposes, this admin user may "Open As" either the Inspection Admin or a regular user with correct permissions to write.
• Admin Account 2 (AA2) - May administer the system, delete/prohibit user issue programs, update the operating system, monitor hardware.
• Inspection Admin (IA) - This account may open/read all files, run any user programs but may not make any changes.

Both AA1 and AA2 would not be permitted to access any user programs such as web browsers, games, word processors (other than basic text editors) and so forth. There would be no way to escalate between such.

Software installation

Since administrators would not have access to run any programs not related to system administration, to install programs a user could (at the administrator's activation) install programs to a restricted location, and the administrator can approve/prohibit programs. The administrator may optionally make a user-installed program available to all users or just the individual.

Administrator software installation

Occasionally additional tools may be required other than what the operating system provides to properly maintain the system. The AA2 account holder(s) may copy a tool to an offline media (such as a USB stick) from their regular user account and then while admin "sign" that program to run. Program would require re-signing if updates occur. Programs signed by AA2 may optionally be made available to AA1: for instance antivirus software.

But this is too complex

Behind the scenes, any proper security mechanism has many layers but those layers may be consoledated at the front-end user interface. In this case it is by way of providing proper menus to permit for example AA1 to inspect files with the IA account. However the barrier between AA1 and AA2 would be preserved.