OS Security Features/Terms

Microkernel architecture

• What it is: An approach to operating system design emphasising small modules that implement the basic features of the system kernel and can be flexibly configured.
• What it’s good for: Separating system and user memory effectively and intelligently. The use of messages allows efficient security filters as well.
• Potential problems: Costly to develop and run traditional UNIX system calls very slowly.

Security Kernel

• What it is: The hardware, firmware, and software elements of a TCB that implement the reference monitor concept. It must mediate all accesses, be protected from modification, and be verifiable as correct.
• What it’s good for: Ensuring that the system security policy is enforced during every transaction.
• Potential problems: Costly to develop.

Least Privilege

• What it is: The principle that requires that each subject be granted the most restrictive set of privileges needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.
• What it’s good for: Ensuring that users and processes don’t have access to things they don’t need access to.
• Potential problems: More people required as task sharing is removed.

Reference Monitor Concept

• What it is: An access-control concept that refers to an abstract machine that mediates all accesses to objects by subjects.

Discretionary Access Controls (DAC)

• What it is: A means of restricting access to objects based on the identity and need-to-know of the user, process and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject.
• What it’s good for: A simple access control model that allows for the highest level of usability. (this should be read as “allows users to most easily violate security policy” ;)) This model is sufficient for the majority of commercial level systems.
• Potential problems: The power of this model is based on its granularity and comprehensiveness. The ability to specifically deny access and not just relying on a lack of specific granting of access is critical to ensuring rights do not propagate to unintended subjects.

Mandatory Access Controls (MAC)

• What it is: A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i. e., clearance) of subjects to access information of such sensitivity. The Bell-LaPadula model is the most common and states that subjects cannot read objects of a higher sensitivity and cannot write to objects of a lower sensitivity, thus it is a hierarchical model. Lattice based models are frequently referred to as “Type Enforcement.”
• What it’s good for: Securing systems with multi-levels of security (since the labels cannot be removed or altered as a rule), securing simple servers, securing network hubs that connect to network segments at different security levels
• Potential problems: More difficult to establish an initial security policy. This tends to result in a poor configuration and maintenance headaches, while requiring more skilled administrators. In hierarchical models, data moves up the model (from low confidentiality to high) to higher and higher sensitivity until eventually everything on the system is So_Top_Secret_Even_the_Name_is_Secret. ;)

Role Based Access Controls (RBAC)

• What it is: A form of identity-based access controls where the system subjects are identified and controlled as functional positions in an organization or process.
• What it’s good for: Very simple security administration, including simple role rotation.
• Potential problems: Roles frequently migrate during the course of a project. For example a subject may be forbidden from accessing an object that is being developed, but may be required access to it once the object is completed. Unless these changes are defined at install via a scheduled RBAC system, there are few advantages to using this model as maintenance can be costly

Domain Based Access Controls (DBAC)

• What it is: This is similar to type enforcement and similar to traditional DAC. Rather than defining access controls based on a uid, they are based on domains. In this instance a domain is defined as the resources required by a process. This includes memory and file accesses. An example would be an http_domain(rwx), an object or subject may have multiple domain attributes assigned to it. These rights tend to be mandatory, that is they cannot be changed however select subjects and objects can be made unaware of the DBAC policy, these subjects by default cannot access DBAC controlled objects, but DBAC aware subjects can access unaware objects.
• What it’s good for: This is a very simple way to add a more advanced access controls to a server systems. Primarily effected at controlling integrity and preventing total system compromise.
• Potential problems: Increased cost of administration, though less than other methods. Perhaps insufficient controls regarding the disclosure of information within the domain. (for example remote DB access)

Integrity Labels

• What it is: Similar to confidentiality labels used in hierarchical MAC, but regarding integrity instead. The Biba model is the most common. This model restricts subjects from reading objects of a lower sensitivity and more importantly preents objects from writing to objects of a higher sensitivity.
• What it’s good for: This ensures that low sensitivity subjects don't overwrite high sensitivty objects when used with the Bell-LaPadula confidentiality model.
• Potential problems: Eventually all objects migrate toward the lowest level of integrity.

