CS代写 CSE 127: Introduction to Security

CSE 127: Introduction to Security

Winter 2022 Lecture 6
Some slides from , , , , , , , , and

Principles of secure system design
1. Least privilege
2. Privilege separation
3. Complete mediation
4. Fail safe/secure
5. Defense in depth
6. Keep it simple

1. Principle of Least Privilege

1. Principle of Least Privilege
• Usersshouldonlyhaveaccesstothedataandresources needed to provide authorized tasks

Principle of Least Privilege
• Usersshouldonlyhaveaccesstothedataand resources needed to provide authorized tasks
• Examples:
• Faculty can only change grades for classes they teach
• Only employees with background checks have access to classified documents

2. Principle of privilege separation

2. Principle of privilege separation
Least privilege requires dividing a system into parts to which we can limit access:
• Breaksystemintocompartments
• Ensureeachcompartmentisisolated
• Ensureeachcompartmentrunswithleastprivilege • Treatcompartmentinterfaceastrustboundary

Example: Multi-user operating system
In this system:
• Userscanexecuteprograms/processes
• Processescanaccessresources

Multi-user OS security properties
• Memoryisolation
• Process should not be able to access
another process’s memory.
• Resourceisolation
• Process should only be able to access certain resources.

Process memory isolation
• Howareindividualprocesses memory-isolated from each other?
• Each process gets its own virtual address space, managed by the operating system
• Memoryaddressesusedbyprocessesarevirtual addresses (VAs) not physical addresses (PAs)
• The CPU memory management unit (MMU) does the translation

3. Principle of complete mediation

3. Principle of complete mediation
• Everymemoryaccessgoesthroughaddresstranslation
• Load, store, instruction fetch
• Virtual memory allows address space much larger than physical memory
• Also means that operating system mediates all process memory accesses and enforces access control policy

Resource isolation in the Unix security model
In Unix, everything is a file: files, sockets, pipes, hardware devices…
• PermissionstoaccessfilesaregrantedbasedonuserIDs • Every user has a unique UID
• AccessOperations:Read,Write,Execute • Eachfilehasanaccesscontrollist(ACL)
• GrantspermissionstousersbasedonUIDsandroles (owner, group, other)
• root(UID0)canaccesseverything

Role-Based Access Control
In a general access control system we can specify permissions in a matrix:
hw/ cse127-instr r/w cse127-tas r/w
cse127-students read cse-students –
exams/ grades/
r/w r/w r/w
read – r/w – – read

ACLs vs. Capabilities
ACL: System checks where subject is on list of users with access to the object.
• Permissionsstoredbycolumnof access control matrix
Capabilities: Subject presents an unforgeable ticket that grants access to an object. System doesn’t care who subject is, just that they have access.
• Rowofaccesscontrolmatrix

Unix file permissions are a simplified ACL
l s – l total 32 -rw-rw-r– 1 rabeshi cse127-a-wi 18660 Jan 14 00:34 index.html
drwxrwxr-x 2 rabeshi cse127-a-sp drwxrwxr-x 2 rabeshi cse127-a-sp drwxrwsr-x 3 rabeshi cse127-a-sp
4096 April 13 08:42 pa
4096 April 13 19:57 resources 4096 April 14 00:34 slides
• Permissionsgroupedbyuserowner,groupowner,other • Operations: read, write, execute

Process UIDs
Process permissions are determined by UID of user who runs it unless changed.
• RealuserID(RUID)
• Usedtodeterminewhichuserstartedtheprocess
• TypicallysameastheuserIDofparentprocess • EffectiveuserID(EUID)
• Determinesthepermissionsforprocess
• CanbedifferentfromRUID(e.g.becausesetuidbitonthefilebeingexecuted)
• SaveduserID(SUID)
• EUIDpriortochange

Difference Real and Effective User ID in Linux

• Aprogramcanhaveasetuidbitsetinitspermissions • Thisimpactsforkandexec
• Typically inherit three IDs of parent
• If setuid bit set: use UID of file owner as EUID
-rwsr-xr-x 1 root root 54256 Mar 26 2019 $ ls -ltr /usr/bin/passwd -rwsr-xr-x 1 root root 54256 Mar 26 2019$ passwd

Overview of Unix file security mechanism
• Pro:Simpleandflexible • Con:
• Nearlyallsystemoperationsrequirerootaccess.
• In practice, common to run many services as root. This violates principle of least privilege and increases attack surface.

