BCOS Home » The BCOS Project » BCOS Specifications » BCOS Application Notes

BCOS Security Model Application Note

Preliminary Draft, Temporary

Project Map

Contents:

Chapter 1: Overview

This Application Note is intended to explain the security model used by the operating system. It is expected that this document will be superceded by later specifications, and exists only as a reference for developers until it is superceded.

Chapter 2: Permissions

In general; the security system used by the OS involves checking if a subject (a user or executable) has permission to perform an operation on a resource (e.g. a file or directory). Each resource has an owner, and a table that describes the security category and a security level within that security category for each operation that can be performed on that resource. For each subject, every security category is given a minimum and maximum permitted security level.

To determine if an operation is allowed, the OS first checks if the subject is the resource's owner and grants permission if the subject is the resource's owner. Otherwise (if the subject is not the resource's owner) the OS uses the security category for the operation to find the subject's minimum and maximum security level for that category; then checks that the security level for the operation is not smaller than subject's minimum security level for the category and that security level for the operation is not larger than subject's maximum security level for the category.

Figure 2-1. Permission Check Pseudocode
 
    if(subject == resource.owner) {
        * Permission Granted *
    } else {
 
        securityCategory = resource[operationNumber].securityCategory
        securityLevel = resource[operationNumber].securityLevel
 
        if( securityLevel < subject[securityCategory].minimumSecurityLevel ) {
            * Permission Denied *
        } else if( securityLevel > subject[securityCategory].maximumSecurityLevel ) {
            * Permission Denied *
        } else {
            * Permission Granted *
        }
    }

2.1. Subject IDs

Every user and every executable is assigned a subject ID. A subject ID is a 32-bit unsigned integer, where the highest bit determines if the subject is a user or an executable such that subject IDs from 0x00000000 to 0x7FFFFFFFF correspond to users and subject IDs from 0x80000000 to 0xFFFFFFFFF are executables.

Some subject IDs are given fixed meanings. These are described in Table 2-1. Fixed Subject ID Assignments.

Table 2-1. Fixed Subject ID Assignments
Subject IDDescription
0x00000000Anonymous/Guest
0x00000001Cluster Owner (see Subsection 2.1.1. "Cluster Owner" Role)
0x00000002Head Infrastructure Officer (see Subsection 2.1.2. "Head Infrastructure Officer" Role)
0x00000003Head Security Officer (see Subsection 2.1.3. "Head Security Officer" Role)
0x80000000Operating System (e.g. boot code and kernel)

Security Officers are responsible for creating and managing subject IDs (including creating user's accounts, resetting user passwords when they're forgotten, etc).

2.1.1. "Cluster Owner" Role

The cluster owner is assumed to be the person who "owns" the cluster (e.g. the president of a company) who may not have any technical knowledge and delegates various tasks to other people. The cluster owner is treated like a normal user, except that they have the ability to change the Head Infrastructure Officer's password and the Head Security Officer's password; and the Head Security Officer and other Security Officers (and the Head Infrastructure Officer and other Infrastructure Officers) are unable to change the cluster owner's password. This is specifically intended for situations where the Head Infrastructure Officer or Head Security Officer needs to be replaced but may become a "disgruntled employee" (e.g. a malicious attacker with full access/control over a company's critical systems).

2.1.2. "Head Infrastructure Officer" Role

The Head Infrastructure Officer is reponsible for managing a team of none or more Infrastructure Officers; and collectively the team of Infrastructure Officers (including the Head Infrastructure Officer) are responsible for the provision and maintenance of infrastructure (things like backups, disaster recovery plans, monitoring hardware, replacing faulty hardware, upgrading hardware, etc).

The operating system has an Infrastructure Management Tool that Infrastructure Officers (including the Head Infrastructure Officer) use to perform their duties. When an Infrastructure Officer (including the Head Infrastructure Officer) logs into the operating system the Infrastructure Management Tool is started (instead of a normal GUI or application), and Infrastructure Officers are unable to do anything outside of the Infrastructure Management Tool. For this reason Infrastructure Officers don't participate in the operating system's security model (e.g. they are never the subject in a permission check).

2.1.3. "Head Security Officer" Role

The Head Security Officer is reponsible for managing a team of none or more Security Officers; and collectively the team of Security Officers (including the Head Security Officer) are responsible for creating and upholding security policies.

The operating system has an Security Management Tool that Security Officers (including the Head Security Officer) use to perform their duties. When an Security Officer (including the Head Security Officer) logs into the operating system the Security Management Tool is started (instead of a normal GUI or application), and Security Officers are unable to do anything outside of the Security Management Tool. For this reason Security Officers don't participate in the operating system's security model (e.g. they are never the subject in a permission check).

2.2. Security Categories

Each security category has an ID and a name. The name is only used for display purposes. A security category ID is a 20-bit unsigned integer, and the security category ID of 0x00000 means "none" (the owner of the resource is the only subject able to be granted permission to peform the operation). This gives 1048575 security categories that can be used.

Security Officers are responsible for creating and managing security categories (including assigning names to them).

2.3. Security Levels

Security levels are 4-bit unsigned integers. This gives 16 security levels for each security category.

Security Officers may give security levels names (e.g. top secret, secret, confidential, ...); and if security levels are given names those names are only used for display purposes.

2.4. Operation Permissions

For each operation that may be performed on a resource, a 32-bit field is used to contain the information that the Security Manager needs to know about that operation. These bits are described in Table 2-2. Operation Permission Format.

Table 2-2. Operation Permission Format
Bit/sDescription
0 to 3Security level (see Section 2.3. Security Levels)
4 to 23Security category ID (see Section 2.2. Security Categories)
24 to 31Reserved for Security Manager's internal use (e.g. for fine grained control of audit logging, etc)

The Security Manager may/should encrypt the raw 32-bit values so that the Virtual File System and all file systems are unable to (maliciously) tamper with permissions.

Chapter 3: Components

The Operating System's security model depends on the cooperation of multiple components.

3.1. Security Manager

The Security Manager is the central component in the Operating System's security model, which is run on each computer within the cluster. It is responsible for storing, maintaining and using a database of information that includes:

The Security Manager is responsible for implementing three messaging protocols (none of which are currently designed or documented):

The Security Manager also creates any audit logs (if enabled)

3.2. Virtual File System

The Virtual File System is responsible for asking the Security Manager to perform permission checks for all file system operations.

3.3. Station Managers

Station Managers are responsible for handling the user log in prompt, asking the Security Manager to perform log in security checks, providing "save file as currently logged in user" functionality on behalf of applications, and coordinating the transfer of applications between users.

Generated at 20:05:50 on the 28th of June, 2017 (UTC)