0% found this document useful (0 votes)
6 views30 pages

User Management and Security Overview

Chapter 2 discusses account and security administration, focusing on user management, registration, and access control in both Unix and Windows systems. It covers the creation and management of user accounts, the importance of password security, and file access control mechanisms. Additionally, the chapter highlights the ethical responsibilities of system administrators in maintaining user support and resource management.

Uploaded by

abrehamcheru15
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views30 pages

User Management and Security Overview

Chapter 2 discusses account and security administration, focusing on user management, registration, and access control in both Unix and Windows systems. It covers the creation and management of user accounts, the importance of password security, and file access control mechanisms. Additionally, the chapter highlights the ethical responsibilities of system administrators in maintaining user support and resource management.

Uploaded by

abrehamcheru15
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Chapter 2

Account and Security


Administration, & Access Control
Account and security
Administration
User management
 Users are both the reason that computers exist and their
greatest threat.
 User management is about interfacing humans to computers.
 This brings to light a number of issues:
 Accounting: registering new users and deleting old ones.
 Comfort and convenience.
 Support services.
 Ethical issues.
 Trust management and security.
Account and security
Administration
User registration
 One of the first issues on a new host is to issue accounts for users.
 In small organizations, user registration is a relatively simple matter.
 Users can be registered at a centralized location by the system manager
 The issues of creation and management often clash in distributed
organisations
 Central creation and management
 Central creation, delegated management
 Delegated creation and management. The need to provide privileged access is a
security weakness
 No universal standard method of user registration
 one of the unsolved problems of system administration.
 the requirements of each organization are rather different.
Local and Network Accounts
 Both Unix and NT support the creation of accounts
 locally on a single host, or
 ‘globally’ within a network domain.
 Local accounts
 are configured on the local host itself.
 a user has permission to use only the local host.
 Changes to an account (e.g. new password) on one host do not
affect similar accounts on other hosts.
 With a network account
 the user can use any host which belongs to a network domain.
 a single user account is shared amongst many hosts.
 Changes globally affect all other hosts.
 NIS and DCE are standard based network user systems
Unix Accounts
To add a new user to a Unix-like host we have to:
 Unique username, UID# and password
 Store user details in system password database
(/etc/passwd, /etc/group)
 Create login directory for user (i.e. home)
 Choose a shell for the user (if appropriate)
 Copy some configuration files like .cshrc or
.profile into the new user’s directory, or update the
system registry.
 Often done using adduser command
Windows Accounts
 Single Windows accounts are added with the
command
 net user username password /ADD /domain
 using the GUI
 Batch user creation with [Link]
 allow lists of users to be registered from a standard file format

 Only a single kind of shell (command


interpreter) available
 Domain users may have initialisation scripts
and automatic drive mapping
 User directory can be shared. eg H:
Groups of Users
Group
 an association of usernames which can be referred to
collectively by a single name.
 Used to allocate process or file permissions to groups
of users
 Individual users may be members of several groups
 Groups are defined statically by the system
administrator.
 On Unix-like systems they are defined in the
/etc/group file, like this:
 users::100:user1,mark,user2,user3
 Users is the name of the group, with group-id 100
and members user1, mark, user2 and user3.
Groups of Users
 On Windows groups are created by command
 net group groupname /ADD
 Users may then be added with the syntax,
 net group groupname username1 username2... /ADD

 They can also be edited with the GUI on a local host.


 Some standard groups are defined by the system, e.g.
 Administrators
 Users
 Guest
 The Administrators group has privileged access to the
system.
User Account Policy
 Rules or standards for account management
For example….
 Standard for username creation
 Standards for password (prevent weak pwd)
 Disk quota
 Logging and accounting
 Internet protocols and Quota
 Rules about what users are allowed/not allowed to do.
 Guest accounts are a bad idea.
 they usually have weak or non-existent passwords
 therefore are an open invitation to attack the system.
The privileged account’s or
superuser’s environment
 Privileged account gives us the power to destroy the system,
or sabotage it.
 should be configured to avoid as many casual mistakes as
