Secure Operating Systems

1. CS 155 May 3, 2005 Secure Operating Systems John Mitchell

2. Access Control Concepts Matrix, ACL, Capabilities Multi-level security (MLS) OS Mechanisms Multics Ring structure Amoeba Distributed, capabilities Unix File system, Setuid Windows File system, Tokens, EFS SE Linux Role-based, Domain type enforcement Secure OS Stronger mechanisms Some limitations Assurance Orange Book, TCSEC Common Criteria Windows 2000 certification Cryptographic File Systems Embedded OS Some issues in Symbian security Software Patches Last Lecture This lecture

3. What makes a “secure” OS? • Extra security features (compared to last lecture) • Stronger authentication mechanisms • Example: require token + password • More security policy options • Example: only let users read file f for purpose p • Logging and other features • More secure implementation • Apply secure design and coding principles • Assurance and certification • Code audit or formal verification • Maintenance procedures • Apply patches, etc.

4. Sample Features of “Trusted OS” • Mandatory access control • MAC not under user control, precedence over DAC • Object reuse protection • Write over old data when file space is allocated • Complete mediation • Prevent any access that circumvents monitor • Audit • Log security-related events and check logs • Intrusion detection • Anomaly detection • Learn normal activity, Report abnormal actions • Attack detection • Recognize patterns associated with known attacks

5. DAC and MAC • Discretionary Access Control • Restrict a subject's access to an object • Generally: limit a user's access to a file • Owner of file controls other users' accesses • Mandatory Access Control • Needed when security policy dictates that: • protection decisions must not be left to object owner • system enforces a security policy over the wishes or intentions of the object owner Jack, Kack, Lack, Mack, Nack, Ouack, Pack and Quack

6. DAC Object owner has full power Complete trust in users Decisions are based only on user id and object ownerships Impossible to control information flow MAC Object owner CAN have some power Only trust in administrators Objects and tasks themselves can have ids Makes information flow control possible DAC vs MAC

7. Information flow High High Process inputs outputs Low Low inputs outputs

8. Controlling information flow • MAC policy • Information from one object may only flow to an object at the same or at a higher security level • Conservative approach • Information flow takes place when an object changes its state or when a new object is created • Implementation as access policy • If a process reads a file at one security level, it cannot create or write a file at a lower level • This is not a DAC policy, not an ACL policy

9. SELinux • Security-enhanced Linux system (NSA) • Enforce separation of information based on confidentiality and integrity requirements • Mandatory access control incorporated into the major subsystems of the kernel • Limit tampering and bypassing of application security mechanisms • Confine damage caused by malicious applications • Why Linux? Open source • Already subject to public review • NSA can review source, modify and extend • Assurance methods later in lecture … http://www.nsa.gov/selinux/

10. Problem: crypto module Signing Signing algorithm key Input Output Actual hope: low security output does not reveal high security input

11. Information flow analysis • First guess • Mark expressions as high or low • Some resemblance to Perl tainting • Check assignment for high value in low location • But consider if (xhigh > 0) ylow = 0; else ylow = 1; • State of the art • Much research on type systems and program analysis to determine software information flow • Still not ready for prime time

12. Covert Channels • Butler Lampson • Difficulty achieving confinement (paper on web) • Communicate by using CPU, locking/unlocking file, sending/delaying msg, … • Gustavus Simmons • Cryptographic techniques make it impossible to detect presence of a covert channel

13. Example • The Two-Server Trojan Horse: • Device P can chose from two Key Servers • P is expected to choose randomly, to balance load • But reveals key one bit at a time • Observations • Information flow easily detected by noninterference analysis of the algorithm • More subtle if choice based on random seed known to external attacker [McLean] S1 P key S2 Also: DNS lookup, SSL nonce, …

