WIP: Layered Assurance of Security Policies for an Embedded OS

Transcription

1 WIP: Layered Assurance of Security Policies for an Embedded OS Jia Song and Jim Alves-Foss Center for Secure and Dependable Systems University of Idaho 1

2 Security tagged architecture Security tagged architecture is a hardware architecture which allows metadata to be used during runtime to enforce security policies and to maintain the semantics of the computation. The metadata can be represented as a tag. It is usually associated with a word of memory or registers to carry the information about the word and registers. 2

3 RTEMS RTEMS is a real-time executive which provides a powerful run-time environment to allow various types of services and applications to be deployed on embedded systems. RTEMS is open source real-time OS, supported by rtems.org 3

4 RTEMS Architecture RTEMS has 18 managers, each manager provides a set of well defined services by using directives (APIs). SCORE (Super CORE) provides kernel functions to support the managers. SCORE (Super Core) 4

5 RTEMS Architecture The APIs (Direc<ves) of each manager and SCORE service can be divided into 4 groups: External APIs Init APIs Internal APIs Private internal APIs e.g. Thread (SCORE service) has: - Thread external APIs - Thread Init APIs - Thread Internal APIs - Thread Private internal APIs 5

6 UI security tagging scheme The tag in the UI tagging scheme consists of three fields: written as (Owner, Code-space, Control-bits) The Owner field of tag shows who is the owner of code or data The Code-space field shows which code space should manage the data. The Control-bits field is used for further control. Eg: (USER1, TASK_EXT, <Control-bits>) (USER2, CLOCK_EXT, <Control-bits>) 6

7 Detailed Control-bits field Bit 7: copy bit (1 bit) - indicates whether a return value has been modified. Bits 6 4: Memory type (3 bits) these 3 bits specify the memory type (data memory, stack memory and code memory), indicate the entry point of a function, and read/write memory protection. Bit 3: World-readable bit (1 bit) - if set, indicates the tagged data can be read by all entities. Bits 2 0: 3 bits are reserved for future use. 7

8 Rules for load instructions For example, ld [%fp-16], %o1 For the load instruction, whether the current running thread is allowed to access that memory space ([%fp-16]) is checked. If the copy bit in the tag of [%fp-16] is cp set, and if Owner([%fp-16] ) Owner(PC), the LOAD is allowed. The tag of [%fp-16] is copied to register s tag. If the copy bit in the tag of [%fp-16] is cp not set, and if [%fp-16] PC, the LOAD is allowed. The tag of [%fp-16] is copied to register s tag. 8

9 Hardware level vs. software level tagging Hardware level tagging can be used to: Check for memory type mismatches Compare security levels of tags Control information flow Software level tagging is needed to: Initialize the tagging scheme Help deal with special/complex tag checking and propagation 9

10 Verification of the tagging policies Verification of the tagging policies and implementation at the hardware level indicates proper tag propagation and correct behaviors of the STA. Verification includes proof that implementation satisfies specified security lattice. Proofs are parameterized by system configurations that specify security labels of all system code and variables. Assume that the configurations are well-formed. 10

11 Verification of the tagging policies For the complex tagging rules at the software level, verification issues and policy concerns can be classified into sets that satisfy specific characteristics. Is module acting as an agent for user? Is it an agent that transfers information between users? Is it an agent for the system to manage users? Proofs can be combined with verification of valid system configurations to prove system supports policies such as separation and controlled information flow. Must prove superuser sets configuration correctly. For example: User 1 can send a message to user 3 only through a guard process (user 4) 11

12 Concerns Compiler optimizations will change and/or remove security relevant code. Inline functions, global variables, library functions need to be carefully tagged. Mapping of limited tag bits to application specific security labels may be difficult. Use of merged security and integrity policies in kernel may not map well to higher levels. System developer has to now understand more complex security policies. 12

13 Thank you! Questions? 13