Network Flags

• What it is: An immutable label attached to a user’s authorization data that identifies how the user in question connected to the host. This may include a NIC identification and port number.
• What it’s good for: Ensuring that remote users can only access data intended for for the specific service they are using in a very simple manner. (everything in http_root gets “port=80” flag added and you are done)
• Potential problems: May require a migration away from some traditional network architectures if you’d like remote users to do things like login on ssh and modify http files.

Crash on Audit Failure (CAF)

• What it is: A mechanism that forces the system to shutdown in the event of a failure in the audit trail.
• What it’s good for: Ensuring that no unmonitored activity can occur on the system.
• Potential problems: A sacrifice of availability for forensics.

Segregation of Administrators and Operators

• What it is: The single superuser account concept is replaced with two (or more) weaker users whose aggregate power is nearly equal to a superuser account. All of these administrator and operator accounts must exist within the context of the security policy.
• What it’s good for: Ensuring that total system compromise is avoided in in the event that a privileged account is compromised. This may include the retention of system logs. Mitigates the effects of a rouge administrator.
• Potential problems: Require additional administration staff, if you give a single user access to both, the whole point is defeated.

Loss of privilege on fork()

• What it is: A mechanism that removes all authorization data from a processes launched with a fork() call.
• What it’s good for: Ensuring that an attacker can never launch a new process like a root shell by breaking an application. Additionally, unlike many other security modifications, this requires no additional training or other cost of ownership increases.
• Potential problems: Systems using this mechanism can clearly not run applications that utilize child processes. Consequently all services must be multithreaded. Although this is a good thing, many popular applications (apache 1.x, most bind and sendmail installs, etc)

Structured Type Enforcement

• What it is: An architecture that breaks the system into several lateral components. Information does not flow between these compartments, barring trusted processes.
• What it’s good for: Ideal choice for proxying firewall appliances, where a single data path is never required to cross multiple compartments.
• Potential problems: Requires multi-tiered systems for simple data flow across services. Expensive to develop.

Trusted Path

• What it is: A mechanism by which a person at a terminal can communicate directly with the TCB. This mechanism can only be activated by the person or the TCB and cannot be imitated by untrusted software.
• What it’s good for: Ensuring that you login credentials are going to the right place.
• Potential problems: None. Every system should feature this.

Trusted Facilities Manual

• What it is: A guide/set of guides outlining various procedures and or checklists that can be used to bring the system to it’s most secure state for its given tasks.
• What it’s good for: Ensuring that a system is correctly configured to its most secure state.
• Potential problems: None. Every system should feature this.

Maintenance Hook

• What it is: Special instructions in software to allow easy maintenance and additional feature development. These are not clearly defined during access for design specification. Hooks frequently allow entry into the code at unusual points or without the usual checks, so they are a serious security risk if they are not removed prior to live implementation. Maintenance hooks are special types of trap doors.
• What it’s good for: Speedy and open development.
• Potential problems: More and more systems are including too many such hooks. Windows in its constant pursuit of more features. And Linux basically has the design model of being one big hook, all part of being easy to modify.

Secure Subsystems

• What it is: A subsystem that contains its own implementation of the reference monitor concept for those resources it controls. However, the secure subsystem must depend on other controls and the base operating system for the control of subjects and the more primitive system objects.
• What it’s good for: Selected process isolation, overcomes some of the general use difficulties associated with type enforcement and less complexity than DBAC. Particularly ideal for controlling elements like the audit trail output.
• Potential problems: May require multiple administrator accounts

Trusted Computing Base (TCB)

• What it is: The totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to enforce correctly a unified security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user’s clearance level) related to the security policy.

I prefer to list just the basics, if this were too long, none of you would read it. ;) If you have any questions about specifics just ask.

Selected Ref:
Glossary of Computer Security Terms
http://www.radium.ncsc.mil/tpep/libr...CSC-TG-004.pdf

cheers,

catch