Operating System (OS)

The software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals

Operating Systems (OSes)

Amoeba

A microkernel-based OS

  • The idea was to take a whole network of computers and make them into one machine

    • When a process was started, it could start on a different machine entirely without the user even being aware of which machine his or her process was running on

    • Different processes can exist, run and access resources on other computers in the system, which is all transparently handled by the overall distributed OS that runs across the different computers in the system

Amoeba Capabilities

  • Amoeba uses capabilities to avoid having the OS do constant authentication on different machines in the same system since this would be very burdensome on the system, as well as slow it down

    • Each object in the Amoeba OS resides on a server

    • To perform an operation on an object, a subject would send a message to the server, which would contain the proof of capability, the object and the action that the subject wishes to perform on the object, as well as a check field to ensure that capabilities could not be modified

    Amoeba Capabilities

  • The most important part of this system from a security perspective is how it handles capabilities and how those capabilities can be verified while remaining unforgeable

    • The way capabilities work in Amoeba is that when a server creates an object, it returns the owner capabilities to the owner

    • Whoever created the new object becomes its owner and they have a rights field (A bit string that contains zeros, which represents permissions that you don't have, and ones, which represents permissions that you do have) where they have all permissions on it

    • All the permissions bits for the owner's capabilities are set to one (Allowed) and then it generates a check field(A random secret number that's generated and only known by the server and the owner), which contains a random 48-bit number that is stored server-side and sent to the owner

    • When the owner wants to grant capabilities for an object to another subject, they can set some of the rights bits' to zero (Not allowed) and calculate a new check field

    • This allows you to do delegation without involving a trusted third party or server

    • The server can verify the rights and check field

    • Without the owner capability, you cannot forge a derived capability since the secret is in the check field (When the owner creates a new capability ticket, they generate a new check field using the new rights and gets XORed (exclusive or) together with the old check field using a one): checkn = H(checkn-1 XOR rightsn)

    • The owner will create a new rights field for a subject and set the bits for all the permissions that they don't want them to have to 0 and then will generate a new check field for that subject that (The owner takes the subject's new rights and the owner's old check field and he XORs them together, then he takes the secure hash of the output, which gives him a new check field

      • The owner can send this new rights string (rightsn) and the new check string (checkn) over to the subject they want to grant access to

      • That subject can then send it to the server, who has the old check field as well

      • The server can the XOR the new rights string with the old check field and hash that value, and if it matches the new check field then access is granted

Revoking Permissions

  • All you have to do is change the random check value and issue a new capability, which will make none of the old capabilities have their check fields match when the server goes and tries to match it with the new hash value
    • It's not a very fine-grained way to do trust revocation since you can't really go and revoke some people's tickets, but it does provide an effective mechanism

Android

Android Architecture

Android Architecture

  • Applications

    • Unprivileged within the system

  • Applications framework

    • Different aspects of the Android OS that go and provide services to the applications
    • They also call down and access other libraries and other functionalities within the system

  • Libraries

  • Android runtime

  • Linux Kernel

    • Provides access to the individual components

Android Access Model

  • Single-user devices have a different access control focus than multi-user devices

  • Assuming that a device has only one user allows the access control mechanism to focus on isolating applications from each other, called Sandboxing

    • A Sandbox is a virtual machine that runs as a separate UID from a Linux perspective (Remember that there's a Linux kernel at the bottom of the Android architecture)

    • so now, instead of having each user running all their apps with the same permissions, now every app runs with its own set of permissions on your Android phone

    • Each application has its own unique UID and communicates with data or resources on the system through a Reference Monitor and through Android middleware that eventually translates down into a Linux kernel

Android Access Model

Android Manifest File

  • Allows developers to define an access control policy for access to components

    • Each component can be assigned an access permission label
    • Each application requests a list of permission labels (fixed at install time)

    Android Manifest File Example

MULTICS

A time-sharing operating system that allowed multiple Processes to use the same machine all at once, which meant that no one could not make superficial assumptions about one Process not being able to access the memory or state of another

  • No longer in use today
  • it used Virtual addresses
  • it was written using a high-level language
  • it used a shared memory multiprocessor
  • it had a Relational Database
  • at the time, it was considered the best when it came to security

Pros

  • was written using a high-level language
  • used a shared memory multiprocessor

Cons

  • was the first successful operating system to have security as a consideration from the beginning, it had issues and turned out to be unwieldy to use in practice, which lead to the creation of UNIX

Demonstrates how different processes could be stopped from bypassing access control by using a few security designs, such as:

Virtual Memory

Ring Structure

  • Rings were domains in which a Process executes in

  • Rings were numbered and the lower the number (0 being the lowest), the more privileges the Process had

  • Every Process had all the privileges of every ring numbered above the ring it was executing in

    • ex: A Process in ring 1 would have all the privileges in ring 1, as well as the privileges in rings 2, 3, and so on)

