Lecture 6: OS - Level Security

목차

Learning Objectives

- Understand what is access control

- Be able to explain how OSs enforce access control

- Reason about pros/cons of different access control mechanisms and policies

 

 

What is an Operating System (OS)?

An operating system provides a useful way to interface with the hardware

Hardware resources are accessed through abstractions provided by the OS (e.g. CPU, Memory, Files, Network, Cursor)

 

운영 체제 (OS)는 모든 하드웨어와 소프트웨어를 관리하는 컴퓨터시스템의 한 부분인 '실행 관리자'이다. 운영체제는 누가 시스템을 사용할 수 있고, 어떻게 사용할 수 있는지를 관리한다. 

 

The System Call (Syscall) Interface

To access hardware sources, do system calls. 

 

 

시스템 호출: 입출력 제어 등 운영 체계(OS)의 기능을 요청하기 위해 응용 프로그램에서 사용되는 메커니즘.

커널은 컴퓨터 자원들을 관리하는 역할을 수행한다. 가장 큰 역할은 컴퓨터의 하드웨어와 추상화 자원을 관리하는 것이다. 여기서 추상화는 여러 사용자를 등록해서 사용할 때 마치 하나의 하드웨어를 독점하여 활용하는 것처럼 느끼게 한다. 커널은 이를 위해 하나의 하드웨어 자원을 여러 사용자들을 위한 여러 개의 추상화된 객체로 관리를 한다.

 

여기서 알아야 되는 것은 Application이 하드웨어 자원을 사용하려 할 때 커널에 syscall을 하고 이 커널이 컴퓨터 자원을 관리하기 때문에 그 결과값을 다시 syscall로 application에 전달한다.

 

 

OS-Level Security

An operating system manages resources (processes, threads, files, ...)

The OS must control access to these resources

Every subject must be identified, authenticated, authorized, and approved before it can perform an action on an object (resource)

 

여기서 subject = users, processes, 그리고 object = files, data

 

 

Why Access Control?

OS must guarantee the followign for all resources (even under attack):

- Confidentiality (비밀성, 기밀성)

허가되지 않은 자가 정보를 보지 못하도록 방지하는 것

 

- Integrity (무결성)

허가되지 않은 자가 정보를 변경할 수 없도록 하는 것.

 

- Availability (가용성)

허가된 자가 정보에 접근하려 할 때 방해가 없도록 하는 것. (악인들이 정보에 접근하는 것을 방지하고 적절하게 허가된 자만 접근할 수 있도록 하는 것)

 

Principle of Least priviledge: 

Limits users' access rights to only what is strictly required to do their jobs. 즉, 유저들의 액세스 제어를 최소한만 하게 해 준다 (딱 필요한 정도만).

 

 

Trusted Computing Base (신뢰 컴퓨팅 기반)

- All components the OS relies upon to provide security guarantees

- The TCB must be correct and untampered (변경되지 않은)

 

A Trusted Computing Base (TCB) refers to the set of all hardware, firmware, and software components within a computer system that are critical to its security. The TCB includes everything necessary to enforce the security policy of the system, ensuring its correct operation.

신뢰 컴퓨팅 기반: 운영 체제, 하드웨어 등이 포함된 컴퓨터 시스템 내의 총체적 보호 메커니즘. 

 

Threats to correctness (정확함에 방해되는 것들):

- Security bugs/vulnerabilities

 

Tampering risks (변경/조작할 수 있는 위험 요소들) :

- Modification of OS binaries

- Rootkits

- Backdoors

 

여기서 Rootkits: malicious software to gain unauthorized access to a computer system or network and maintain control over it while remaining hidden from detection. 즉, 허가되지 않은 접근을 하는 악성 소프트웨어로 발견되지 않은 상태로 시스템이나 네트워크를 컨트롤하려고 함.

 Backdoor: hidden method or mechanism within a software application, operating system, or network that allows unauthorized access to the system. 즉, 숨겨 저 있는 것으로 인증 절차를 받지 않고 액세스를 하려고 하는 것.

 

Threat Model

Threat Model describes:

- what are we protecting (assets)?

- Which protection measures do we put in place?

- What are the threats and their capabilities?

 

Why does this matter?

We only know if a security measure makes sense if we know the threat model (matters for evaluating security and depends on scenario)

 

Summary of our threat model:

- Assets: software-based entities (objects)

- Threats: software-based entities (subjects)

- Protection: correct/untampered TCB + access control

 

 

Safe Sharing: The Gold Standard

Problem: The conflicting concepts of sharing and isolation

Goal: Safe sharing

The gold standard standard for for safe sharing:

- Authenticate (진짜임을 인증)

- Authorize (권한을 부여받음)

- Audit (검사 / 감사)

 

 

How does an OS enforce Access Control?

Login Process

Performs initial identification and authentication of users (allows users to provide id to the OS)

Spawns a shell for the user (shell : program that allows users to interact with the OS by commands)

 

Reference Monitors (참조 모니터)

Checks every access to a sensitive resource

Authorizes or prevents the access

 

Auditing (검사, 감사)

Registers access control decisions

 

 

 

Identification & Authentication

Login Process:

- Identifies and authenticates users

- Access control subjects are software entities (users are not subjects)

- Different ways to identify and authenticate users:

e.g. security token, password, fingerprint, geographic location

 

Identity Propagation (신원 전달):

- Logic processes starts shell (TUI or GUI) with your user id

