To become familiar with groups and some security aspects of the UNIX system.

Security plays an important part in the usage of an operating system. The ability to allow and deny acceptable parties access to information sets up an important hierarchy that is vital to any multi-user system.

Earlier in our journeys, you discovered there were directories on the system that you could not access (namely /root), and yet others that you had limited access (/lost+found).

Let's examine /root:

lab46:~$ ls -ld /root
drwx------   9 root root   4096 Nov 19 17:07 root
lab46:~$ 

• The octal permissions for this directory are: 700
• The owner of the directory is: root
• The owning group of the directory is: root

That means the owner of the directory (root), has permission to read, write, and execute/search.

The group and anyone else on the system has no permissions whatsoever. So when you (as a regular and non-root user), try to change into the /root directory, you get the message:

lab46:~$ cd /root 
-bash: cd: /root: Permission denied
lab46:~$ 

Being a multi-user system, wouldn't it be troublesome if everyone had the same amount of access to the machine? A disgruntled user could delete another user's files, or any sort of evil task.

Thankfully, UNIX uses a hierarchy to separate the powers of system-level and user-level access. There is a priviledged, or Super User, account, and then there are regular users.

So for those who do not already know: root is the Super User on the system. That user has complete control over the resources available through the operating system. This is why the administrator of a system possesses this account.

The UNIX filesystem also provides a means of permissions, as we've seen in prior labs. The distinction of user, group, and other provides three different tiers of access.

This is a big reason why viruses are generally non-existant on UNIX- if a regular user gets “infected” with a malicious program, it can only infect the files owned by that user. So long as root doesn't get infected the problem remains generally restricted.

root is not a Super User just because of its name. UNIX relies on a numeric value that represents the user- the operating system simply translates the number into a name so that you don't have to deal with a number.

These numbers are the User ID (UID) and Group ID (GID). In the same fashion as the PID (Process ID) for running processes on the system, the operating system deals with numbers.

The /etc/passwd file contains all the crucial information for determining this information. It is a central file that houses all the user configuration information* for a UNIX system.

A typical line out of the /etc/passwd files is as follows:

username:x:1234:1234:Joe User,,,:/home/students/username:/bin/bash

Each field is delimited by a colon (:). The fields are designated as follows:

1. username - what you log in with.
2. password - encrypted password or “x” (to indicate another scheme)
3. User ID - numeric value representing your user
4. Group ID - numeric value representing the primary group you are a part of
5. GECOS - contains information such as real name, office, phone number, etc.
6. home directory - the directory where your login session starts
7. shell - the default shell

When you create a file on a UNIX system, it creates a file with full permissions:

• For regular files: -rw-rw-rw- (octal = 666)
• For directories: drwxrwxrwx (octal = 777)

This would pose a problem if left unchecked– forgetful users would have files accessible (both readable and writable) to anyone else on the system. This would not be a desirable thing at all.

Luckily, there exists a mechanism to take care of this. It is known as the un-mask, or umask.

umask takes away permissions from the default file mask. Its actual operation can be explained with binary logic. You take the umask value, invert it, then proceed to AND it with the file mask:

1. file mask: 666 → 110 110 110
2. umask of: 022 → 000 010 010 (remember this is octal, so 3 bits per octal digit)
3. invert 022: 000 010 010 → 111 101 101

apply the umask to the file mask by a Bitwise-AND:

       110 110 110 
 AND   111 101 101
       ----------- 
       110 100 100

Remember that with an AND, both values must be TRUE (or 1) for the result to be 1.

The final result: 110 100 100 = 644. This same result can be obtained by subtracting the umask from the file mask:

  666 
- 022 
  ---
  644

So from that point on (for the duration of your login session), all new files created will have 644 permissions. The subtraction trick works so long as you take directories into consideration.

Directories will have a default mask of 777. This is identical to that of regular files, except that regular files do not get their execute bit set by default. So you can do all umask operations with 777 and just drop any execute bits if dealing with ordinary files.

In the past, the telnet program was amongst the most common of methods used to connect to UNIX systems if a direct terminal connection was unavailable (rlogin was another common method). While this program is functional, the protocol that empowers it has one major drawback– it transmits ALL information in plain text. (This includes your password). An evil individual may be sitting out on the internet (at some point between you and the UNIX machine) using a Packet Sniffer to analyze each and every network packet you send. The packets can be reconstructed by a third party an to obtain an exact copy of everything you type and see.

