Internal Roles Internal features: privileged mode, memory - - PowerPoint PPT Presentation

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
• perations, 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
• pen 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
• f 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

• rder 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

sanitization rule on FLIGHTS FLIGHTS.WEIGHT := sum(PAYLOAD.WEIGHT)where count(PAYLOAD.ITEM#) > 1 0 and FLIGHTS.FLIGHT# = PAYLOAD.FLIGHT# ClassLUB{FLIGHTS.FLIGHT#.cla ss, PAYLOAD.FLIGHT#.class, SECRET}

• The above rule sanitizes the values of

PAYLOAD.WEIGHT, thereby excluding the attribute PAYLOAD.WEIGHT from the access class specification (all data in this example are classified at the attribute level).

• The access class specification includes all
• ther attributes in the source (even

though the total weight discloses no information about flight numbers), and also states that the resulting access class will be at least SECRET.

• The clause"count(PAYLOAD.WEIGHT) >

10" ensures that a minimum number of items is on board each flight so that no single weight can be inferred from the sum.

Location sanitization

• LOCATION(OBJECT, LONG,

LAT,GROSS-LONG, GROSS-LAT) where LONG and LAT give geographical longitude and latitude to 8 significant digits and GROSS-LONG and GROSS-LAT give

• nly 2 digits of precision.
• Suppose that LONG (and LAT)

are SECRET.

• Defining GROSS-LONG to be

CONFIDENTIAL through a sanitization rule: sanitization rule on LOCATION GROSS-LONG := round(LONG,6) class CONFIDENTIAL where round (x, d) rounds x by removing d digits of precision.

Another Example

• Suppose that A and B are large SECRET numbers and that C is the

ciphertext encryption of plaintext A under SECRET key B, where encryption is multiplication modulo a prime. Then C could be released as UNCLASSIFIED through a sanitization rule.

Consistency and Completeness

• The set CC of all classification constraints must be complete and
• consistent. A set of classification constraints is said to be complete if

an access class is defined for each element;

• it is consistent if no two constraints, both of which must be satisfied

simultaneously, define conflicting classes.