11. Which two commands are typically used to modify ownership and permissions on
an inode?
12. What does it mean when an executable has its SetUID flag enabled? 13. What makes a daemon different than a normal executable in Unix?
Answers
1.
Unix was originally designed not to include rigorous security in order to solve problems that didn’t require high level security.
2.
ATT gave UNIX away in the beginning, because their monopoly agreement with the U.S. government prevented them from selling software.
3. ATT essentially lost control of its development of Unix when they gave it away to
Universities in the 1970’s. They also licensed it to numerous hardware developers who modified it as they saw fit. Finally, hackers created their own version using the Internet,
and the result is a variety of variations.
4.
The file system represents and controls every system object in Unix.
5. File system permissions are the primary security mechanism in Unix.
6. File inodes store permissions in Unix.
7.
Unix user account information is stored in the etcpasswd file.
8.
Permissions are not checked for the root user in Unix.
9. The GID of the wheel or superuser group is 0.
10. Read, Write, and Execute are the basic permissions that can be set in an inode.
11.
Typically, the chmod and chown commands are used to modify ownership and permissions on an inode.
12.
Having an executable’s SetUID flag enabled means that it runs under the user account context of the file’s owner rather than the logged on user that executes it.
13. Nothing. Daemons are standard executables that run using SetUID permissions.
Terms to Know
•
block devices
•
BSD Berkeley Software Distribution
•
character devices
•
daemon
•
directory
•
distributions
•
file
•
hard links
•
IO port
•
inode index node
•
mount
•
Multics
•
owner
•
partition
•
pipe
•
process
•
root
•
shadow passwords
•
shell
•
socket
•
User Identifier UID
Chapter 12: Unix Network Security
This chapter covers the major contemporary Unix network security mechanisms. There are a number of obsolete Unix protocols and security mechanisms that are not discussed here
because they are no longer used—either because better alternatives exist now or because their security was weak and is now considered compromised.
This chapter provides an overview of the basic network security mechanisms available to Unix including their relative merits, security posture, and administrative difficulty. It’s not
possible to cover the configuration or administration of these protocols in a single chapter, but pointers to other resources for configuring them are provided.
Unix Network Security Basics
Standard Unix ATT System V does not include facilities to implement either single- signon one password and user account in the network or pervasive network security.
Security accounts are only valid on individual machines, machines do not “trust”
other machine’s accounts per se, and every network service implements its own security
mechanisms. Unix security is similar to Windows “Workgroup” mode security in this respect, where trust amongst machines does not exist.
Also consider that no true universal network file system exists in Unix. While Windows has had “Windows networking” since its inception to allow for file and print sharing, Unix did not
have anything that could be called a standard file sharing mechanism until the early nineties, when NFS became the de facto file sharing standard. Prior to that, FTP was the closest thing
to a file sharing standard, but it only allowed for copying files, not mounting and using them remotely.
Without a standard network file sharing mechanism, there was little point in having a single network logon—traversing machines wasn’t that much of an issue. But as networks of single-
user computers became popular in the late 1980’s, Unix began to show its age.
Of course, numerous solutions to these problems have cropped up in the 30 years since Unix was developed. Originally, network access simply meant connecting to a Unix machine using
a terminal application and logging in using a local user account. This method is still used by telnet, remote shell, secure shell, and numerous other remote logon protocols.
remote logon
The process of logging on to a remote machine in order to execute software on it. When Sun developed the
Network File System and Network Information System, they
simply adapted Unix security to a network environment. In these situations, all machines share a central account database, but they log on locally using these accounts. Because UIDs
are synonymous throughout the network supposedly, this mechanism was relatively
Kategori