See this page as a slide show

CT320: Network and System Administration

Accounts and Namespaces

Thanks to Dr. James Walden, NKU, Russ Wakefield, CSU, and Dr. Indrajit Ray, CSU, for contents of these slides

Topics

1. UNIX User Accounts
2. Passwords
3. User Management
4. Namespaces

UNIX Accounts

• Account Components
  • Username
  • UID
  • Password
  • Home directory
• Account Files
  • /etc/passwd
  • /etc/shadow
  • /etc/group
• Account Management
  • Adding users
  • Removing and disabling users
  • Account/password policies

/etc/passwd, /etc/shadow

Central file(s) describing UNIX user accounts.

/etc/passwd entries

$ getent passwd root
root:x:0:0:root:/root:/bin/bash

$ getent passwd mstrout

$ getent passwd mstrout | tr : '\n'

Username

• Syntax
  • Each username must be unique.
  • 8 or fewer chars (32 on some systems)
  • Any character except : or newline, theoretically.
• Issues
  • Naming standards
    • applin, j_applin, or neutron?
  • How to ensure that usernames are unique?
  • System uses UIDs internally

UIDs

• UIDs are 32-bit non-negative integers.
• Standards
  • The super-user, root, is UID 0.
  • System accounts have low UIDs (≤1000)
• Uniqueness
  • Multiple usernames can have same UID!
  • Re-using UIDs may give away files to new user.
  • Distributed systems may require unique UIDs across organizational boundaries.

Password

• Syntax
  • Length: unlimited (MD5, SHA), 8 chars (crypt)
  • Chars: anything except newline, though certain control chars (e.g., backspace) may be interpreted by the system. Spaces are useful for passphrases.
• Stored in “encrypted” (really, hashed) format
  • Hashed: crypt, MD5, SHA

Password Field

Hashing

Good hash algorithms, such as SHA-512, are considered non-reversible, and return radically different results for small input changes:

Common passwords

According to Wikipedia, the most common passwords of 2016 are:

Rainbow Tables

• A simple attack is to use a list of common passwords and try them for every user. Or, just try every word in the dictionary.
  • Unfortunately, this means that you have to hash every word in the dictionary. Hashing is slow!
  • Speed it up by computing, once, hashes for all dictionary words. We call the precomputed hashes a Rainbow table.

Partial MD5 rainbow table:

    e0ebc3c409070d07f1df0f2f4132509e escape
    bafbb2fabbff5876f8bf7834f802936b escaped
    712f32fc42f27433a6db7cba03a980b3 escapee
    1ba8fbf22b249654d5cde753bae85def escaper
    f801cba4d35a3da1501ab3162cbb4dee escapes

Salt

• Salt is the cure for this.
  • Each line in the password file has some random salt bits.
    • $1$BTZEc3ZC$OgrtMuWtLyZ.9AbsXGTey0
  • 48-bit salt, as used with MD5 & SHA, means 2⁴⁸ (~281 trillion) different hashes for each password.
    • Makes pre-computed hash dictionaries impractical.

mkpasswd

mkpasswd can be handy for generating an initial password:

