Topic:
distributed system security
Topic:
operating system security
Topic:
security by access rights
Topic:
security leaks and weaknesses
Topic:
security of remotely executed code
| |
Summary
Secure domains, mandatory access control, security partition, and multilevel security enforce security by partitioning a system and its data into multiple levels. For example, the U.S. national security hierarchy is top-secret, secret, confidential, and unclassified. Access is permitted for someone with the same or high security level. When computerized, this policy may be implemented by flow relations.
The same technique is useful for all systems. The most sensitive information receives the highest security level along with the attendent costs and inconveniences. Security may be physical locks, cryptographic keys and capabilities, and access controls. A small security kernel allows proof of security. Reinitialization enforces security across time.
If a system is separated into secure domains, the system may share an address space or file system. For example, the sandbox model ensures that remotely executed code can not modify sensitive locations. This requires strong type checking in order to develop provable properties about a program. (cbb 4/98)
Subtopic: multilevel security 
| Quote: security by least privilege; give only those privileges needed to accomplish the task [»schnB_2000]
| | Quote: government and military systems must prevent direct and indirect data transfer from files at high security to files and users at low security [»dennDE5_1976]
| | Quote: multilevel security: each individual is assigned a clearance and each item of information has a classification; widely used [»rushJ7_1983]
| | Quote: mandatory access control limits damage a Trojan horse can do; e.g., military security levels (clearance for classified objects) [»mcleJ1_1990]
| | Quote: a flow relation is a partial order on security classes; e.g., military security from highest to lowest [»dennPJ_1980]
| | Quote: multilevel security verifier for verifying that information flows do not violate the security model [»silvBA_1981]
| | Quote: conventional computer systems do not enforce multilevel security; subverted by trap doors and trojan horses [»rushJ7_1983]
| | Quote: simple security--users and programs not permitted to view data with a higher classification [»mcleJ1_1990]
| | Quote: *-property for security--programs not permitted to copy data to a lower classification level
| | Quote: implemented the secure Newcastle_Connection as a Unix layer above the kernel [»rushJ7_1983]
| | Quote: IX is a multilevel-secure UNIX; security labels on all files and processes, private channels, mandatory access control, no super-user [»mcilMD8_1992]
| | Quote: IX protects information from automated theft by unauthorized users and from accidental disclosure; allows some out-of-band leaks
| | Quote: an unprivileged process can only cause upward data flow that remains below all pertinent ceilings; enforce by rules on security labels [»mcilMD8_1992]
| | Quote: security labels in IX give lattice value (bit vector), privilege, fixity, and yes/no; occupy appreciable space, and take time to compare [»mcilMD8_1992]
| | Quote: secure file manager adds a checksum to prevent top secret information from leaking from the file store [»rushJ7_1983]
|
Subtopic: trusted host
| Quote: an Andrew cell is an autonomous system with its own security, file servers, and administration; user must be authenticated for each cell [»satyM8_1989]
| | Quote: key management was tricky; used a secure processor in a credit control hierarchy; refilling the processor's credit counter required a higher level transaction [»andeRJ5_1996]
|
Subtopic: security partition
| Quote: compartmentalize security; limit damage from a successful attack; e.g., door keys, user accounts, encrypted files [»schnB_2000]
| | Quote: after factotum is marked 'private', no secret must escape; process memory is inaccessible and never swapped to disk [»coxR8_2002]
| | Quote: temporally separate activities in different security partitions by reinitializing an untrusted host [»rushJ7_1983]
| | Quote: cryptographic separation for different uses of shared communication and storage media [»rushJ7_1983]
| | Quote: separation kernels are smaller, less complicated, faster, and more easily verified then security kernels [»rushJ7_1983]
| | Quote: security partition: a set of compartments accessible by an individual, and a clearance or classification [»rushJ7_1983]
| | Quote: a file storage machine can be used for multiple security partitions since leaks are prevented by the secure file manager [»rushJ7_1983]
|
Subtopic: lattice model
| Quote: lattice model of secure information flow; ignores covert channels; need access control and flow control [»dennDE5_1976]
|
Subtopic: privileged group
| Quote: secure transactions via enrollment in a privileged group (safe dealing); resources relative to requesting organization [»gladHM5_2001]
|
Subtopic: access to untrusted components
| Quote: reference monitor for trustworthy access to untrusted components and data; checks each access against policy and record so far [»rushJ7_1983]
| | Quote: security processors contain a separation kernel to logically separate reference monitors and untrusted support functions [»rushJ7_1983]
| | Quote: partition secure file system into trusted and untrusted machines; the secure file manager enforces secure access to the untrusted file storage [»rushJ7_1983]
| | Quote: physically separate untrusted computing resources and the security processors [»rushJ7_1983]
|
Subtopic: access by untrusted components
| Quote: use a trustworthy intermediary for secure information flow; e.g., a low-level host places a file in a secure store for reading by a high-level host [»rushJ7_1983]
|
Subtopic: protection domain
| Quote: an Andrew protection domain is a user or a group of users with an owner; owner prefixed to group name [»satyM8_1989]
|
Subtopic: sandbox partition
| Quote: sandbox untrusted programs in a completely separate world with separate folders, history, Web cache, etc.
| | Quote: only communication with untrusted domains by explicit copy or network file share
| | Quote: guarantee sandbox security by well-typed applets and verified parameter references [»leroX1_1998]
| | Quote: devise a secure language by constructing secure input/output facilities for a conventional language [»boreNS11_1992]
| | Quote: specify a security policy in terms of sensitive store locations; i.e., locations or files which an applet must not modify [»leroX1_1998]
| | Quote: strong typing protects the sandbox model by preventing arbitrary access to the computer running the execution environment [»leroX1_1998]
| | Quote: use big-step operational semantics to monitor reachable locations under the security policy [»leroX1_1998]
|
Subtopic: address space security
| Quote: for remote processing, the kernel must encapsulate a program in an address space; prevents damage to other programs [»cherDR3_1988]
| | Quote: safe programs can share the same address space; no accidental side effects from other programs
|
Subtopic: fine-grained security using types
| Quote: use named types for fine-grained types implemented by a program type; e.g., different kinds of strings
| | Quote: simple types are too coarse for a security policy; e.g., a string can be a message, a file name, or a cryptographic key [»leroX1_1998]
| | Quote: enforce type system with run-time validation checks on each argument; e.g., all file names belong to the /tmp directory
|
Subtopic: limitations of mandatory access control
Quote: multilevel security and mandatory access control concentrate on confidentiality; it assumes that classifications are fixed and well known; it may deny legitimate access
[»schnB_2000]
|
Related Topics
Topic: distributed system security (17 items)
Topic: operating system security (18 items)
Topic: security by access rights (38 items)
Topic: security leaks and weaknesses (67 items)
Topic: security of remotely executed code
(24 items)
|