possible.
 The privileged user should never log in directly
 unless the system is in single user mode or on the console.
 On Unix, one should log in as a user and su to root.
 This keeps a record of who is root at any time
 is more secure in the sense of having fewer points of attack.
User support services
 All users require help at some time or another.
 The fact that normal users are not privileged users means
that they must occasionally rely on a superuser to clean up
a mess, or fix a problem which is beyond their control.
 It is important to:
 Train users.
 Help users.
 Document and provide the answers to frequently asked questions.
Managing User Resources
 Variety of usage patterns requires balance of
demand by passive and active users
 System administrators have a responsibility to
find a balance which addresses users’ needs but
which keeps the system stable and functional.
 Disk space quotas
 CPU usage & Process count limits
 Garbage collection – deleting temporary and
unused files – needs a careful definition!
Managing User Resources
 Quotas have an unpleasant effect on system morale, since
they restrict personal freedom.
 They should probably only be used as a last resort. There are
other ways:
 Killing old processes
 Processes sometimes do not get terminated when they should.
 Terminating orphan/run-away processes
 Moving and removing users
 When disk partitions become full, it is necessary to move users
from old partitions to new ones
 Deleting old users
 it is often advisable to keep old accounts for a time in case the
user actually returns, or wishes to transfer data to a new location.
 Whether or not this is acceptable must be a question of policy.
 Before deleting a user completely, a backup of the data can be
made for safe-keeping.
Password security
 Password security is the first line of defence against intruders.
 Once a malicious user has gained access to an account, it is very
much easier to exploit other weaknesses in security.
 User education is clearly an important weapon against weak
passwords.
 Some sites use schemes such as password aging in order to force
users to change passwords regularly.
 No one with an easy password is safe.
 Passwords should never be any word in a dictionary or a simple
variation of such a word or name.
 It takes just a few seconds to guess these.
Filesystems
 Files and filesystems are at the very heart of what system
administration is about.
 Almost every task in host administration or network
configuration involves making changes to files.
 We need to acquire a basic understanding of the principles
of filesystems.
Filesystems
Unix file model
 Unix has a hierarchical filesystem, which makes use of directories and
subdirectories to form a tree.
 All file systems on Unix-like operating systems are based on a system of
index nodes, or inodes, in which every file has an index entry stored in a
special part of the filesystem.
 The inodes contain an extensible system of pointers to the actual disk
blocks which are associated with the file.
 The inode contains essential information needed to locate a file on the
disk.
 The top or start of the Unix file tree is called the root filesystem or ‘/’.
Although the details of where common files are located differ for
different versions of Unix, some basic features are the same.
Filesystems
The file hierarchy
 The main subdirectories of the root directory together with the most
important file are shown below.
 /bin Executable (binary) programs.
 /etc Miscellaneous programs and configuration files.
 /usr This is where application software lives, together with
all of the basic libraries used by the OS.
 /usr/bin More executables from the OS.
 /usr/sbin Executables that are mainly of interest to system
administrators.
 /usr/local This is where users’ custom software is normally added.
Filesystems
The file hierarchy
 /sbin A special area for (often statically linked) system
binaries.
 /sys This holds the configuration data which go to
build the system kernel.
 /export This contains the disk space set aside for client
machines which do not have their own disks. It is
like a ‘virtual disk’ for diskless clients.
 /dev and /devices A place where all the ‘logical devices’ are
collected.
 /home ( /users on some systems.) Each user has a separate
login directory where files can be kept.
Filesystems
 Every Unix directory contains two ‘virtual’
directories marked by a single dot and two dots ( .
.. )
 The single dot represents the directory one is already
in (the current directory).
 The double dots mean the directory one level up the
tree from the current location.
 E.g. cd /usr/share
cd ..
 the final directory is /usr.
Filesystems
 Symbolic link: a pointer or an alias to another file.
 The command
 ln -s fromfile /other/directory/tolink
 makes the file fromfile appear to exist at /other/directory/tolink
simultaneously.
 The file is not copied, it merely appears to be a part of the file tree
in two places.
 Symbolic links can be made to both files and directories.
 Hard link: a duplicate directory reference to an
inode in the filesystem.
 It is in every way equivalent to the original file reference.
 If a file is pointed to by a number of hard links, it cannot be
