Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS1730 UNIX/Linux Fundamentals</fs></WRAP>
<fs 125%>Lab 0xD: Groups and Security</fs>
</WRAP>

~~TOC~~

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

=====Security=====
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**:

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

  * 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:

<cli>
lab46:~$ cd /root 
-bash: cd: /root: Permission denied
lab46:~$ 
</cli>

====UNIX user hierarchy====

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. 

<WRAP round info box>**__NOTE__**: Traditionally, the encrypted user passwords were also stored in this file. Over time, however, it was realized that this was generally a bad idea, and alternative schemes were developed. One common scheme is what are known as **Shadow Passwords**, where the encrypted password is stored in **/etc/shadow**, and that file is inaccessible to non-priviledged users.</WRAP>

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

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

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

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

^  1.  ^|Locate the following information:|
| ^  a.|What are the permissions on your home directory? Show me how you found this.|
|:::^  b.|What is your User ID (UID)? How did you determine this?|
|:::^  c.|What is your Group ID (GID)? Show me how you found this.|
|:::^  d.|What is the name of the default Super User/Administrator account on the system?|
|:::^  e.|What is that user's UID and GID? How did you find this?|

====Default file permissions: umask====

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:

  - file mask: 666 -> **110 110 110**
  - umask of: 022 -> **000 010 010**  (remember this is octal, so 3 bits per octal digit) 
  - invert 022: 000 010 010 -> **111 101 101**

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

<code>
       110 110 110 
 AND   111 101 101
       ----------- 
       110 100 100
</code>
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:

<code>
  666 
- 022 
  ---
  644
</code>

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.

^  2.  ^|Playing with **umask**:|
| ^  a.|What is your current **umask**? How did you determine this?|
|:::^  b.|Using **touch**(**1**), create a new file. Do its resultant permissions correlate with your **umask**?|
|:::^  c.|Unset your **umask** with a value of **000**. Create a new file. What are the permissions? Do that correlate with your **umask**?|
|:::^  d.|Derive and set a **umask** to give you **640** files by default. What value did you use?|

^  3.  ^|Perform the following **umask** calculations and show me how you arrived at your answer:|
| ^  a.|Show me a **077** **umask** via **Bitwise-AND** (you can assume a directory)|
|:::^  b.|Show me a **777** **umask** via **Bitwise-AND**. What is the resulting permission?|
|:::^  c.|Show me a **226** **umask** via **Subtraction**|
|:::^  d.|Show me a **074** **umask** via **Subtraction** (you can assume a directory)|

====Secure Shell====
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.

====Viruses/Trojans/Worms, Oh My!====
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"). 

=====Groups=====
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.

^  4.  ^|Locate the following information:|
| ^  a.|Determine what groups your account has membership. Tell me what they are.|
|:::^  b.|What are the GID's of each group you are a member? How did you find this information?|

^  5.  ^|Change to the groups/ subdirectory of the UNIX Public Directory. Do the following:|
| ^  a.|List the directory. What files are there? What are the permissions?|
|:::^  b.|What groups own what directories? Are you a member of any of the groups?|
|:::^  c.|In the various directories are files containing Secret Codes. Obtain this from as many of the directories as you can and report them to me.|
|:::^  d.|What directories/files couldn't you get into? Why?|

=====Conclusions=====
This assignment has activities which you should tend to- document/summarize knowledge learned on your Opus.

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

User Tools

Site Tools

Page Tools