Segments

  • Segments were data and text areas within a program that you could call into

  • Subjects could not call into the middle of a segment, but instead, they would call a segment at a restricted segment entry point

    • This was to avoid the issue of subjects jumping into the middle of a segment, past the portions of code that handled the access control, in order to ensure that they weren't granted unauthorized access

Channels

MULTICS Processes

  • Each process consisted of multiple segments that were dynamically linked

  • The linking process used the file system to find segments, which may be shared by several processes

  • Processes could have procedures and data segments in multiple rings, and access depended on two mechanisms: a per-segment access control mechanism and concentric rings of protection

    • The per-segment access control allowed file authors to specify the users that had access to it,
    • while the concentric rings of protection forced access to inner rings to go through a gatekeeper, which ensured access was authorized

  • Process communicated with each other through channels, which was a way of communicating data through different processes and different rings efficiently and securely

UNIX

It's the modern successor to MULTICS and a multiuser, multitasking OS designed for flexibility and adaptability

UNIX is composed of:

Users

  • Each user has a user ID (UID), which is a unique identifying number that is linked to their username
  • In addition to each normal user, there are a few other special user accounts
    • Root, which has a UID of 0 and can do almost anything in the system
    • Owner, which is the user who owns the data, where ownership gives you certain permissions
    • daemon/sys, which handles some important services
    • Guest, which is used for site visitors
    • FTP
    • UUP
    • LP
    • etc.

Groups

Each group has a unique Group ID (GID) and are useful for access control feature since they follow an easy way to quickly apply some coarse access control rules to users

  • Each user in a system belongs to at least one group
  • In addition to normal groups, we also have a few other special groups
    • "Wheel" group, which is the group of system administrators
    • UUCP
    • LP
    • etc.

Permissions

Permissions: read, write and execute

  • UNIX has three categories of subjects that you need to specify permissions to

    • Owner

    • Group

    • Other (Everyone else in the system)

    • The only people who can change these permissions are the Owner and the Root

    • UNIX permissions are stored as ACLs in a structure called an inode (A structure used to store UNIX permissions)

  • Permissions can be stored in different formats, such as:

    • Octal

    • 0 - No permissions at all

    • 1 - execute

    • 2 - write

    • 4 - read

      • Example:
      • The owner can read, write and execute: 1 + 2 + 4 = 7
      • The group can read and write: 2 + 4 = 6
      • The others can't do anything: 0 The final octal representation of this example: 0760

    • Letters and Dashes

    • - --- --- ---

      • The first - represents the type of object

      • The first group of --- represents the permissions given to the owner

      • The second group of --- represents the permissions given to the group

      • The last group of *---*represents the permissions given to others

      • Example:

        • the owner has read, write and execute permissions
        • the group has read and write permissions
        • the others have no permissions
        • The final representation of this example: - rwx rw- ---

User File-Creation Mode Mask (umask)

A four-digit octal number that UNIX uses to determine the file permission for newly created files

  • Specifies the permissions that you do not want to be given by default to newly created files and directories

  • It works by doing a bitwise AND with the bitwise complement of the umask (Bits that are set in the umask correspond to permissions that are not automatically assigned to newly created files)

    • Example: 0666

Set User ID (setuid)

A special type of file permission in Unix and Unix-like operating systems (ex: Linux, BSD, etc.) that permits users to run certain programs with escalated privileges

  • This is done with the help of different user IDs

Types of IDs

  • RUID (Real User ID) - Used for accounting our overall system to help understand what's happening within a system

  • EUID (Effective User ID) - Used to look at what permissions you're supposed to have for the operations that you're doing within a system

  • SUID (Saved User ID) - Used to store original user IDs so that you can later restore and revert a process back to its original user ID

  • etc.

