January 24, 2005

Implementing Access Controls

Access control (a brief refresher):

§ Objects – the items requested

§ Subjects – the entities that request access to the object through the reference monitor

§ Reference Monitor – the system that determines whether a subject may have access to an object

Multics

• Popular system from the 1960s (1964-1967). Goal of sharing time introduced many new security concerns, and lead to the development of new techniques such as virtual, segmented memory, written in a high level language, shared memory multiprocessors and relational database
• Influenced the design of many modern systems:

Multics à Unix à Linux/Windows

• Timesharing – A new concept, which was to allow multiple people to share the cycles of a single machine

Security model:

• Security is divided into rings.
• Inner ring (0) is kernel. Processes in outer rings have fewer privileges.
• Process at a ring has all privileges associated with rings outside it, but not rings inside it
• Access to inner rings controlled by programmable gatekeeper acting as reference monitor, which implements security policy, a custom piece of code executed at each stage
• Owner specifies policy about which ring process must be in to access data, owner needs to specify a lot of data. UNIX learns to "Keep it Simple" from this complicated policy
• Interprocess communication accomplished by means of “channels”, which are sort of like gatekeepers, only for communication

Access control model:

§ Uses the ring structured security model

§ Specifies a domain in which a process can execute

§ Each piece of data has an access control item, represented as such: <b1,b2,b3>

o The rings b1-b2 can read/write, the rings b2-b3 must use a gatekeeper to gain restricted access to the data

Amoeba

• Distributed system, abstraction: treats network as 1 machine
• Each object resides on a server, can be requested through the use of a capability
• Capability: A message that indicates an object and the rights to that object
• Message looks like: [Server Port][Object #][rights][check]
• Server Port / obj # uniquely specify object, right specify which rights process has
• Check is cryptographic hash of the rights and a server salt (special private data) that is used to verify the rights
• The owner capability has all rights bits set to 1, and a 48-bit random number
• Derived capabilities: Can be handed out, with some rights bits set to 1, then XORed with the random number, and hashed into the check to prevent tampering, thus allowing a process to send its children less access but still some access. Benefit of allowing for right granting without having to call the server every time.

UNIX

• Access control lists: octal values setting R/W/X permissions for owner, group, other
• Order for checking permissions:

If (user==owner) then use owner

            Else if (user==group) then use group

            Else use other

• Sometime we want process to inherit parent's privileges, but sometimes we want it to have more (example mail)
• So we have 3 UIDs: Real (parent's ID), Effective (from setid bit or sys call), and Saved.
• EUID is the one which determines access level
• We set these with setuid, seteuid, setruid, etc
• Setuid is allowed to set EUID to RUID or SUID (unless EUID == root, then can be anything
• Finger daemon exploit took advantage of RUID being 0, and therefore allowed a buffer overflow to escalate privileges by calling setuid
• Similar system for groups
• Be careful with setuid programming, as it can open vulnerabilities (as with the finger daemon)
• Reset RUID to something other than 0 when done being root. If you have to put root into SUID, makes more work for exploiter
• Sticky bit:
• When off: if user has write on the directory, then they can rename or remove a file even if they are not the owner of that file
• When on: even if user has write on the directory, they cannot rename or remove a file unless they are the owner of that file

GOOD UNIX FEATURES: decent protection, pretty flexible

BAD UNIX FEATURES: no mode between normal/super user (i.e. fine grain control isn’t possible), tempting to run as root, limited number of groups

Windows

• Much richer, more expressive policies available
• Can set read, modify, delete, change owner
• More flexible: can create new kinds of permissions, can create users between normal and administrator
• SID replaces UID, stores identity, 48-bit authority value, revision number, RIDs
• Each user, computer, domain etc gets a unique SID
• Inheritance policy:
• WinNT (static): subfolders inherit permissions from parent, can change independently, must explicitly propagate permissions down to subfolders
• Win2000 (dynamic): Initially inherits parent, but stays linked, changes to parent propagate to children unless explicitly overridden
• In case of conflicts: Take union of all positive privileges, subtract out negative ones (so negative takes priority)
• Tokens: Security context in each threat has tokens to establish identity. Can use impersonation tokens to achieve various levels of privilege delegations (see slides for details).
• Security Descriptor: has header, SID of owner, SID of group and optional lists:
• Discretionary ACL (used to store extra users and groups who do/don’t have access),
• System ACL (used to store access for system such as devices)