14. Sample Features of Trusted OS • Mandatory access control • MAC not under user control, precedence over DAC • Object reuse protection • Write over old data when file space is allocated • Complete mediation • Prevent any access that circumvents monitor • Audit • Log security-related events and check logs • Intrusion detection • Anomaly detection • Learn normal activity, Report abnormal actions • Attack detection • Recognize patterns associated with known attacks

15. Interesting risk: data lifetime • Recent work • Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation by Jim Chow, Ben Pfaff, Tal Garfinkel, Mendel Rosenblum • Example • User types password into web form • Web server reads password • Where does this go in memory? • Many copies, on stack and heap • Optimizing compilers may remove “dead” assignment/memcopy • Presents interesting security risk

16. Sample Features of Trusted OS • Mandatory access control • MAC not under user control, precedence over DAC • Object reuse protection • Write over old data when file space is allocated • Complete mediation • Prevent any access that circumvents monitor • Audit • Log security-related events and check logs • Intrusion detection (cover in another lecture) • Anomaly detection • Learn normal activity, Report abnormal actions • Attack detection • Recognize patterns associated with known attacks

17. Kernelized Design • Trusted Computing Base • Hardware and software for enforcing security rules • Reference monitor • Part of TCB • All system calls go through reference monitor for security checking • Most OS not designed this way User space User process Kernel space OS kernel TCB Reference monitor

18. Audit • Log security-related events • Protect audit log • Write to write-once non-volatile medium • Audit logs can become huge • Manage size by following policy • Storage becomes more feasible • Analysis more feasible since entries more meaningful • Example policies • Audit only first, last access by process to a file • Do not record routine, expected events • E.g., starting one process always loads …

19. Assurance methods • Testing • Can demonstrate existence of flaw, not absence • Formal verification • Time-consuming, painstaking process • “Validation” • Requirements checking • Design and code reviews • Sit around table, drink lots of coffee, … • Module and system testing

20. Rainbow Series DoD Trusted Computer Sys Evaluation Criteria (Orange Book) Audit in Trusted Systems (Tan Book) Configuration Management in Trusted Systems (Amber Book) Trusted Distribution in Trusted Systems (Dark Lavender Book) Security Modeling in Trusted Systems (Aqua Book) Formal Verification Systems (Purple Book) Covert Channel Analysis of Trusted Systems (Light Pink Book) … many more http://www.radium.ncsc.mil/tpep/library/rainbow/index.html

21. Orange Book Criteria (TCSEC) • Level D • No security requirements • Level C For environments with cooperating users • C1 – protected mode OS, authenticated login, DAC, security testing and documentation (Unix) • C2 – DAC to level of individual user, object initialization, auditing (Windows NT 4.0) • Level B, A • All users and objects must be assigned a security label (classified, unclassified, etc.) • System must enforce Bell-LaPadula model

22. Levels B, A (continued) • Level B • B1 – classification and Bell-LaPadula • B2 – system designed in top-down modular way, must be possible to verify, covert channels must be analyzed • B3 – ACLs with users and groups, formal TCB must be presented, adequate security auditing, secure crash recovery • Level A1 • Formal proof of protection system, formal proof that model is correct, demonstration that impl conforms to model, formal covert channel analysis

23. Common Criteria • Three parts • CC Documents • Protection profiles: requirements for category of systems • Functional requirements • Assurance requirements • CC Evaluation Methodology • National Schemes (local ways of doing evaluation) • Replaces TCSEC, endorsed by 14 countries • CC adopted 1998 • Last TCSEC evaluation completed 2000 http://www.commoncriteria.org/

24. Protection Profiles • Requirements for categories of systems • Subject to review and certified • Example: Controlled Access PP (CAPP_V1.d) • Security functional requirements • Authentication, User Data Protection, Prevent Audit Loss • Security assurance requirements • Security testing, Admin guidance, Life-cycle support, … • Assumes non-hostile and well-managed users • Does not consider malicious system developers

