Operating System Security, Con’t CS 136 Computer Security Peter Reiher October 20, 2011

Outline Interprocess communications protection File protection and disk encryption Protecting other OS resources Logging and auditing

Protecting Interprocess Communications Operating systems provide various kinds of interprocess communications Messages Semaphores Shared memory Sockets How can we be sure they’re used properly?

IPC Protection Issues How hard it is depends on what you’re worried about For the moment, let’s say we’re worried about one process improperly using IPC to get info from another Process A wants to steal information from process B How would process A do that?

Message Security Process A Process B That’s probably not going to work Gimme your secret That’s probably not going to work Can process B use message-based IPC to steal the secret?

How Can B Get the Secret? He can convince the system he’s A A problem for authentication He can break into A’s memory That doesn’t use message IPC And is handled by page tables He can forge a message from someone else to get the secret But OS tags IPC messages with identities He can “eavesdrop” on someone else who gets the secret

Can an Attacker Really Eavesdrop on IPC Message? On a single machine, what is a message send, really? A message is copied from a process buffer to an OS buffer Then from the OS buffer to another process’ buffer Sometimes optimizations skip some copies If attacker can’t get at processes’ internal buffers and can’t get at OS buffers, he can’t “eavesdrop” Need to handle page reuse (discussed earlier)

Other Forms of IPC Semaphores, sockets, shared memory, RPC Pretty much all the same Use system calls for access Which belong to some process Which belongs to some principal OS can check principal against access control permissions at syscall time Ultimately, data is held in some type of memory Which shouldn’t be improperly accessible

So When Is It Hard? Always possible that there’s a bug in the operating system Allowing masquerading, eavesdropping, etc. Or, if the OS itself is compromised, all bets are off What if it’s not a single machine? What if the OS has to prevent cooperating processes from sharing information?

Distributed System Issues What if your RPC is really remote? Goal of RPC is to make remote access transparent Looks “just like” local The hard part is authentication The call didn’t come from your own OS How do you authenticate its origin?

The Other Hard Case Process A Process B Process A wants to tell the secret to process B But the OS has been instructed to prevent that A necessary part of Bell-La Padula, e.g. Can the OS prevent A and B from colluding to get the secret to B?

OS Control of Interactions OS can “understand” the security policy Can maintain labels on files, process, data pages, etc. Can regard any IPC or I/O as a possible leak of information To be prohibited if labels don’t allow it

Covert Channels Tricky ways to pass information Requires cooperation of sender and receiver Generally in active attempt to deceive system Use something not ordinarily regarded as a communications mechanism

Covert Channels in Computers Generally, one process “sends” a covert message to another But could be computer to computer How? Disk activity Page swapping Time slice behavior Use of a peripheral device Limited only by imagination

Handling Covert Channels Relatively easy if you know what the channel is Put randomness/noise into channel to wash out message Hard to impossible if you don’t know what the channel is Not most people’s problem

File Protection Files are a common example of a typically shared resource If an OS supports multiple users, it needs to address the question of file protection Simple read/write access control What else do we need to do?

Standard Access Control for Files Basic application of typical access control mechanisms Usually ACLs Issues of complete mediation come up Checked on open vs. on use But what about the raw disk?

The Disk and File Systems Most file systems are stored on disks Disks are also devices OS can access them below the file system interface Can be moved to other machines How do we protect file data under these circumstances?

Encrypted File Systems Data stored on disk is subject to many risks Improper access through OS flaws But also somehow directly accessing the disk If the OS protections are bypassed, how can we protect data? How about if we store it in encrypted form?

An Example of an Encrypted File System Issues for encrypted file systems: When does the cryptography occur? Ks Where does the key come from? Transfer $100 to my savings account Sqzmredq #099 sn lx rzuhmfr zbbntms What is the granularity of cryptography?

When Does Cryptography Occur? Transparently when a user opens a file? In disk drive? In OS? In file system? By explicit user command? Or always, implicitly? How long is the data decrypted? Where does it exist in decrypted form?

Where Does the Key Come From? Provided by human user? Stored somewhere in file system? Stored on a smart card? Stored in the disk hardware? Stored on another computer? Where and for how long do we store the key?

What Is the Granularity of Cryptography? An entire disk? An entire file system? Per file? Per block? Consider both in terms of: How many keys? When is a crypto operation applied?

What Are You Trying to Protect Against With Crypto File Systems? Unauthorized access by improper users? Why not just access control? The operating system itself? What protection are you really getting? Data transfers across a network? Why not just encrypt while in transit? Someone who accesses the device not using the OS? A realistic threat in your environment?

Full Disk Encryption All data on the disk is encrypted Data is encrypted/decrypted as it enters/leaves disk Primary purpose is to prevent improper access to stolen disks Designed mostly for laptops

