0% found this document useful (0 votes)
11 views

Unix Security Model

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

Unix Security Model

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

Operating system security models General Unix model

• Unix security model • Everything is a file under a virtual root diretory

• Windows security model – Files


– Directories
– Sockets
– Devices
– ...

• Objects are identified by name


– Several concurrent names are possible for any object
(because of links)

• Discretionary access control (DAC): each object has a owner


who decides the access rights for the object

M EELIS R OOS 1 M EELIS R OOS 2

S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

Unix security model Root user

• Access control subjects are users (objects belong to users, users • Has UID 0
delegate access to their objects to other subjects)
• Can bypass access controls
• Users run processes to do things. Processes belong to users
• Has other rights in the system (capabilities) — can configure
• Processes run by user have the same privileges as the user does devices, network stack, mount filesystems etc

• Internally, users are identified by numeric user ID (UID) • Can change the ownership of current process (login!)

• There are no other ways for accessing objects • Can change file ownership
– Hardware protection • Can arbitrarily change file groups
– Protected operating system with well-defined interface to
• Can create and remove users and groups
user programs
• Can install and modify any software

• Target for attackers — gain root privileges from normal user


account by some security vulnerability

M EELIS R OOS 3 M EELIS R OOS 4


S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

Setuid and setgid programs Permissions

• Normal users need a gateway to privileged operations (e.g. • Fixed structure ACL — there are always entries for owner, one
change your password in system password database) group of users and the rest of users

• Normally processes run with the rights of executing user, • For each subject in ACL 3 permission bits are present:
independent on whoever owns the file r — read 4
• Setuid programs run with the effective uid of the owner of the w — write 2
file (often root) x — execute 1
• Setgid programs run with effective group being set to program • r w x r - x - - - = 0750 (octal representation!!!)
file’s group (whether ot not the user belongs to the group)
• ACL only protects one object — no influence to objects in
• "Gateways to other user accounts" — security critical subdirectories, each of them has their own permission bits
components
– Minimize the amount of setuid programs
– We still need some of them

M EELIS R OOS 5 M EELIS R OOS 6

S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

More permission bits Meaning of permission bits

00001 world execute • File read, write


00002 world write • File execute — marks runnable files from data files
00004 world read
• Executable file sticky bit — used to mean no swapping, unused
00010 group execute
• Executable file setuid and setgid — change owner of process
00020 group read
during run
00040 group write
• Directory execute — access a file or directory by name
00100 owner execute
00200 owner read • Directory read — list entries (not needed for lookup by name)
00400 owner write • Directory write — any namespace operation (create, rename,
01000 "sticky" bit remove!!)
02000 setgid • Directory sticky — restricts object removal to object owner
04000 setuid
• Directory setgid — determine the group of newly created objects

M EELIS R OOS 7 M EELIS R OOS 8


S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

umask Process credentials

• umask — bitmap of permissions that newly created files must • Each process has UID, GID ("real UID, real GID")
not have
• EUID, EGID — effective UID and GID
• Example: – Usually the same as UID and GID
– Process does open("file.txt", O_RDWR, 0666) – Setuid/setgid programs affect these ID-s
– If umask=000, file would have permissions rw-rw-rw-
• Saved UID, saved GID — for swithing between 2 ID-s ("drop and
– If umask=027, file would have permissions rw-r----- regain root privileges in setuid root program")

• At user logon, root-owned process sets group list and all the
UID and GID info for the process (changing EUID last)

• All threads of the process share the same ownership info

• Credentials are inherited to subprocesses

• Other resources are also inherited to subprocesses (file


descriptors, environment variables, umask, rlimits, priority etc)

M EELIS R OOS 9 M EELIS R OOS 10

S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

Unix and ACL-s POSIX ACL-s

• Try to express the following with Unix permission bits: • Halfway standardized ACL model for Unix system (POSIX
– Owner has rw dropped the standard)

– Group A has also rw • Mostly compatible between Unixes (setfacl, getfacl)


– Group B has r • Example:
– Others have no permissions setfacl -m user:mroos:rw-,mask:rw- file.txt

• Or, a more common example for users’ public_html directories • ACL mask for all ACL entries
– Owner has rwx • Default ACL-s for directories (copied into ACL-s of newly created
– Web server user has --x objects)
– No other users or groups have any permissions • Only positive permissions, no denying ACL entries
• So we need more flexible ACL-s (Access Control Lists) • NFS version 4 network file system makes use of
Windows-compatible ACL-s with negative ACL entries too and
this is also used in some file systems

M EELIS R OOS 11 M EELIS R OOS 12


S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

Windows security model Windows objects

• Subjects (users, groups, computers) are identified by SID • Each named object and some unnamed objects have security
(Security ID) descriptor — owner, group, ACL-s
– S-1-5-21-2025429065-492874223-1748137768-500
• Lots of different object types, including
• SAM (Security Account Manager) — keeps database of users – Files, directories
and performs authentication
– Processes, threads
• On login, user’s SID and SID-s of all his groups are added to his
– Windows
process
– Login sessions
• Process security token contains user and group SID-s, SID of
– Named pipes, semaphores, other IPC
the logon session, list of system-wide privileges granted to user
– Registry keys
• These security tokens are inherited to subprocesses
• Threads can have different security token (to impersonate
remote users for some local services)
• System privileges

M EELIS R OOS 13 M EELIS R OOS 14

S ECURE P ROGRAMMING T ECHNIQUES S ECURE P ROGRAMMING T ECHNIQUES

Windows ACL-s Windows Vista: integrity levels

• Two types of ACL-s: containers and objects • First steps in MAC (Mandatory Access Controls) — additional
restrictions to the standard discretionary ACL
• Objects in containers inherit their ACL from container
• Processes have trustworhiness level, objects have integrity level
• ACL is set by the user and delegates access
• Objects: files, registry keys, windows (for sending window
• System ACL is set by system administrator and regulates
messages for interaction)
auditing
• Can isolate different processes of the same user one from
• Missing ACL means full access
another
• Present but empty ACL means no access – Internet Explorer protected mode
• ACLs can have negative entries ("no access") • Stored in system ACL
• Inheritance flags — "no ACL here, look at the parent"

• Directory bypass possible

M EELIS R OOS 15 M EELIS R OOS 16

You might also like