Joe Chung
Monmouth U. Homepage

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Users and Limits ======

----

===== Users & Groups =====

  * See the section of [[cs_471_-_general_sysadmin_principles?&#users|General Admin Principles]] that deals with Users.

==== Becoming root vs. Running as root (su, sudo) ====

See [[http://rockhopper.monmouth.edu/cs/jchung/cs471/cs_471_-_introduction_unix_installation#types_of_users|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.
==== Adding new users ====

  * 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//.
==== Choosing passwords ====

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

==== Shell initialization files ====

  * 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

==== Automating account creation / deletion ====

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

==== Disabling and/or removing user accounts ====

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

==== User quotas and limits ====

=== Disk quotas ===

     * 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):

<code>
                  Disk quotas for user mp3user (uid 503):

                    Filesystem  blocks       soft       hard     inodes     soft     hard
                    /dev/hda3       24       5000          0          7        0        0
</code>
 
=== Resource usage quotas ===

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

==== User authentication and PAM ====

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

=== Linux PAM ===

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

----

===== Lab Activity =====

==== Fork bombs & ulimits ====

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 [[cs_471_tasks|preventative measures to your Linux systems]]. Test a fork bomb, but make sure the limits are in place first!

----