• See the section of General Admin Principles that deals with Users.

See Types of Users.

Becoming root

• Use su or su - or su - root
  • Can also use su to become a normal user, e.g., su - jchung
• Login as root
  • Login at the login manager, if the system is configured to allow this.
  • Ssh in as root, if SSH configured to allow this.
• Becoming root is usually discouraged because of the possibility of running disastrous commands as root.
  • Even experienced admins should be careful about logging in as root/administrator.

Running as root/administrator

• Login as a normal user and only run selected commands as root or administrator
  • Safer than doing everything as root
  • Can use su to do this with its -c or –command option
  • Recommended to use sudo instead
    • Requires user to be put in a sudo group
      • See information on groups below.
    • User enters their user password, not the root password to run commands as root.
    • Users may be restricted in the set of commands they can run as root.
      • Allows team- or delegated administration, if restrictions are carefully written in the sudo config file, /etc/sudoers
        • sudo config is typically done by running visudo as root
    • If configured to allow it, can also become root using sudo by running sudo su -.
      • But becoming root is discouraged, as always.

• Steps involved (usually automated through utilities such as adduser)
  • Determine login name, user ID (UID), group ID (GID)
  • Add user data to /etc/passwd file
  • Assign a password
  • Set account parameters (e.g. password aging, account expiration, system resource limits, disk quotas)
  • Create home directory
  • Copy initialization files/personal shell profiles
    • /etc/skel
  • Set file ownerships and permissions (use chown, chgrp, chmod commands)
  • Add user to other facilities (create mail spool, add to mail aliases file)
  • Perform other site-specific initialization tasks
  • Test the new account

• Fields in the /etc/passwd file

     logname:(encrypted-passwd):uid:gid:user info:home:shell

• The shell specified in /etc/passwd must exist, and the full path must be supplied, else login will fail
  • Especially if a bad shell entry is inserted in the root entry in /etc/passwd

• Shadow passwords
  • On any recent variant of UNIX, the encrypted passwords are in /etc/shadow, not /etc/passwd
    • Contains encrypted passwords
    • Readable by root only, whereas /etc/passwd is readable by everyone

• /etc/passwd and /etc/shadow should be edited using 'vipw' and 'vipw -s', respectively.
  • Puts a lock on /etc/passwd or shadow, preventing multiple root-privileged users from editing those files at the same time, which could potentially cause inconsistencies.

• Groups
  • Users are usually put in more than one group
    • Though, in UNIX, they have one primary group, which is specified in the /etc/passwd file's gid field.
    • Try running 'id' on rockhopper to see what groups you belong to.
  • Only those with administrative privileges can control what users belong to what groups, and also create/delete groups.
  • Fields in the /etc/group file

          group:(group password):gid:members      # group passwords are not common

• Edit with vigr.

• An admin must assign a password when creating a new user.
  • The tricky part is assigning a non-trivial password, so that new accounts can't be easily compromised.
  • Also, a policy to enforce tough user-chosen passwords should be in place.
    • Even the most security-hardened system can be compromised by one user who chooses an easily-guessed password.
• One commonly used algorithm for password creation is to take two non-related words, separate them with a punctuation character, mix in some upper-case characters, and perhaps reverse one of the words. E.g.,

    DOg.tenT (mixed upper/lower case)
    t00l%p0nd (zeros instead of "O")
    p33l*BOARd (substitute numeric for alpha)
    tned-Pile (reversed first word)

• Could also try pwgen (apt-get install pwgen).

• C shell: ~/.cshrc, ~/.login, ~/.logout, /etc/cshrc, /etc/cshrc.std
• Borne (Again) shell: ~/.profile, /etc/profile, /etc/profile.std, /etc/bashrc, .bashrc, .bash_profile
• Skeleton files: in /usr/skel, /etc/skel, or /etc/security directories
  • Copied into the home directories of newly-created users

• Some user account creation utilities from different UNIX variants:
  • sysadm (System V)
  • useradd (System V.4, some BSD / Linux)
  • SMIT (AIX)
  • admintool (Solaris)
  • adduser, addgroup (Some BSD / Linux)
  • several public domain shell scripts
    • Sometimes, the need arises to add many users at once (academic institutions, every semester).
      • Third party applications or in-house scripts are usually used to do this.

• Steps involved in deleting an account:
  • Remove or modify entry in /etc/passwd
  • Remove mail spool
  • Remove from mail aliases file
  • Remove any cron or at jobs
  • Remove home directory