Windows (NTFS+)

  • In general, Windows permissions are more flexible than UNIX permissions and offer explicit denies and explicit permissions for the deletion of objects

    • Windows partial administrator access can be given, which is different from UNIX

  • Subjects are defined using a security ID (SID)

    • In addition to storing the SID, Windows also stores a revision number for this value and a 48-bit authority value

Windows Access Control

Permissions are implemented as ACLs that specify permissions based on the user and the group

  • Their ACLs include:

    • the security identifier of the entity that owns the object
    • the regular ACL for access permissions
    • a system ACL that is used for auditing
    • A group security identifier

  • Each of these ACLs is compromised of an Access Control Entity (ACE), which is compromised of basic permissions such as

    • read
    • write
    • execute
    • delete
    • change access permissions
    • take ownership

  • There are several types of ACEs

    • Access-allowed ACEs, which allow access rights
    • Access-denied ACEs, which explicitly deny access rights
    • Access-denied ACEs always take precedence over access-allowed ACEs, meaning that if a subject is part of a group that is explicitly denied access, they will not be able to read the file, even if their user account is given explicitly allow access
    • System audit ACEs, which are used in ACLs to generate an audit record when the trustee attempts to exercise the specific access rights

Windows Permission Inheritance

  • When a child object is created, it inherits the properties of the parents, and the children and parents remain linked

  • Whenever a parent's permissions are changed, the children are updated to have the same permissions as well

    • Permission inheritance can be sometimes confusing when trying to figure out a child object's permissions inside of a large system since you'd have to go find and look at its parent object's permissions in order to do so

OS as a reference monitor

One can think of the OS as a reference monitor sitting between user-level applications and the resources of the machine

  • Access control decisions are made by the OS depending on the security policy

    • This is simplified by associating processes with users and storing ACLs with files that state that users can read, write and/or execute them

  • In addition to files, processes are also access-controlled

    • One process cannot write into the memory of another process
    • Some actions require superuser privilege, which is guarded by processes like setuid, and are relinquished when the operation is completed

  • Additionally, the OS does access control that is totally invisible to the user: It enforces CPU sharing, disk quotas, and other protection policies (These policies are granted at the user level, so all processes running as a given user have the same policy applied to them)

OS VMs - What does an OS VM do?

  • A hypervisor, which can also be thought of as a translator for the hardware to the VM, also acts like a reference monitor

    • The hypervisor mediates access to the hardware between “processes”, which in this case are VMs, and provides a very limited namespace so there cannot be accidental leaking of resources and data to other VMs

    • The hypervisor also provides a simplified programming abstraction to perform these duties, ensuring that every access operation has to go through the reference monitor

    • At this level of abstraction, it’s much easier to restrict resource consumption than on the OS level because typically there is less VMs than processes running on a typical OS

Containerization

What Do OSes Do?

Process Isolation

You need to make sure that two or more processes that are running on the same machine do not interfere with each other in any way, but still have ways of communicating with each other

  • This is usually a difficult task and is handled by things like Inter-process communication

Programming Abstraction

In order to ensure this is easier to do for programmers, the OS must provide a layer of abstraction for programmers to write their code (This is done by providing programmers with functions, etc., that interact with the OS)

  • ex: fopen in Linux
    • by doing this, OSes attempt to make things easier for the programmer and more secure for the system by controlling the way in which programmers can access resources/This interface is a way to interact with the reference monitor

Restrict Resource Consumption

In addition, the OS needs to restrict resource consumption on the machine

  • If it doesn’t restrict consumption, one process can hog all resources and starve the other processes on the machine

Modern OSes have a lot going on

  • The more processes we have running on a modern system, the more complicated it becomes, and the more complicated it becomes, the more difficult it is to reason about the security properties of the system, and how well the system will work at a given point in time

Why does resource isolation matter?

  • Consider a malicious application that wants to deny services to other applications

    • If the OS doesn’t control resources, what stops this application from taking up all the memory to stop them from being able to compute, or from writing to the entire disk to deny other processes the ability to store information?

    • What stops it from overloading the network so no other computers in the area can effectively communicate?

  • The security of a modern machine relies on resource isolation