HW Vs. SW Full Disk Encryption HW advantages: Probably faster Totally transparent, works for any OS Setup probably easier HW disadvantages: Not ubiquitously available today More expensive (not that much, though) Might not fit into a particular machine Backward compatibility

Example of Hardware Full Disk Encryption Seagate’s Momentus 7200 FDE.2 line Hardware encryption for entire disk Using AES Key accessed via user password, smart card, or biometric authentication Authentication information stored internally on disk Check performed by disk, pre-boot .15 Gbytes/sec sustained transfer rate Primarily for laptops

Example of Software Full Disk Encryption Microsoft BitLocker Doesn’t encrypt quite the whole drive Unencrypted partition holds bootstrap Uses AES for cryptography Key stored either in special hardware or USB drive Microsoft claims “single digit percentage” overhead One independent study claims 12%

Protecting Other Resources Devices The processor itself

Protecting Devices Some handled through file system protection/authentication Others by only allowing kernel to access them User access mediated by the kernel Assumes kernel will be careful in what it allows users to do Sometimes issue with alternate access E.g., Firewire interfaces

Protecting the Processor Mostly about protecting processes from each other But also about ensuring user-level processes can’t execute privileged instructions Most typically, instructions OS needs to do its work Syscalls used to explicitly change mode

Presumptions for Processor Protection Assume context switch code clears out all info from old process Registers, etc. Model is that processor is clean and devoted only to current user Switch to privileged mode is explicit Don’t allow arbitrary user code to run in this mode

Logging and Auditing An important part of a complete security solution Practical security depends on knowing what is happening in your system Logging and auditing is required for that purpose Often (partially) built into OS

Logging No security system will stop all attacks Logging what has happened is vital to dealing with the holes Logging also tells you when someone is trying to break in Perhaps giving you a chance to close possible holes

Access Logs One example of what might be logged for security purposes Listing of which users accessed which objects And when and for how long Especially important to log failures

Other Typical Logging Actions Logging failed login attempts Can help detect intrusions or password crackers Logging changes in program permissions A common action by intruders Logging scans of ports known to be dangerous

Problems With Logging Dealing with large volumes of data Separating the wheat from the chaff Unless the log is very short, auditing it can be laborious System overheads and costs

Log Security If you use logs to detect intruders, smart intruders will try to attack logs Concealing their traces by erasing or modifying the log entries Append-only access control helps a lot here Or logging to hard copy Or logging to a remote machine

Local Logging vs. Remote Logging Should you log just on the machine where the event occurs? Or log it just at a central site? Or both?

Local Logging Only gives you the local picture More likely to be compromised by attacker Must share resources with everything else machine does Inherently distributed Which has its good points and bad points

Remote Logging On centralized machine or through some hierarchical arrangement Can give combined view of what’s happening in entire installation Machine storing logs can be specialized for that purpose But what if it’s down or unreachable? A goldmine for an attacker, if he can break in

Desirable Characteristics of a Logging Machine Devoted to that purpose Don’t run anything else on it Highly secure Control logins Limit all other forms of access Reasonably well provisioned Especially with disk

Network Logging Log information as it crosses your network Analyze log for various purposes Security and otherwise Can be used to detect various problems Or diagnose them later

Logging and Privacy Anything that gets logged must be considered for privacy Am I logging private information? If so, is the log an alternate way to access it? If so, is the log copy as well protected as the real copy?

An Example Network logs usually don’t keep payload Only some header information You can tell who talked to whom And what protocol they used And how long and much they talked But not what they said

Auditing Security mechanisms are great ` Security mechanisms are great If you have proper policies to use them Security policies are great If you follow them For practical systems, proper policies and consistent use are a major security problem

Auditing A formal (or semi-formal) process of verifying system security “You may not do what I expect, but you will do what I inspect.” A requirement if you really want your systems to run securely

Auditing Requirements Knowledge Of the installation and general security issues Independence Trustworthiness Ideally, big organizations should have their own auditors

When Should You Audit? Periodically Shortly after making major system changes Especially those with security implications When problems arise Internally or externally

Auditing and Logs Logs are a major audit tool Some examination can be done automatically But part of the purpose is to detect things that automatic methods miss So some logs should be audited by hand

A Typical Set of Audit Criteria For a Unix system Some sample criteria: All accounts have passwords Limited use of setuid root Display last login date on login Limited write access to system files No “.” in PATH variables

What Does an Audit Cover? Conformance to policy Review of control structures Examination of audit trail (logs) User awareness of security Physical controls Software licensing and intellectual property issues

Does Auditing Really Occur? To some extent, yes 2008 CSI/FBI report says more than 64% of responding organizations did audits Doesn’t say much about the quality of the audits It’s easy to do a bad audit