Three Basic Concepts Hardware Support For Protection: - Instructions, Which Hand Execution Over To Other
Uploaded by
Forest EuropeThree Basic Concepts Hardware Support For Protection: - Instructions, Which Hand Execution Over To Other
Uploaded by
Forest EuropeThree basic concepts
Reference monitor - mediates all access between subjects and objects Security kernel - the parts which together implement a reference monitor in a computer Trusted computing base, TCB, - the total of hardware, software and data, which take care of security
1
Hardware support for protection
Specific memory types (ROM etc.) Modes of operation (status bits) Controlled invocation (traps, gates) Tags on segments, pages etc. Base and/or bounds registers
Specific memory types
Fixed system parameters can have absolute data integrity by being stored in ROM Fixed system parameters can have normally adequate protection by being stored in EPROM Cryptographic keys, audit logs etc. can be stored in WROM
3
Modes of operation (status bits)
Oldest version (IBM 360 1966) had just two modes: Operating system and user. More recent versions implemented more levels (rings) like Intel 80486 Modes can be combined with further tag bits, which indicate for example address partition, like function codes in Motorola 68000
4
Controlled invocation (traps, gates)
Instructions, which hand execution over to other processes, must have the same status as the target process, in order to pass control directly to the target. Higher status targets are reached through gates, interrupts etc., which check access conditions, change status, perform the task and finally set the status back before returning control
5
Tags on segments, pages etc.
Tags can indicate status, like rings. Tags can also indicate non-hierarchic status, like program or data space. Tags can be used by traps and gates.
6
Base and/or bounds registers
Addresses can be created from base registers, like when the lowest address part is reserved for the operating system. Addresses can be checked against the bounds of the current process.
7
Theoretical computer
User process 1 User process 2 Communication channels Utility process Operating system Keyboard/ Mouse Secondary storage Free memory
8
Display
Real computer
Instruction pointer Machine instruction
Real computer
Instruction pointer Machine instruction
Next instruction
10
Real computer
Instruction pointer + 1 Next instruction
Next instruction Following instruction
Real computer
New instruction pointer Following instruction
Next instruction Following instruction New instruction pointer
11
12
Real computer
New instruction pointer Following instruction
Next instruction Following instruction New instruction pointer
Basic requirements
It is very important that the set of instructions, that is especially protected by the hardware, matches the need for protected kernel primitives . Whatever protection mechanism you use, it is vital that the kernel does not loose track of what code it is running
13 14
Typical problems
Data segments are placed where program code is supposed to be, buffer overflow The reference monitor is bypassed for some types of access Connections are trusted without a proper basis for the trust Security requirements are not captured
15
Buffer overflow
Legitimate programs are in practice rewritten in real time and then executed The privileges of the process are not changed Enables the attacker to run code beyond his/her access permissions Crashes are easy to perform, running serious code is more difficult
16
Bypassing the reference monitor
System functions may be allowed to escape control, as when root is running in UNIX systems Always a dangerous state, that still must be used sometimes Never use it a nanosecond more than is needed!
17
Misplaced trust
Have you any idea what the program you just called is actually doing?
Viruses, Trojans, worms etc. Autoexecution Mobile code, redirections etc.
Is the caller properly authenticated? Has the calling system been subverted?
18
Assurance
Shall ensure that security requirements are properly found, documented and implemented. Used for the development of security critical system parts like the OS kernel, smart card architecture, network protocols etc. Informal versions can be used for whole systems, formal versions are too resource heavy for that scale Common Criteria the currently valid standard
19
Assurance history
TCSEC, USA, 1983
Confidentiality main goal No separation of functionality and assurance
ITSEC, Europe, 1991 (1995)
Developed by UK, France, Germany and Netherlands
CTCPEC, Canada, 1989 Common Criteria developed primarily by those involved in former standards
20
CC concepts
Target Of Evaluation, TOE
Description of Security Policy Description of necessary functions and mechanisms
CC evaluation levels
EAL1: Functionally tested EAL2: Structurally tested EAL3: Methodically tested and checked EAL4: Methodically designed, tested and reviewed EAL5: Semi-formally designed and tested EAL6: Semi-formally verified design and tested EAL7: Formally verified design and test
21 22
Protection Profile, PP
Security requirements for category of product Specifies intended usage, environment and threats
Security target, ST
Specification for actual evaluation product