removed until all of the links are removed.
File access control
 Unix records information about who creates files and also who is allowed
to access them later.
 Unix makes no policy on what names files should have: a file can have any
name, as long as it does not contain illegal characters such as forward-
slash.
 A file belongs to user A if it is owned by user A.
 User A then decides whether or not other users can read, write or execute
the file by setting the protection bits or the permission of the file using the
command chmod.
 Every user is a member of at least one group, called the login group and
each group has both a textual name and a number (group id).
 The uid and gid of each user is recorded in the file /etc/passwd.
 Membership of other groups is recorded in the file /etc/group or on some
systems /etc/logingroup.
File access control
 The following output is from the command ls -lag executed on a SunOS
type machine.

 The first column is a textual representation of the protection bits for each
file.
 Column two is the number of hard links to the file, for regular files, or
the number of objects contained in a subdirectory.
 The third and fourth columns are the user name and group name and the
remainder show the file size in bytes and the creation date.
File access control
 The leading bits give information about the type of file: is the file a plain
file, a directory or a link etc. (i.e. represented by a single character: -, d
or l)
 The remaining three groups of three bits set flags which indicate whether
a file can be read r, written to w or executed x by
 (i) the user who created them,
 (ii) the other users who are in the group the file is marked with, and
 (iii) any user at all.
 For example, the permission
 Type Owner Group Anyone
 d rwx r-x ---.
 tells us that the file is a directory, which can be read and written to by the owner,
can be read by others in its group, but not by anyone else.
 Note about directories. It is impossible to cd to a directory unless the x bit is set.
 That is, directories must be ‘executable’ in order to be accessible.
File access control
Chmod
 The chmod command changes the permission or mode of a file.
 Only the owner of the file or the superuser can change the permission.
Here are some examples:
 # make write-able for everyone
chmod a+w myfile
 # add the user (owner) ’execute’ flag for directory
chmod u+x mydir/
 # open all files for everyone
chmod 755 *
 This gives
 Read, write, and execute permissions to the owner of the file;
 Read and execute permissions to the group associated with a file;
 Read and execute permissions to the others
File access control
Making programs executable
 A Unix program is normally executed by typing its
pathname.
 If the x execute bit is not set on the file, this will generate a
‘permission denied’ error.
 To make a program executable for someone, you can use a
command like:
 chmod u+x filename
 This command would set execute permissions for the owner of the file;
 chmod ug+x filename
 would set execute permissions for the owner and for any users in the same
group as the file.
File access control
chown and chgrp
 These two commands change the ownership and the group
ownership of a file. For example:
 chown mark ~mark/testfile
 chgrp www ~mark/www/tmp/[Link]
 In newer implementations of chown, we can change both
owner and group attributes simultaneously, by using a dot
notation:
 chown [Link] ~mark/www/tmp/[Link]
 Only the superuser can change the ownership of a file.
 This is to prevent users from being able to defeat quota
mechanisms.
Windows file model
 The Windows operating system supports a variety of legacy
filesystems for backward compatibility with DOS and
Windows 9x.
 These older filesystems are insecure, in the sense that they
have no mechanisms for restricting access to files.
 The filesystem NTFS was introduced with NT in order to
solve this problem.
 NTFS, like the Unix file system, is a hierarchical file system
with files and directories.
 Each file or directory has an owner, but no group membership.
 Files do not have a set of default permission bits, as does
Unix; instead they all have ACLs, which assign a set of
permission bits to a specific user.
Windows file model
Access control lists
 Windows files and directories have the following attributes.
 Access control lists are composed of access control entries
(ACEs) which consist of:

 Access control lists, or Access control entries are set and


checked with either the Windows Explorer program
File/Properties/Security/Permissions menu) or the cacls
command.
Ethics and Responsibilities
 Administrators have a responsibility to care for health
and well-being of users.
 Ultimately, happy users will cooperate well
 Ergonomic standards protect user health
 Etiquette – Dealing with user politely to minimise
offence and maximise harmony
 Ethics – Power must be wielded wisely or it will be
denied (or circumvented!)
See SAGE code of ethics at
[Link]
End of Chapter 2

You might also like