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.

1. 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

Every process is associated with a user id (numeric), a (primary) group id, and an additional list of group ids. (Not the full story, see below under suid/sgid.)

2. 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: these bits are CLEARED in permission of new files

  • 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.

Some services require superuser privileges to perform necessary operations, e.g. opening network ports < 1024 - this applies to most network servers, including a web server (port 80).

  • Problem: Running network servers with superuser privileges is a major security risk for remote attacks
  • Solution: open the server port as root, then change the effective user id to a less powerful one ("disabling" superuser privileges)
  • Example: the Apache web server, where the "other" user (and group) can be configured.
  • Note: only the superuser can change user id.
2.2. ACLs

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

(Note: in Linux, need to mount the file system with a special option.)

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

3. 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

4. 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 and/or unusual names)
  • Control: nosuid, nodev flags when mounting (and noexec to prevent any executable program)

5. Audit logs

Records are kept of e.g.

  • the last time a user logged in (lastlog)
  • every time a user logs in or out (wtmp)
  • who is currently logged in (utmp)
  • (optionally) accounting information about each process which terminates (acct)

In addition the syslog process (system logger) logs more or less important events, such as failed logins, firewall events, ...

6. Environment variables for trojans

Classic method for trojan attacks. Examples:

  • The PATH variable is a directory search list for "commands". Do not include "." (the current directory).
  • The LD_LIBRARY_PATH is a directory search list for shared libraries. Do not include untrustworthy directories.

Countermeasures: suid/sgid programs should reset the sensitive variables.

7. 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)

8. 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

We don't want to rewrite/recompile every program as our policies change. Instead, write them to call the PAM library.

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

The goals of the PAM framework are as follows (OSF RFC 86.0):

  1. The system administrator should be able to choose the default authentication mechanism for the machine. This can range from a simple password-based mechanism to a biometric or a smart card based system.
  2. It should be possible to configure the user authentication mechanism on a per application basis. For example, a site may require S/Key password authentication for `telnet' access, while allowing machine `login' sessions with just UNIX password authentication.
  3. The framework should support the display requirements of the applications. For example, for a graphical login session such as `dtlogin', the user name and the password may have to be entered in a new window. For networking system-entry applications such as `ftp' and `telnet', the user name and password has to be transmitted over the network to the client machine.
  4. It should be possible to configure multiple authentication protocols for each of those applications. For example, one may want the users to get authenticated by both Kerberos and RSA authentication systems.
  5. The system administrator should be able to stack multiple user authentication mechanisms such that the user is authenticated with all authentication protocols without retyping the password.
  6. The architecture should allow for multiple passwords if necessary to achieve higher security for users with specific security requirements.
  7. The system-entry services should not be required to change when the underlying mechanism changes. This can be very useful for third-party developers because they often do not have the source code for these services.
  8. The architecture should provide for a pluggable model for system authentication, as well as for other related tasks such as password, account, and session management.
  9. For backward-compatibility reasons, the PAM API should support the authentication requirements of the current system-entry services.
8.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
8.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