- By default, every object (e.g. file, thread, process) you create inherits your user id (the object has the same id as the shell)

- User id can be changed but there are some exceptions (e.g. setuid binaries)

 

 

Reference Monitors (참조 모니터)

Invoked whenever a subject attempt to access a resource (즉, 대상이 자료에 액세스를 하려 할 때마다 콜 됨)

Can be modelled as a function:

RefMonitor(subject, object, action) => OK or NOT_OK

Returning NOT_OK cancels the action

Every reference monitor can enforce a different policy.

E.g. File access checks → Discretionary Access Control (DAC)

E.g. Process manipulation → Mandatory Access Control (MAC)

 

참조 모니터는 주체의 객체에 대한 모든 접근 통제를 담당하는 추상 머신으로서 승인되지 않은 접근이나 변경으로부터 객체를 보호하기 위하여 객체에 대한 모든 주체의 접근 통제를 중재하는 개념이다.

 

 

Discretionary Access Control (DAC)

Owner of an object decides access control policy (객체의 주인이 액세스가 가능한지 안 한지 정함)

Access control decisions based on identity of the subjects

Most common access control policy for file access checks

 

+ Easy to implement

- Some implementations are very coarse-grained (e.g. POSIX file permissions) (조잡하다)

- Cannot enforce global policy (e.g. files can never be shared with guest users)

 

 

Access Control Matrix

Global matrix that species which actions each subject can perform on each object

Con: Incredibly large/sparse on real-world systems => impractical (takes a lot of space) --> Access Control Lists

 

 

Access Control Lists (ACLs)

Separate list of actions each subject can perform

Stored with/attached directly to the object

 

Matrix는 너무 사이즈가 크기 때문에 리스트로 사용

 

 

POSIX permissions and Windows/Linux/macOS ACLs are all forms of access control lists

 

 

 

Capability Lists

List of permitted actions stored with the subject

Typically used to give subjects permissions to perform specific (normally priviledged) actions

 

 

ACL과 Capability List의 차이는 subject과 object. 즉, ACL에서는 각 object마다 어떤 subject가 어떤 행동을 할 수 있는지, 얼마나 access control이 있는지 보여주고 Capability List에서는 각 subject가 어떤 object에 어떤 행동을 할 수 있는지를 보여준다.

 

 

Mandatory Access Control (MAC)

OS sets the access control policy.

Ensures that organizational security policies cannot be (intentionally or accidentally) overriden by users

Traditionally used in Multilevel security:

- Assign security labels to all objects and subjects 

- Reference Monitor allows or denies actions based solely on security label of object and subject

 

즉, 운영 체제가 직접 접근 제어 방책을 정한다. 각 object과 subject마다 security label을 배정하고 이 label들을 참조 모니터가 확인해서 허가할지 거부할지 정함.

 

 

MAC Model 1: Bell-LaPadula

Bell-LaPadula (confidentiality) -> information cannot flow to a lower security level.

(Practical use: prevent company/government secrets from leaking to unpriviledged subjects)

Cons: 

- Priviledged subjects cannot share information with lesser priviledged subjects

- Cannot enforce integrity (무결성: 허가되지 않은 자가 정보를 변경할 수 없도록 하는 것)

- Hard to handle changes in security levels (tranquility)

 

 

MAC Model 2: Biba

Biba (integrity) => subjects at lower integrity level cannot modify objects at higher level

+ Practical use: protect system processes against malicious user processes

Cons: 

- High integrity subjects cannot receive information from lower-integrtiy subjects

- Cannot enforce confidentiality

- Cannot handle changes in integrity levels

 

No read up (integrity): A subject at a certain integrity level (e.g., low) is not allowed to read data from objects at higher integrity levels (e.g., medium or high). This prevents lower-integrity subjects from accessing or corrupting higher-integrity data.
No write down (integrity): A subject at a certain integrity level (e.g., high) is not allowed to write data to objects at lower integrity levels (e.g., medium or low). This prevents higher-integrity subjects from corrupting or degrading the integrity of lower-integrity data.

 

여기서 integrity level은 subject와 object에 배정된다 based on trustworthiness or reliability in maintaining the integrity of data.

 

Pure implementations of Biba, Bell-LaPadula or similar models are impractical but commercial OSes do implement MAC.

Core idea:

- Flexible security servers that can implement many different types of policies

- Support for security/integrity label updates, propagation and revocation

 

 

Case Study: Windows Group Policies

Windows has a huge MAC-based access control infrastructure

 

 

Case Study: setuid/setgid binaries

By default, all processes/threats inherit the user id of their creator

There are many cases where we would prefer to launch binaries under a different user id. Examples;

- Servers / Browsers → interact with untrusted entities. Run as unpriviledged user

- Login Process → must be able to see user/password info. Run as priviledged user

- Package Managers → must have access to configure packages for all users. Run as priviledegd user

Solution: setuid/setgid binaries → Launch with uid/gid of their owners

 

 

Case Study: Superusers

Priviledged users can create superuser process

Superuser processes bypass all access control checks

 

e.g. sudo [command]  (Runs command as superuser)

e.g. su [user name]  (launches a shell with a different user id)

 

 

Trusted Computing Base (Revised)

OS Kernel과 하드웨어만 신뢰컴퓨팅 기반에 포함된 게 아니라 Priviledged Processes도 포함.

 

 

Audit (검사/감사, 책)

- Accountability/auditability

All mainstream OSes have vast auditing/logging facilities