Skip to main content
Department of Information Technology

Unix security

Example of general-purpose OS security. Originally not designed for high security, these days reasonably good (cf. Windows)

Major drawback: superuser (root)/user distinction. Too many things require root permission, which comes with all permissions. No intermediate levels, really.

Identification and authentication

  • passwd file and shadowing, user IDs
    username:passwd:uid:gid:gecos:homedir:loginshell
    • disable account easily: set passwd field so it can't match an encrypted password, e.g. prefixing "*"
    • shadowing: passwd is "x"
    • example:
      victor:$md5$vjTSep.U$$U/gFElD.Sxx4/tU.fhM8a.:1020:8031:Bjorn Victor,MIC 1139,4713169,501601:/home/victor:/usr/local/bin/bash
    • /etc/shadow:
    • username:passwd:lastchange:change allowed:change required:expiration warn:inactivation:expiry
      • lastchange: days since 1970-01-01 password was last changed
      • change allowed: days before which password may not be changed.
      • change required: days after which password must be changed.
      • expiration warn: days before password is to expire that user is warned of pending password expiration.
      • inactivation: days after password expires that account is considered inactive and disabled.
      • expiry: days since Jan 1, 1970 when account will be disabled.
  • group file, group IDs: defines group names, adds users to more than one group
    groupname:passwd:gid:user list
    passwd empty or not (ignored except in System V)
    • example:
      tbend:*:8045:victor,karlm,daz,eh,lalle

File protection

  • Permissions: r, w, x, s, t ("sticky bit")
  • File interpretation
  • Directory interpretation
    • r: read contents (filenames only)
    • w: create/write/delete files (requires {x} also)
    • x: "search directory" - access files if they permit, get file info (e.g. permissions, dates), cd
    • sgid: sets group of new files to that of directory
    • t: sticky bit - only owner (and root) may remove files

Note: Gollman's examples use ls -F which prints the trailing "/" and "*" for directories and executable files. These are not part of the name.

Recall order of access checks: user, group, others.

Octal interpretation of permission:

  • rwx,rwx,rwx => 777
  • 4000 = suid bit
  • 2000 = sgid bit
  • 1000 = sticky bit

umask sets default permission mask:

  • Ex: umask 022 masks the write bit for group and others
2.1. suid/sgid programs

"Controlled invocation" - gives a program additional/other rights.

  • processes have effective and real { user, group} IDs
  • suid, sgid programs: controlled invocation

chown root pgm; chmod u+s pgm => rwsr-xr-x

  • changes effective user id to root on execution
    • pgm is trusted - i.e. can harm you
    • used when root access necessary (e.g. ping)
    • suid programs cannot be debugged (traced)
    • traditional errors: shell escapes, not complete argument checking...
      • cf. game high score file access
      • some protection: execve call sets effective := real uid.

chgrp games pgm; chmod g+s pgm => rwxr-sr-x

  • changes effective group id on execution
    • more flexible/granular "privileges", specific to service
    • e.g. daemons (system server processes) for printing, mail, etc.
2.2. ACLs

getfacl, setfacl to get and set file ACL. Extends u/g/o ACL to more users and groups.

Example:
% ls -ld frotz
drw-rwsr-x+ 3 victor docs 512 Sep 5 11:28 frotz
% getfacl frotz

# file: frotz
# owner: victor
# group: docs
user::rw-
user:marcusn:rwx                #effective:rwx
group::rwx              #effective:rwx
mask:rwx
other:r-x

% setfacl -m group:it:r-x frotz
% getfacl frotz

# file: frotz
# owner: victor
# group: docs
user::rw-
user:marcusn:rwx                #effective:rwx
group::rwx              #effective:rwx
group:it:r-x            #effective:r-x
mask:rwx
other:r-x

Sensitive special files (device files)

  • /dev/mem - physical memory
  • /dev/kmem - kernel virtual memory
    • (earlier) used for e.g. reading process info
  • /dev/ttyXX and similar - terminals.
  • /proc, /sys - in Linux, process and system information/configuration

Mounting filesystems

File systems (e.g. disk partitions, remote file systems, card readers, USB memories) need to be mounted to be usable by users. Mounting means attaching to the current file system.

  • Threats: suid programs, device files (with poor protection)
  • Control: nosuid, nodev flags when mounting

PATH for trojans

Classic.

Network service wrappers: tcpd

Instead of modifying network servers to handle access control based on remote host address/name, start them using a "wrapper" program which does the access control, and then starts the program.

Configured in /etc/hosts.allow and /etc/hosts.deny. Example:

  • /etc/hosts.deny
(deny all hosts by default)
  • /etc/hosts.allow
    ALL: LOCAL
    ALL: .uu.se EXCEPT .student.uu.se
    (allow local domain, allow *.uu.se except *.student.uu.se)

Configurable authentication control: PAM

PAM = Pluggable Authentication Modules

PAM makes authentication mechanisms and policies dynamically configurable.

  • account management
    • has the user's password expired? is this user permitted access to that service?
  • authentication management
    • by /etc/passwd, NIS/YP, LDAP, ...
  • password management
    • updating authentication mechanisms
    • e.g. checking password strength
  • session management
    • things to do before and after access to a service has been given
    • e.g. audit, mounting/dismounting home directory

Allows configuration per "service" (program). Many modules ("pluggable") for different purposes.

7.1. Example: configuration for the "halt" program.
auth sufficient pam_rootok.so
  • it is sufficient if you're root
auth required pam_console.so
  • otherwise you need to be on the console
account required pam_permit.so
  • and just be a known user
7.2. Example: system authentication

Part of config for login, passwd, ...

Authentication management:

auth sufficient pam_unix.so likeauth nullok
  • it's sufficient if you try your own identity, and it's OK if the password is set to null
auth required pam_deny.so
  • otherwise we fail

Account management:

account sufficient pam_succeed_if.so uid < 100
  • we succeed if our UID is less than 100 (i.e. system services)
account required pam_unix.so
  • otherwise just ensure the account and password is active

Password management:

password requisite pam_cracklib.so retry=3
  • we test the password with "cracklib", and allow user to retry 3 times
password sufficient pam_unix.so nullok use_authtok md5 shadow
  • use authentication token if one exists, use md5-style encryption, and /etc/shadow
password required pam_deny.so
  • else deny

Session management:

session required pam_limits.so
  • set up limits on file sizes, open files, cpu time, etc.
session required pam_unix.so
  • log username and service

Updated  2005-09-26 17:25:13 by Björn Victor.