$ mkpasswd
au,E6bq7Z
$ mkpasswd
8exTO3wv-
$ mkpasswd -l 20
pPDrsgj4adtmh^kgpn5i
$ mkpasswd -c 2 -C 2 -s 2 -d 2
6;hft1#FM
$ mkpasswd -c 10 -C 10 -s 10 -d 10 -l 60
NVipnS-95}+I5fuzt5l$3%hinVhang{G0agjl83n&rf>Eiesj1XuTaX2xz$=
$ mkpasswd -c 0 -C 0 -d 0 -s 50 -l 50
>_)}>)@%{~{(%!:)-&~+&<+"|+;,<;]'=?%/.@@>}||+!*#&*&

Or, should you let the user choose one?

Password Aging

/etc/login.defs determines password longevity:

$ grep PASS /etc/login.defs
#	PASS_MAX_DAYS	Maximum number of days a password may be used.
#	PASS_MIN_DAYS	Minimum number of days allowed between password changes.
#	PASS_MIN_LEN	Minimum acceptable password length.
#	PASS_WARN_AGE	Number of days warning given before a password expires.
PASS_MAX_DAYS	99999
PASS_MIN_DAYS	0
PASS_MIN_LEN	5
PASS_WARN_AGE	7

• Is this good, from a security point of view?
• What value is PASS_MIN_DAYS?
• You can pre-expire the password, to force the user to change it:

    # passwd -e smith

Feedback

• I can’t seem to log in:

    $ ssh xyzzy@denver.cs.colostate.edu
    xyzzy@denver.cs.colostate.edu's password:
    Permission denied, please try again.
    xyzzy@denver.cs.colostate.edu's password:
    Permission denied, please try again.
    xyzzy@denver.cs.colostate.edu's password:
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

• Which was wrong, the account xyzzy or the password?
• Why didn’t it tell me which one?

GID

• GIDs are 32-bit non-negative integers.
• Each user has a default GID.
  • File group ownership set to default GID
  • Temporarily change default GID: newgrp
• Groups are described in /etc/group
  • Users may belong to multiple groups.
  • Format: group name, pw, GID, user list

    wheel:x:10:root,waldenj,bergs

GECOS

• Original use
  • Data for General Electric Comprehensive Operating System
• Current use
  • User information
  • Full name, location, phone number, e-mail

Home Directory

• Users CWD at login time
• Typically where user stores all files

Login Shell

• Process started when user logs in
• Typically a shell like bash, tcsh, ksh, or zsh
  • System users may be different.
  • Disabled accounts have a special “go-away” shell.

$ getent passwd | cut -d: -f7 | sort | uniq -c | sort -n
      1 /bin/bash
      1 /bin/sync
      1 /sbin/halt
      1 /sbin/shutdown
   6317 /sbin/nologin

Changing your Shell

$ cat /etc/shells
/bin/sh
/bin/bash
/usr/bin/sh
/usr/bin/bash
/usr/bin/tmux
/bin/tmux
/usr/bin/zsh
/bin/zsh
/bin/ksh
/bin/rksh
/usr/bin/ksh
/usr/bin/rksh
/bin/csh
/bin/tcsh
/usr/bin/csh
/usr/bin/tcsh
/bin/false
/bin/true
/sbin/nologin
/usr/local/etc/no_access

• The chsh program change your login shell.
• It may restrict your shell to one from /etc/shells.
  • Why?
• Alas, chsh fails here, so you have to send email to the sys admin people. How quaint!

Adding a User

1. Create account with useradd.
2. Lock account until user arrives.
3. User signs account agreement.
4. Set password with the passwd command.
   • Yes, both /etc/passwd and /bin/passwd exist.

Adding a User

• Edit /etc/{passwd,shadow} with vipw.
• Set password with the passwd command.
• Edit /etc/group to add groups.
• Create user home directory.
  • mkdir /home/studenta
  • chown studenta.student /home/studenta
  • chmod u=rwx,go=rx /home/studenta
• Copy default files from /etc/skel: .bashrc, .Xdefaults, .xsession, etc.
• Set e-mail aliases, disk quotas, etc.
• Verify that the account works.

Disabling an Account

• Edit account configuration:
  • Place * in front of encrypted password.
  • Replace shell with nologin program.
• Kill active logins and processes.

Removing a User

• Disable account.
• Change shared passwords (root, etc.)
  • Why are you using @#!?☠$★ shared passwords‽
• Kill active logins and processes.
• Remove:
  • from local databases/files
  • from e-mail aliases
  • mail spool (backup first)
  • crontabs and pending jobs
  • temporary files
  • home directory (backup first)
  • from passwd, shadow, and group
• Or use userdel.

Namespaces

Systems include many namespaces:

• User account names
• Filesystem pathnames
• Hostnames
• Printer names
• Service names

Types of Namespaces

• Flat
  • No duplicates may exist.
  • Example: usernames in /etc/passwd
• Hierarchical
  • Tree-structured namespace like DNS.
  • Duplicates can exist.
  • Ex: www.nku.edu and www.google.com

Namespace Problems

• How to select names?
• How to avoid name collisions?
• How to ensure consistency?
• How to distribute names?

Name Selection

• Functional Names
  • mail hostname, ~ct320, student account
• Formula-based Names
  • cvg0141 hostname, student0148 account
• Themed Names
  • constellations (orion, ursa, etc.)
  • Use something big. Seven dwarves doesn’t allow for much expansion.
• Steal from another standard (e.g., .us, .fr, .de)
• No Standard

Name Lifetime

• When are names removed?
  • Immediately ater PC, user leaves org
  • Set time after resource is no longer in use
• When are names re-used?
  • Immediately: functional names
  • Never
  • Ater a set time

Namespace Scope

• Geographical scopes
  • Local machine. (e.g., /etc/passwd)
  • Local network
  • Organization
  • Global (e.g., DNS)
• Service scopes
  • Single username for UNIX, NT, e-mail
• Transferring scopes
  • Difficult without advance planning.
  • Some names may have to change.

Key Points

• UNIX accounts use /etc/passwd
• Password security: shadow, hashing, salts
• User management: add, disable, remove
• Namespaces: flat and hierarchical
• Name selection policies
• Names are valid in specific scopes