Internal Roles • Internal features: privileged mode, memory protection, file access permissions, etc. • What do they accomplish? • What is the real goal?
Whom do we protect • Internal features protect the operating system against users • This necessary but not sufficient • File permissions protect users (and the OS) against other users • Again, this is necessary but not sufficient
User Authentication • File permissions are based on user identity, which is based on authentication • How does an OS authenticate users? • Many methods: something you know, something you have, something you are
Attacks • Trojan horses — “come and get it” attack • Trick someone into executing a program that does nasty things (Many viruses and worms spread that way) • How can the OS protect users? • Unix- type file permissions don’t help — the attack program can change permissions • Need mandatory access control (MAC) • Login spoofing • Buggy software — the big one
Sandboxes • OS to provide sandboxes — an environment where the program can execute but can’t affect the rest of the machine • Strong isolation is conceptually pretty easy — run the program on a separate machine, or under VMware or the like • There are other, more elegant mechanisms that attempt to provide the same feature at lower cost; most are limited to root • The trick — and it’s a very difficult one — is permitting limited interaction with the outside world while still protecting security
Race Conditions • Consider a privileged program that checks if a file is readable and then tries to open it as root • The attacker can pass it a symlink; in the interval between the two operations, the attacker removes the symlink and replaces it with a link to a protected file • The OS must provide (and the application must use) atomic operations to open the file as that user
Fake LOGIN login: • Is that the real login prompt? • A fake one could capture your login and password • Many similar FAKES – CC readers, ATMs …
Trusted Path • A trusted path is a user-initiated sequence that is guaranteed to get you to the real OS • Example: cntl+alt+delete on Windows • Well, it was supposed to be one. . . But — you have to train people not to log in unless they’ve initiated the sequence • Must protect all password prompts that way
Certified Systems • In the early 1980s, the U.S. Defense Department created the so-called Orange Book (DoD Trusted Computer System Evaluation Criteria) and its companions • The Orange Book described a set of secure system levels, from D (no security) to A1 (formally verified) • Higher levels had more features; more importantly, they had higher assurance
Hierarchy (1) • D – Minimal Protection: no security is required; the system did not qualify for any of the higher ratings. • C1 – Discretionary Security Protection: the system must identify different users (or jobs) running inside the system, and provide mechanisms for user authentication and authorization to prevent unprivileged user programs from interfere each other (e.g., overwriting critical portions of the memory). • C2 – Controlled Access Protection: the system meets additional security requirements than that of C1 that include access control at a per user granularity (access control for any subset of the user community); clearing of newly allocated disk space and memory; and ability of auditing (logging) for security relevant events such as authentication and object access, etc.
Hierarchy(2) • B1 – Labeled Security Protection: the system must implement the Mandatory Access Control in which every subject and object of the system must maintain a security label, and every access to system resource (objects) by a subject must check for security labels and follow some defined rules. RWFM • B2 – Structured Protection: few new security features are added beyond B1; rather the focus is on the structure (design) of the system to maintain greater levels of assurance so that the system behaves predictably and correctly (such as, a minimal security kernel, trusted path to user, and identified covert channels,etc
Hierarchy (3) • B3 – Security Domains: more requirements to maintain greater assurance that the system will be small enough to be subjected to analysis and tests, and not to have bugs that might allow something to circumvent mandatory access controls, e.g., support of active audit, and secure crashing, etc. • A1 – Verified Design: no additional features in an A1 system over a B3 system; rather there are formal procedures for the analysis of the design of the system and more rigorous controls on its implementation. • Most existing commercial operating systems are with the ratings of C2 or below.
Challenge • Certification + performance + usability
Assignment 2b • 1. Construct RWFM model for BLP, Biba • 2. Construct RWFM for RBAC • 3. Construct RWFM Model for Chinese Wall Model • SUBMISSION of Assignment 2: 10 April 2017
Multi Level Database Security • Views for Multilevel Database Security, DOROTHY E. DENNING, SELIM G. AKL, MARK HECKMAN, TERESA F. LUNT, MATTHEW MORGENSTERN,PETER G. NEUMANN, ROGER R. SCHELL, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 2, FEBRUARY 1987
Notation • Each relation R is defined by a schema R (Al, A2, * . , Ak) that specifies a set of attributes Al, A2, * * *, Ak. • The relation consists of a set of records (also called tuples or rows), where the elements in a record have data values in the domains of the attributes. • The relational algebra consists of operators for selecting whole or partial records having certain values from relations and for joining data in different relations
Example • ITEM(ITEM#, ITEMNAME, WEIGHT) • FLIGHTS(FLIGHT#, DATE, DEST, WEIGHT) • PAYLOAD(FLIGHT#, ITEM#, QTY, WEIGHT) • To deal with multilevel security, we provide the abstraction of multilevel relations, with the assignment of access classes down to the element level
• view PAYLOAD.WEIGHT := ITEM.WEIGHT * PAYLOAD.QTY where ITEM.ITEM# = PAYLOAD.ITEM# Target: PAYLOAD.WEIGHT. • Source: ITEM.ITEM#, ITEM.WEIGHT, PAYLOAD.ITEM#, and PAYLOAD.QTY. • view HEAVIER-THAN(x) :=ITEM.all where ITEM.WEIGHT > x
Classification Constraints • classification constraints on PAYLOAD FLIGHT#, ITEM#, QTY class SECRET WEIGHT class TOP-SECRET • classification constraints on FLIGHTS ALL class TOP-SECRET where FLIGHTS.DEST = 'Iran' class SECRET where else
Class based Entry • classify the records in the FLIGHTS relation at either SECRET or TOP- SECRET depending on their destination • Assuming we do not want to make this classification rule available to SECRET users, the rule must be classified TOP-SECRET. • Doing so, however, means that an additional rule, at the SECRET level, is needed in order that a SECRET user can insert new records into the FLIGHTS relation. Such a constraint might specify that all records are to be classified SECRET: classification constraint on FLIGHTS ALL class SECRET
Duplicate Key?? • Consequently, if a SECRET user inserts a record with DEST = 'Iran', then that record will be classified SECRET. • If the SECRET user attempts to insert a record with a primary key (FLIGHT#) corresponding to an existing TOP-SECRET record, the "'duplicate" record will be inserted into the relation. • This is because the existing record must be completely invisible to the user and all database subjects operating on the user's behalf in order to avoid introducing covert channels. • This does not, however, violate the requirement for "no duplicate keys" because the concept of key can be extended to include its access class.
Derivation Rule Derivation rule on PAYLOAD PAYLOAD.WEIGHT := PAYLOAD.QTY * ITEM.WEIGHT where PAYLOAD.ITEM# = ITEM.ITEM# • The access class for each element of PAYLOAD. LUB{ITEM.weight.class, PAYLOAD.QTY.class,. ITEM,ITEM#.class, PAYLOAD.ITEM#.class}
Santization Rule • The above rule sanitizes the values of sanitization rule on FLIGHTS PAYLOAD.WEIGHT, thereby excluding the attribute PAYLOAD.WEIGHT from the FLIGHTS.WEIGHT := access class specification (all data in this example are classified at the attribute sum(PAYLOAD.WEIGHT)where level). • The access class specification includes all count(PAYLOAD.ITEM#) > 1 0 other attributes in the source (even though the total weight discloses no and FLIGHTS.FLIGHT# = information about flight numbers), and also states that the resulting access class PAYLOAD.FLIGHT# will be at least SECRET. • The clause"count(PAYLOAD.WEIGHT) > ClassLUB{FLIGHTS.FLIGHT#.cla 10" ensures that a minimum number of ss, PAYLOAD.FLIGHT#.class, items is on board each flight so that no single weight can be inferred from the SECRET} sum.
Location sanitization • LOCATION(OBJECT, LONG, • Defining GROSS-LONG to be LAT,GROSS-LONG, GROSS-LAT) CONFIDENTIAL through a sanitization rule: where LONG and LAT give geographical longitude and sanitization rule on LOCATION latitude to 8 significant digits and GROSS-LONG := round(LONG,6) GROSS-LONG and GROSS-LAT give class CONFIDENTIAL only 2 digits of precision. where round (x, d) rounds x by • Suppose that LONG (and LAT) removing d digits of precision. are SECRET.
Recommend
More recommend