• Locking/disabling an account
  • 'passwd -l userid' locks an account
    • userid can no longer log in.

• Users can fill up disk space quickly.
  • Multimedia downloads (music, videos)
  • File sharing (“warez”)
  • Software installation
  • Two ways to deal with this: 1) detect & delete or 2) use quotas
• UNIX/Linux disk quotas:
  • See http://tinyurl.com/4v2z7dh
  • Debian: install quota package
  • Modify /etc/fstab
    • /dev/hda2 /home ext3 defaults,usrquota,grpquota 1 1
      • usrquota - enable per user disk quotas
      • grpquota - enable per group disk quotas
  • Create /<file system>/aquota.user or /<file system>/aquota.group
    • If applying quotas to /home, then /home/aquota.user or /home/aquota.group
    • Run quotacheck to scan file system for disk usages, and create/update the quota record files “aquota.user/aquota.group” to the most recent state.
  • Run quotaon or quotaoff to turn on/off quotas for file systems.
  • Run edquota -u user_id or edquota -g group_name to edit disk quotas for individual users or groups.
    • Quota table params:
      • Blocks: The amount of space in 1K blocks the user/group is currently using.
      • Inodes: The number of files the user is currently using.
      • Soft Limit: The maximum blocks/inodes a quota user may have on a partition.
        • The role of a soft limit changes if grace periods are used. When this occurs, the user is only warned that their soft limit has been exceeded. When the grace period expires, the user is barred from using additional disk space or files. When set to zero, limits are disabled.
          • Grace periods are set with edquota -t.
      • Hard Limit: The maximum blocks/inodes a quota user may have on a partition when a grace period is set. Users may exceed a soft limit, but they can never exceed their hard limit.
    • Example: mp3user below is limited to a maximum of 5MB of data storage on /dev/hda3 (if /home is on /dev/hda3):

                  Disk quotas for user mp3user (uid 503):

                    Filesystem  blocks       soft       hard     inodes     soft     hard
                    /dev/hda3       24       5000          0          7        0        0

• See http://tinyurl.com/4bomtw2
• A way to automate control of user processes
• Want to prevent runaway/malicious user processes (e.g. fork bombs) from bogging system down.
  • Or limit how much file system space their core dumps can consume.
• UNIX/Linux: See man ulimit (man page for the ulimit system function)
  • ulimit is also a shell built-in command (see ulimit section of man bash)
• Setting system default ulimits
  • Debian: See /etc/security/limits.conf
    • See rockhopper:/etc/security/limits.conf for rockhopper user limits
    • /etc/security/limits.conf is a PAM configuration file because user limits enforcement is naturally a function of the user authentication system. See below.

• If user accounts are present on a system, they will need to login to their accounts and/or system services.
  • Sometimes, they will need to authenticate even after initial login, e.g., locking screen savers.
  • There may be multiple methods to initially login, e.g., login via ssh, login via telnet, login via ftp, login via GDM.

• Pluggable authentication modules, or PAM, is basically a flexible mechanism for authenticating users.
  • a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API).
  • Allows programs that rely on authentication to be written independent of the underlying authentication scheme.
    • These programs have PAM “authentication modules” attached to them at run-time in order to work.
  • First proposed by Sun Microsystems in 1995.
  • Currently supported in multiple UNIX and UNIX-like operating systems including Linux and Mac OS X.

• See http://tinyurl.com/y3mwv5h

• In Linux PAM, there are four groups of modules:
  • Account modules check that the specified account is a valid authentication target under current conditions.
    • This may include conditions like account expiration, time of day, and that the user has access to the requested service.
  • Authentication modules verify the user's identity, for example by requesting and checking a password or other secret.
    • They may also pass authentication information on to other systems like a keyring.
  • Password modules are responsible for updating passwords, and are generally coupled to modules employed in the authentication step.
    • They may also be used to enforce strong passwords.
  • Session modules define actions that are performed at the beginning and end of sessions.
    • A session starts after the user has successfully authenticated.

• The /etc/pam.d directory contains PAM application support and module definitions.
  • Recall setting of password encryption standard in /etc/pam.d/common-password.
• The /lib/$(MACHTYPE)/security directory contains PAM library modules.
• The /etc/security directory contains PAM config files.

Read information on fork bombs and prevention at the following two links:

• http://www.cyberciti.biz/faq/understanding-bash-fork-bomb/
• http://www.cyberciti.biz/tips/linux-limiting-user-process.html

Apply the fork bomb preventative measures to your Linux systems. Test a fork bomb, but make sure the limits are in place first!