Transcript Document

Access Control
How does your code manage who
has access to what?
 authorization
 permission
 privilege
Two OS models:
Unix
Windows
Access Control in Unix/Linux
Every user …
 has a unique UID (positive integer)
 belongs to one or more groups
 can ____ resources (files)
User 0 -- ______
Every file/resource …
 stores permissions for owner, group & world
 potential permissions are _______
 other possibilities:
sticky bit, setUID, setGID
The sticky bit
One bit of file/dir permission is dedicated as the sticky bit.
 Such bits are no longer used for files
 Some directories have the “sticky bit” property
Any user can write to such a directory.
If you create new files, you are the owner and
have wr permission and the world has r permission.
Example:
Processes in
Unixprocess execution.
Executing a file initiates
 process permissions normally derive from the owner
 any created file has permissions determined by umask
A forked process/thread inherits permissions.
To ______ permissions …
execute a process from an owner with lesser privilege
To ________ permissions …
setUID, setGID
If the setUID bit is set on an executable file, then when
the file executes it assumes the permissions of the
file’s owner for the duration of this file’s execution.
EUID  executing file’s owner
The rule is not to elevate privilege any more than necessary.
Access Control in Windows
When a user is authenticated, Windows produces
an access token containing:
 the user’s _____
 a list of group SIDs – one _____ per group
A copy of the access token is attached to every process
and thread the user executes.
A special kind of token (impersonation token) can be granted
to services when they are authorized.
Windows Resources
Many objects are thought of as resources:
 files / directories
 registry keys
 shared memory
 job objects (processes)
 mutexes, named pipes, semaphores
 printers
 active directory objects
Permissions vary by resource type.
ACLs
Discretionary Access Control List (DACL)
– every resource has one
- DACL is a list of Access Control Entry (ACE)
Access Control Entry (ACE) contains
1)
2)
3)
An object can have both explicit and inherited ACEs.
Algorithm for authorizing:
follow the DACL for the first ACE to ALLOW or DENY
matching one of the SIDs in the access token
ACEs are ordered by explicit collection before inherited and
following inheritance tree.
Within each collection all DENY precede all ALLOW
Example
SID4
xFile
X-ALLOW
inherits from
xParent
SID2
SID4
SID3
R-ALLOW
W-ALLOW
W-DENY
SID2
SID2
SID5
SID5
SID3
X-DENY
R-DENY
R-DENY
X-DENY
W-ALLOW
inherits from
xGParent
Authorization requests:
Write to xFile access token: SID3 & SID4
Write to xFile access token: SID2 & SID4
Read from xFile access token: SID2 & SID5
Execute from xFile access token: SID2, SID3, SID4 & SID5
File Permissions in Windows
Full control – read, write, modify, execute,
change attributes/permissions
and/or take ownership
Modify– read, write, modify, execute and/or
change attributes
Read & execute – display file content, view
attributes/owner/permissions and/or
execute
Read – display file content and/or view
attributes/owner/permissions
Write – write file content, append to file and/or
read/change file attributes
Windows advantages:
- finer user granularity (Administrator & operator groups)
- ACE’s can specify many groups, not just one
- allows for variation in permissions by object type
Windows disadvantage:
- complexity
Other Access Control Systems
Programming languages may or may not provide full access
Web access control?
 network security – see CS455
 cookies