25. Evaluation Assurance Levels 1 – 4 EAL 1: Functionally Tested • Review of functional and interface specifications • Some independent testing EAL 2: Structurally Tested • Analysis of security functions, incl high-level design • Independent testing, review of developer testing EAL 3: Methodically Tested and Checked • Development environment controls; config mgmt EAL 4: Methodically Designed, Tested, Reviewed • Informal spec of security policy, Independent testing

26. Evaluation Assurance Levels 5 – 7 EAL 5: Semiformally Designed and Tested • Formal model, modular design • Vulnerability search, covert channel analysis EAL 6: Semiformally Verified Design and Tested • Structured development process EAL 7: Formally Verified Design and Tested • Formal presentation of functional specification • Product or system design must be simple • Independent confirmation of developer tests

27. Example: Windows 2000, EAL 4+ • Evaluation performed by SAIC • Used “Controlled Access Protection Profile” • Level EAL 4 + Flaw Remediation • “EAL 4 … represents the highest level at which products not built specifically to meet the requirements of EAL 5-7 ought to be evaluated.” (EAL 5-7 requires more stringent design and development procedures …) • Flaw Remediation • Evaluation based on specific configurations • Produced configuration guide that may be useful

29. Is Windows is “Secure”? • Good things • Design goals include security goals • Independent review, configuration guidelines • But … • “Secure” is a complex concept • What properties protected against what attacks? • Typical installation includes more than just OS • Many problems arise from applications, device drivers • Windows driver certification program • Security depends on installation as well as system

30. Secure attention sequence (SAS) • CTRL+ALT+DEL • “… can be read only by Windows, ensuring that the information in the ensuing logon dialog box can be read only by Windows. This can prevent rogue programs from gaining access to the computer.” • How does this work? • Winlogon service responds to SAS • DLL called GINA (for Graphical Identification 'n' Authentication) implemented in msgina.dll gathers and marshals information provided by the user and sends it to the Local Security Authority (LSA) for verification • The SAS provides a level of protection against Trojan horse login prompts, but not against driver level attacks.

31. Encrypted File Systems (EFS, CFS) • Store files in encrypted form • Key management: user’s key decrypts file • Useful protection if someone steals disk • Windows – EFS • User marks a file for encryption • Unique file encryption key is created • Key is encrypted, can be stored on smart card • Unix – CFS [Matt Blaze] • Transparent use • Local NFS server running on "loopback" interface • Key protected by passphrase

32. Q: Why use crypto file system? • General security questions • What properties are provided? • Against what form of attack? • Crypto file system • What properties? • Secrecy, integrity, authenticity, … ? • Against what kinds of attack? • Someone steals your laptop? • Someone steals your removable disk? • Someone has network access to shared file system? Depends on how file system configured and used

33. Encrypted file systems • Several possible designs • Block based systems • Disk based systems • Network loopback based systems • Stackable file systems • Application based encryption • Some references • A cryptographic file system for unix • Matt Blaze • Cryptographic File Systems Performance • Charles Wright, Jay Dave and Erez Zadok • Cryptoloop HowTo • Dennis Kaledin et. al • Ncryptfs: A secure and convenient cryptographic file system • Wright et. al

34. Block Based • Encrypt one disk block at a time • Not dependent on underlying file system • Can write to raw device or preallocated file

35. Sample block-based implementation • Cryptoloop • Uses Linux loopback device driver, CryptoAPI • Linux kernel CryptoAPI exports an interface to encryption functions and hash functions • Can write to a raw device or to a preallocated file • Preallocated file effectively cuts buffer cache in half

36. Other block-based file systems • CGD (Cyptographic disk driver) • For NetBSD • raw device only • BestCrypt • Commercial product for Linux and windows • preallocated file for storage • vncrypt • For FreeBSD: uses the vn device driver • preallocated file for storage • vnd • For OpenBSD: uses the Vnode disk driver (vnd) • preallocated file for storage

37. Disk Based • Encrypt data at the file system level

