Access Control: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 169: | Line 169: | ||
Sometimes, also a developer uses the easier way to reach a goal. |
Sometimes, also a developer uses the easier way to reach a goal. |
||
Sometimes it‘s just user friendly. |
Sometimes it‘s just user friendly.. |
Revision as of 00:43, 8 September 2005
Who and what has access to which resource has to be controled on every IT System.
Introduction
Controlled are issues like
- access to files
- access to memory
- execution of programs
- sharing data with other principals
Access is controlled at different levels:
- application
- middleware
- operating system
- hardware
The complexity of administering Access Control is growing complexity.
Hardware Protection
Protection Problem: preventing one process from interfering with another
Confinement Problem: preventing programs communicating outwards through other than authorized channels (e.g. memory overwriting)
Intel 80x86 (Pentium) Processors
8088/8086: | any running program controlled the whole machine |
80286: | protected segment addressing and rings, operating systems could run proper |
80386: | built-in virtual memory and large memory segments, treated as a 32-bit flat-address machine |
Rings
- process in ring 0 (kernel) manages privilege level of other processes
- ring 1, 2 usually system processes (e.g. win32 subsys, virtual DOS)
- ring 3 user programs
- gates between rings for executing code at an other level
Other Procssors
Acorn Risc Machine (ARM)
- most commonly licensed to third-party vendors of embedded systems
- 32-bit processor
- separate banks of registers for user and system processes
- hardware protection can be customized
Security Processors
- hardware security support for cryptography and access control
- authorized state
- password covered memory access
s.o.
Operating Systems
- access control for files and processes, ring management, IO-management, memory, processors s.o. as deep as the hardware permits it
- matrix is often used to manage this
- not usable for large organizations, because the administration becomes to difficult for humans
Do it by groups and/or roles !
Groups and Roles
- every user fits into one or some categories
- rights have to be defined for these categories
- user gets role and fits in group
What is the difference ?
There‘s no final definition.
Access Control Lists
- just one column of the access control matrix stored for every resource
- not very performant
- difficult to administrate
Unix
- simple list: owner, group, world for user – not for programs
- indirect method for programs: SUID and SGID
- or by user dummy
Win NT
- more attributes (take ownership, change permission, delete)
- arrangement in domains with trust between them
Capabilities
- just one row of the access control matrix stored for every resource
- some experimental implementatios in the 70s
- today a comeback in the form of public key certificates
Win 2k/XP
- used combined with ACL
- group policies
- active directory
Understands
Granularity |
|
Sandboxing | access to a restricted environment |
Proof-Carrying-Code | tests the behaviour of a program |
Object Request Brokers | controlling calls for several objects/resources |
Problems
- problem if any level doesn’t controll access
- "Every system has at least one bug – Windows much more."
- "The most serious bug is sitting in front of the monitor."
- smashing the stack
- bypassing denied permissions
- trojans
- structural defects in operating systems (Windows user has to be admin for installation)
Background
Decisions were made one time, consequences work eternally, but environment changes very rapidly.
Sometimes, also a developer uses the easier way to reach a goal.
Sometimes it‘s just user friendly..