Theoretical OS Admin Defense Model

From Digibase Knowledge Base
Revision as of 14:40, 27 October 2013 by Kradorex Xeron (talk | contribs) (Created page with "==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 ma...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.
  • Admin Account 2 (AA2) - May administer the system, delete/prohibit user issue programs, update the operating system, monitor hardware.

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.

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