38. Disk Based • EFS (Encryption File System) • Extension to NTFS based on NT kernel. • Uses windows access control and authentication libraries though located in the kernel, its tightly coupled with user space dlls to do encryption and user authentication. • Encryption keys are stored on the disk, encrypted with user password • StegFS • A file system that employs encryption and steganography • Inspection of system will not reveal content or extent of hidden data • uses modified ext2 kernel driver • Very slow and hence impractical

39. Network Based • CFS • User level crypto NFS server • Performance hampered by many context switches and data copies between user and kernel space • Data appears in user space in cleartext

40. Network Based • TCFS • modified kernel mode nfs client • works with normal nfs server • keys are stored on the filesystem

41. Stackable Systems • Ncryptfs • Can operate on top of any file system.

42. Application based encryption • Applications like pgp, SafeHouse allow users to encrypt/decrypt files • File may be in cleartext on the disk while the user is editing and saving it

43. Encrypted file system • Complete file system encryption is feasible in real time • Crypto operations are not a big bottleneck • Performance study: with single processor, I/O is limiting factor • Caching plays a big role in performance of encrypted systems

44. Embedded operating systems • Symbian History • Psion released EPOC32 in 1996 • based on 1989 EPOC OS • EPOC32 was designed with OO in C++ • Symbian Ltd. formed in 1998 • Ericsson, Nokia, Motorola and Psion • EPOC renamed to Symbian OS • Currently ~30 phones with Symbian,15 licensees • Current ownership Nokia 47.5% Panasonic 10.5% Ericsson 15.6% Siemens 8.4% SonyEricsson 13.1% Samsung 4.5% See: Symbian phone security, Job de Haas, BlackHat, Amsterdam 2005

45. Symbian UI • Two main version Series60 UIQ

46. Architecture • Multitasking, preemptive kernel • MMU protection of kernel and process spaces • Strong Client–Server architecture • Plug-in patterns • Filesystem in ROM, Flash, RAM and on SD-card

47. Symbian Development • Emulator on x86 runs most of native code base • Compiled to x86 (so not running ARM cpu) • Emulator is one windows process • Limited support for on-target debugging • It does not work on all devices • Uses a gdb stub • Metrowerks provides MetroTRK • Future: v9 will move to ARM Real View (RVCT) and the EABI standard

48. Toll fraud: Auto dialers. High cost SMS/MMS. Phone Proxy Loss or theft: Data loss. Data compromise. Loss of Identity (caller ID) Availability: SPAM. Destruction of the device (flash) Destruction of data. Risks induced by usage: Mobile banking. Confidential e-mail, documents. Device present at confidential meetings: snooping Attack vectors Executables Bluetooth GPRS / GSM OTA IrDa Browser SMS / MMS SD card WAP E-mail Too many entry points to list all Mobile phone risks

49. Crypto: Algorithms Certificate framework Protocols: HTTPS, WTLS, … Symbian signed: Public key signatures on applications Root CA’s in ROM Separation Kernel vs. user space; process space Secured ‘wallet’ storage Access controls SIM PIN, device security code Bluetooth pairing Artificial Limitations / patches Prevent loading device drivers in the kernel (Nokia). Disallow overriding of ROM based plug-ins Limitations No concept of roles or users. No access controls in the file system. No user confirmation needed for access by applications. User view on device is limited: partial filesystem, selected processes. Majority of interesting applications is unsigned. Are attacks prevented? Fraud: user should not accept unsigned apps Loss/theft: In practice, little protection Availability: any application can render phone unusable (skulls trojan). Symbian security features

50. Symbian attacks • What goes wrong? • All known attacks need user confirmation. Often more than once. • People loose a lot devices • Skulls Trojan: • Theme that replaces all icons and cannot be de-installed • Caribe: • Installs itself as a ‘Recognizer’ to get activated at boot time and starts broadcasting itself over Bluetooth