Kernel isolation
• Kernelisisolatedfromuser processes
• Separate page tables
• Processor privilege levels ensure userspace code cannot use privileged instructions
• Interfacebetweenuserspace and kernel: system calls

Example: Smartphone OS design
Does the threat model for a smartphone differ from a desktop?

Mobile Security vs Computer Security

Android process isolation
• Android uses Linux and sandboxing for isolation.
• EachapprunsunderitsownUID.
• Apps can request permissions, which are basically capabilities.
• Android has a well-developed notion of app/app access control.
• Heavily relies on user’s consent, for better or worse.

Software fault isolation (SFI)
Placing untrusted components in their own address space provides isolation, but comes with overhead.
Software fault isolation wants to partition apps running in the same address space.
• Kernel modules should not corrupt kernel • Native libraries should not corrupt JVM
SFI approach: Partition process memory into segments
• Memory isolation: Instrument all loads and stores
• Controlflowintegrity:Ensureallcontrolflowisrestrictedto CFG that instruments loads/stores
• Complete mediation: Disallow privileged instructions
• Syscall-likeinterfacebetweenisolatedcode

Example: Browser design
What’s the threat model?
What are the assets?
What security properties do we want to preserve?

Chrome Security Architecture
Pre-2006 Modern

Modern Browser Security Model
• Browserprocess
• Handles the privileged parts of browser (network requests, address bar, bookmarks)
• Rendererprocess
• Handles untrusted attacker content: JSengine, DOM, etc.
• Communication restricted to remote procedure calls
• Manyotherprocesses(GPU,plugin,etc.)

Virtual Machines
• Virtualmachinesallowasinglepieceof hardware to emulate multiple machines
• Usefulforcloudcomputingandalsofor isolation
• Intelhashardwaresupportforx86 virtualization: VMM support in
hardware so that operating system
can be run in ring 0 without requiring VMM intervention for syscalls

VMs and Isolation
VM Isolation for the cloud:
• VMsfromdifferentcustomersmayrunonthesamemachine • Hypervisor tries to isolate VMs to minimize information leaks
VM Isolation for the end user:
• QubesOS:AdesktopOSwhereeverythingisaVM. • EverywindowframeUIidentifiesVMsource.

Hardware isolation: Secure enclaves
• IntelSoftwareGuardeXtensons(SGX)
• Runs trusted code in an enclave
• Enclave memory encrypted and only decrypted in the CPU
• Can’t be read even by malicious OS
• WhydowewanttoprotectaprogramagainstamaliciousOS?
Example applications:
• DRM (Digital Rights Management)
• Secure remote computation
• Protecting crypto keys or sensitive information

iOS Secure Boot
• Apple devices use a secure enclave coprocessor as part of its boot chain.
• Hardware-based root of trust: code and code-verifying keys baked into boot ROM (read-only memory).
• Each step of the boot process verifies that the bootloader, kernel are signed by Apple.
• What are the positives and negatives of this kind of design?

Physical isolation: Air gap
• To ensure that a misbehaving app cannot harm the rest of the system, you could run it on physically isolated system.
• What kinds of systems would you do this for? What are the merits/demerits?

4. Principles: Fail-safe and Fail-secure

4. Principles: Fail-safe and Fail-secure
A fail-secure system is one that, in the event of a specific type of failure, responds in a way such that access or data are denied.
• Related: a fail-safe system, in the event of failure, causes no harm, or at least a minimum of harm, to other systems or to personnel.
Fail-secure and fail-safe may suggest different outcomes
• For example, if a building catches fire, fail-safe systems would unlock doors to
ensure quick escape and allow firefighters inside, while fail-secure would lock doors to prevent unauthorized access to the building.

5. Principles: Defense in depth

5. Principles: Defense in depth
We do not expect any of our defenses to be perfect.

Last. Principles: Keep it simple

6. Principles: Keep it simple
We have to trust some components of our system.
In general keeping the Trusted Computing Base small and simple makes it
easier to verify.
• Intheoryahypervisorcanbelesscomplexthanafullhostoperating system.
• AsmallOSkernelhaslessattacksurfacethanonewithmanyfeatures.

Software and hardware isolation techniques
• Memoryisolation
• Resourceisolationandaccesscontrol • Systemcallinterposition
• Sandboxing
• Containers
• Virtualization
• Secureenclaves
• Physicalairgap
Lesson: Complete isolation is often inappropriate;
applications need to communicate through regulated interfaces

Principles of secure system design
1. Least privilege
2. Privilege separation
3. Complete mediation
4. Fail safe/closed
5. Defense in depth
6. Keep it simple

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts