Unix security

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

• 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

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

# 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

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

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)

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

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.

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)

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.