Page 304 - DCAP403_Operating System

Unit 13: Case Study: Linux

individual password that allows the access. Access to files is determined by the permissions that Notes

are set on the files and directories.

Access to various services such as printers or even local file systems is also determined by
permissions. In addition, some services, as we shall see shortly can be restricted at a much lower
level.
In some cases, passwords may be blank, meaning you only need to press enter. In other cases it
can be removed altogether so you are never even prompted to input your password. Removing
the password may not always be a good idea. Since you have the source code, Linux allows you
the option to prevent users from either having no password or having to just press return. Since
we are talking here about security and accounts without passwords are not very secure, we’ll
restrict ourselves to talking about accounts that have passwords.

On many systems (including many Linux versions) one cannot force users to use (or not use)

specific passwords. As a system administrator it is your responsibility to not only enforce a
strong password policy, but to educate your users as to why this is important. Later, we’ll go
over some examples of what happens when users are not aware of the issues involved with
password security.

Although this password protection stops most attempts to gain unauthorized access to the
system, many security issues involve users that already have accounts. Unchecked, curious users
could access payroll information and fi nd out what their boss gets paid. Corporate spies could
steal company secrets. Disgruntled workers could wreak havoc by destroying data or slowing
down the system.
Once logged in, Linux provides a means of limiting the access of “authorized” users. This is in
the form of fi le permissions, which we already talked about. File permissions are one aspect of
security that most people are familiar with in regard to UNIX security. In many cases, this is the
only kind of security other that user accounts.
Each file has an owner, whether or not some user explicitly went out there and “claimed”

ownership. Its a basic characteristic of each file and is imposed upon them by the operating

system. The owner of the file is stored, along with other information, in the inode table in the
form of a number. This number corresponds to the User ID (UID) number from /etc/password.

Normally, files are initially owned by the user who creates them. However, there are many
circumstances that would change the ownership. One of the obvious ways is that the ownership
is intentionally changed. Only the owner of the file and root can change its ownership. If you are

the owner of a file, you can, in essence, “transfer ownership” of the file to someone else. Once you

do, you are no longer the owner (obviously) and have no more control over that fi le.

Another characteristic of a file is its group. Like the owner, the file’s group is an intrinsic part of

that files characteristics. The file’s group is also stored in the inode as a number. The translation

from this number to the group name is made from the /etc/group file. As we talked about in the

section on users, the concept of a group has only real meaning in terms of security. That is, who
can access which fi les.
What this means is that only “authorized” users can access files in any of the three manners: read,

write and execute. It makes sense that normal users cannot run the fdisk utility, otherwise they
would have the ability to re-partition the hard disk, potentially destroying data. It also makes

sense that normal users do not have write permission on the/etc/password file, otherwise they
could change it so that they would have access to the root account. Since we talked about it in the
section on shell basics and on users, there is no need to go into more details here.
There is also access to the all powerful root account. On a Linux system root can do anything.
Although it is possible to restrict roots access to certain functions, a knowledgeable user with
root privileges can overcome that. There are many instances where you have several people
administering some aspect of the system, such as printers or the physical network.

LOVELY PROFESSIONAL UNIVERSITY 297