USER ADMINISTRATION

USER ADMINISTRATION
Creating users and providing password:
useradd
adduser
passwd
Accounts may be added in a batch with newusers
vim userlist
usr1:redhat:512:512::/home/usr1:/bin/bash
usr2:redhat:513:513::/home/usr2:/bin/bash
usr3:redhat:514:514::/home/usr3:/bin/bash
usr4:redhat:515:515::/home/usr4:/bin/bash
usr5:redhat:516:516::/home/usr5:/bin/bash
usr6:redhat:517:517::/home/usr6:/bin/bash
usr7:redhat:518:518::/home/usr7:/bin/bash
usr8:redhat:519:519::/home/usr8:/bin/bash
usr9:redhat:520:520::/home/usr9:/bin/bash
To create users
newusers
newusers userlist
Note: only drawback of using this method is that the user’s home directories do not get populated with
the files from /etc/skel. so copy the hidden files from /etc/skel to user's home directory.
cp –rf /etc/skel/.* /home/usr1
useradd command populate entries in three files,
/etc/passwd
/etc/shadow
/etc/group
When user accounts are created, a private group is also created with the same name, users are
assigned to this private group
Entries in /etc/passwd
one:x:501:501::/home/one:/bin/bash
user name of the account
An x in the password field. Passwords are stored in the /etc/shadow file or else will contain
the user's encrypted password.
Numeric user id. This is assigned by the useradd script
A common convention is to number them sequentially starting from 500.
Accounts with a UID under 100 are generally system accounts.
root user always having the UID 0
Numeric group id. Red Hat uses group is in a fairly unique manner for enhanced file security.
Usually the group id will match the user id.
Comment field. User details such as name, contact number, address.......
User’s home directory. Usually /home/username (eg. /home/one). All user’s personal files,
web pages, mail forwarding, etc. will be stored here.
User’s shell account. Often set to /bin/bash to provide access to the bash shell
Entries in /etc/shadow
one:$1$vDPEOJMj$OG6VnnJrYS75z.fxadMCA/:13805:0:99999:7:::
As with the passwd file, each field in the shadow file is also separated with colon,characters,
and are as follows:
Username. Case-sensitive, usually all lowercase. A direct match to the username in the
/etc/passwd file.
Password, encrypted. A blank entry (eg. ::) indicates a password is not required to login, and
an entry (eg. :*:) indicates the account has been disabled.
The number of days (since January 1, 1970) since the password was last changed.
The number of days before password may be changed (0 indicates it may be changed at any
time)
The number of days after which password must be changed (99999 indicates user can keep
his or her password unchanged for many, many years)
The number of days to warn user of an expiring password (7 for a full week)
The number of days after password expires that account is disabled
The number of days since January 1, 1970 that an account has been disabled
A reserved field for possible future use
Entries in /etc/group
class:x:541:stud4,stud3,stud2,stud1
Name of the group
group password, or an 'x' when using shadow passwords
unique group ID
comma-seperated list of group members
GROUP ADMINISTRATION:
ADD A GROUP
groupadd
DELETE A GROUP
groupdel
CHANGE A GROUP NAME
groupmod -n
CHANGE THE FILE'S GROUP OWNERSHIP:
chgrp
CHANGE THE FILE'S OWNERSHIP:
chown
Note: if we change the group name, then automatically the members are also added to that newgroup
ALLOCATE USER TO GROUP
ADDING USERS DIRECTLY TO A GROUP
useradd -G
useradd -G class stud2
ADDING AN EXISTING USER TO A GROUP
usermod -G
usermod -G class stud1
gpasswd [-a user]
DELETING USER FROM A GROUP
gpasswd [-d user]
USER ID ANG GROUP ID
root user
system user accounts
users
In order to avoid using GID within the range typically assigned users and their private groups, use -r
groupadd -r
groupadd -r class1
The above command will create an entry in /etc/group like this
class1:x:101:std2,std1
Note: The group ID's are allocated from 101
MODIFYING USER ACCOUNTS:
usermod [options] username
options:
-d
-e
-g
-G
-l
-s
-u
-p
-L
-U
DELETING USERS ACCOUNTS:
userdel
userdel -r
(or)
Manually remove the user from /etc/passwd, /etc/shadow, /etc/group, /var/spool/mail
PASSWORD AGING POLICIES:
By default, passwords do not expire
Forcing passwords to expire is part of a strong security policy
Modify default expiration settings in /etc/login.defs
0
 1-100
 starting from 500