Encryption provides a means of sending data securely through an unsecure medium. Secure Shell (or SSH), was developed as a replacement for telnet- providing similar functionality with several added features– the main one being security.

When you use SSH to connect to a system, all your information is encrypted. A malicious third party does not have immediate access to the data you are sending, providing an extra buffer of security both to yourself and the system.

Be sure to always use Secure Shell for any interactions you have with UNIX machines. You are not only protecting yourself and your data, but you are protecting the security of the system you are logging into.

Although UNIX/Linux systems have not been prone to the virus problem (although proof of concept viruses have been written) that afflicts other operating systems, it is certainly susceptible to trojan horses and worms– the trick is, these malicious programs can only be run under the authority of the user they've managed to infiltrate.

It is for reasons like this why it is critical you use strong passwords (8+ characters), connect using secure means (SSH), consider using key-based authentication, and if you're the administrator, lock down the root account as much as possible- the more you minimize root accessibility and usage, the more difficult it will be for your machine to be “rooted”.

A common practice is to disable remote root logins via SSH, so that only authorized users can connect. Attempts to log in directly as root over the network, even if you know the right password, will automatically fail.

Of course, with every benefit comes a drawback- if you disable remote root logins, the administrator cannot directly log in, even for legitimate means, if they do not have easy access to the main login console.

In addition to intentionally malicious programs, there are other vectors of attack that are hunted for and used. Vulnerabilities, or exploits, are the common names given to these kind of attacks.

A vulnerability or exploit is when an attacker takes advantage of a weakness or flaw in an existing and perceived legitimate program or facility. A successful attack can yield access in various forms where the attacker may not normally be privy to such authorization.

Common attacks:

• local root exploit: generally quite severe- typically a user who is logged onto the system can run a specially crafted program (built legitimately using available tools) that when run will take advantage of a weakness yielding a root-level shell.
• remote root exploit: typically the most severe- by means of sending uniquely crafted communications to a system over a network, root access (a shell, or a means of executing commands that are run as root) is gained. This is quite problematic as anyone, including users who do not have accounts on your system, can take advantage of this “hole”.
• denial of service: isn't typically intended to gain access to a system as much as it is to deny access- the purpose behind a DoS attack is to take a resource off-line by overwhelming it.
• buffer/stack overflow: through improperly designed program logic, a program may not do the appropriate checks to verify it can handle all the information it receives. In such cases, intentional input can be given which starts to write to memory that could have the purpose of overwriting the program, causing an intentional alteration in behavior, which could be used as a means of providing a shell or doing file manipulation. Depending on the program being exploited in this fashion, a buffer overflow could lead to a root privilege escalation.
• race condition: in a scenario where multiple facilities are sharing resources or using temporary files to store data, a race condition is the creation of an unexpected and sometimes unpredictable behavior.
• brute force: to gain access to a system, a valid username and password combination must be given. A brute force attack attempts to gain access by trying every possible combination of values for a password for a user account, root, or commonly assumed accounts (like “Admin”).

The UNIX permission hierarchy consists of three tiers: The user that owns a file, the group that is associated with the file, and the access the rest of the world (other) has to the file.

The user and other levels have seen extensive exposure. And they probably make the most sense– every file has an owner, and you have to determine what permissions the owner should have to its file, and what kind of access you wish the rest of the world to have on the file.

But what about group? This level is frequently overlooked, but we must be careful to consider any implications and capabilities it provides. It has its roots in project/teamwork ideas during the development of UNIX. A group essentially lets a team of people working on a project to have common access to important files that need to be shared among several people.

The group ownership of a file can be changed with the chgrp(1) utility. It can be used to change the ownership to any other group that your account is a member.

The /etc/group file defines all the groups and their members on a UNIX system. If you have a local account, searching for your username in this file you can determine what groups you are a part of.

The groups(1) utility can also be used to report the groups you to which you have membership.

This assignment has activities which you should tend to. While there is no formal submission required, it would be prudent to document some of the knowledge and experience gained on your Opus.

As always, the class mailing list and class IRC channel are available for assistance, but not answers.