change the home directory
set the date on which the account will expire and be disabled
change the initial login group
change group name
change login name
change the login shell
change login ID
change the string in the password field
Lock the password.
Unlock the password
deletes user from system
deletes user and the home directory of the user
To modify password aging for existing users, use the chage command
chage [options] username
Options:
-d, --lastday
-E, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
-I, --inactive
-l, --list
-m, --mindays
LAST_DAY
set last password change to LAST_DAY
INACTIVE
MIN_DAYS
-M, --maxdays
-W, --warndays WARN_DAYS
-h, --help
MAX_DAYS
set password inactive after expiration to INACTIVE
show account aging information
set minimum number of days before password
change to MIN_DAYS
set maximim number of days before password
change to MAX_DAYS
set expiration warning days to WARN_DAYS
display this help message and exit
LOGIN SHELL SCRIPTS:
/etc/profile
~/.bash_profile
/etc/profile.d/*.sh
~/.bashrc
/etc/bashrc
/etc/profile is executed every time a user logs in to the system. It will set environment
variables for the user such as HISTSIZE and MAIL. This is the first script executed at login.
The user's ~/.bash_profile scripts runs next,
which typically calls ~/.bashrc and /etc/bashrc.
The /etc/profile contains system-wide environment settings; whatever is added or
removed here affects all users.
/etc/profile.d contains initialization scripts specific to software packages installed by RPM.
These scripts are called by /etc/profile.d on login, or by /etc/bashrc if called by a non-
interactive shell.
~/.bash_profile is executed once at login time. It is usually used to set environment
variables and to start programs at login, as opposed to every time you open a terminal
window.
NON LOGIN SHELL SCRIPTS:
~/.bashrc
/etc/bashrc
/etc/profile.d/*.sh
~/. bashrc allows users to customize their own aliases and functions without the
intervention of the administrator.
it runs whenever a user
~/.bash_profile also calls it whenever the user logs
The /etc/bashrc script is used for system-wide functions and aliases.
It alllows a system-administrator to set aliases for every user, like “c” for “clear” or “h” for
“history”. This script is usually called by a user's ~/.bashrc file.
SWITCHING ACCOUNTS:
su - [user]
su - [user] -c command
Allows the user to temporarily another user
Default user is root
The '-' option makes the new shell a login shell
SUDO:
Users listed in /etc/sudoers execute commands with:
an effective user id of 0
group id of root's group
sudo acess is controlled by /etc/sudoers.


This file should be edited with 'visudo'
TO GIVE PERMISSION TO USE A COMMAND FOR A SET OF USERS
visudo
User_Alias USERS = test, test1
Cmnd_Alias COMMAND = /sbin/fdisk
USERS ALL=COMMAND
Now the above list of users can use the commands in the list.
su - test
sbin/fdisk -l
sudo /sbin/fdisk -l now it is working
starts up a non-login interactive shell, and the default user
 not working
TO GIVE FULL PERMISSION LIKE ROOT
visudo
test1
The user test1 can run any command using sudo
sudo /sbin/fdisk -l
ALL=(ALL)
ALL
FILE OWNERSHIP:
Every file has both user and group "ownership"
A newly created file will be owned by:

the user who creates it

the current primary group of that user

SGID directories may change this behavior

The chown command can be used by root to change ownership
Examples:
touch new new1
ls -l (or) ll
-rw-r--r-- 1 root root 0 Oct 12 15:02 new
-rw-r--r-- 1 root root 0 Oct 12 15:02 new1
File ownership can be changed as follows
chown stud1 new1
ll
-rw-r--r-- 1 stud1 root 0 Oct 12 15:02 new1
File ownership and group name can be changed as follows
chown stud2:class new
(or)
chown stud2.class new
ll
-rw-r--r-- 1 stud2 class 0 Oct 12 15:02 new
SUID / SGID EXECUTABLES

Normally processes started by a user run under the user and group security context of that
user

SUID and/or SGID bits set on an executable file cause it to run under the user and/or group
security context of the file's owner and/or group
Example: SUID
ll /sbin/fdisk
-rwxr-xr-x 1 root root 95572 Jan 11 2007 /sbin/fdisk
chmod 4755 /sbin/fdisk
(or)
chmod u+s /sbin/fdisk
-rwsr-xr-x 1 root root 95572 Jan 11 2007 /sbin/fdisk
login as any user and try to access fdisk command
STICKY BIT AND SGID:
groupadd mba
useradd -G mba st1
useradd -G mba st2
useradd -G mba st3
mkdir /work
chgrp mca /work
chmod 777 /work
chmod 770 /work
chmod 1770 /work
or
==> Creating working directory
==> Assigning working directory to group
==> Setting full permission to that directory
(any user can access the group directory)
==> Setting owner ang group only to access
==> Sticky Bit
( owner only having full permission to edit and delete files)
chmod o+t /work
chmod g+s /work
chmod 2770 /work
or
(group names are assigned in this mode (SGID) )
ACCESS CONTROL LISTS (ACL)
ACLs can be configured:

Per user

Per group

For users not in the user group for the file
Grant RWX access to files to multiple users or groups
mount -o remount,acl /home
getfacl file|directory
getfacl /home/newfile.txt
For example, to give read and write permissions to user jack, group class rw:
setfacl -m u:jack:rwx /home/newfile.txt
The above command would grant the user jack read, write and execute access to the file
/home/newfile.txt
To remove acl
setfacl –x u:jack /home/newfile.txt
On directories, default access control lists can be used. If we wanted all newly created content of a
directory to be readable and writable by the user student:
setfacl -m d:u:student:rw /home/share/project/
To set acl to a directory:
setfacl -m d:o:rx /share
The above command would grant the others to read and execute access to the directory /share
To remove all the permissions for a user, group, or others, use the -x option and do not specify any
permissions:
setfacl -x
setfacl -x u:new /mnt

For example, to remove all permissions from the user with UID 500:
setfacl -x u:500 /project/somefile
SELinux
There is an old UNIX saying that everything is a file. Traditional file access is controlled
by user, group, and permission settings. To SElinux, everything is an object and access is
controlled by security elements stored in the inode’s extend attribute fields. Collectively, the elements
are called the security context.
In Red Hat Enterprise Linux 4, SELinux was protecting 13 processes.
In the initial release of Red Hat Enterprise Linux 5, this count had increased to 88.
All files and processes have a security context
The context has several elements, depending on the security needs
user:role:type:sensitivity:category
user_u:object_r:tmp_t:s0:c0
user:
Indicates the type of user that is logged in to the system.
For root user the name will be displayed as root,
Processes have the valve system_u.
For other users user_u.
role :
Defines the purpose of the particular file, process, or use.
Files have the role of object_r
Process and Users get the role of system_r.
Type :
Used by Type Enforcement to specify the nature of the data in a file or a processes.
Rules within the policy say what process types can access which file types.
Sensitivity:
A security classification sometimes used by government agencies.
Category:
Similar to group, but can block root’s access to confidential data.
Not all systems will display s0:c0
To view the security context of a file, user the ls command’s –Z option:
ls –Z
Ex:
ls –lZ /root/anaconda-ks.cfg /var/log/messages
Generally, Files having Directory’s security context
ls –Zd /etc/ /etc/hosts
ls –Z /etc/shadow /etc/aliases
To determine the process is protected by SELinux.
ps –ZC syslogd,bash
SELinux Key Components - Policy
Strict
A system where everything is denied by default.
You must specify allow rules to grant privileges
SELinux designed to be a strict policy.
The policy rules only have allows, no denies.
Minimal privilege's for every daemon
separate user domains for programs like GPG,X, ssh, etc
Difficult to enforce in general purpose Operating system.
Targeted
System where everything is allowed. use deny rules.
Protects systems Doors and Windows
By default processes run in unconfined_t.
unconfined processes have the same access they would have without SELinux running.
Daemons with defined policy transition to locked down domains.
httpd started from unconfined_t transitions to httpd_t which has limited access.
Any process whose type is unconfined_t, is not yet restricted by SELinux.
To view the entire process stack, use either
ps –eZ
or
ps Zax
Note: A restricted process is sometimes called protected, though it is the data that is protected, not
the process.