# Lab4
To make this report as clear as possible, some output were store in files in the gitlab repository. When necessary, links to these files will be provided.

## Task 1: printenv, export and unset
The two commands presented were tested.
The output from `printenv` can be checked [here](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task1.txt).

## Task 2: fork()
### Step 1
The output printed by the `myprintenv.c` when it's the __parent__ process can be checked [here](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task2/output_myprintenv_parent.txt).
### Step 2
The output printed by the `myprintenv.c` when it's the __child__ process can be checked [here](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task2/output_myprintenv_child.txt).
### Step 3
Applying the command `diff output_myprintenv_child.txt output_myprintenv_parent.txt` we verified that the child process inherits the environment variables from the parent. Which makes sense, since the child is a copy of the parent process, which contains the env variables.

## Task 3: execve()
### Step 1
In this step we have checked that it was not possible by the program to print the environment variables. The output was empty.
- [Output file](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task3/output_myenv_step1.txt)

### Step 2
In this second step we observed that the program printed the environment variables.
- [Output file](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task3/output_myenv_step2.txt)

### Step 3
We have concluded that, since the __execve__ is executed inside the current program process and overwrites the data, text, bss and stack of the calling program, the `environ` variable is lost. For this motive the program output in step 1 is empty.
Step 2, by another hand, guide us to parse these env variables to the `execve`, so it can be saved in the program resources and used.

## Task 4: system()
The information described in this task was verified.
- [Output file](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task4/system_call.txt)

## Task 5
For this exercise the following env variables were set:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:.
ANY_NAME=ANY_NAME
LD_LIBRARY_PATH=CRISTINA

### Step 3
We were expecting to see all the environment variables defined in the program output. However, the `LD_LIBRARY_PATH` could not be found and this was our surprise.
After a brief search we found out that `LB_LIBRARY_PATH` is a predefined path that tells the linker where to search for dynamic libraries. Since this path is searched before, a person could get an application to load a shared library that contains malicious code. That's one of the reasons that setuid/setgid executables neglect this variable.

- [Output file](https://git.fe.up.pt/fsi/fsi2122/m07g03/-/blob/main/src/week-4/task5/output_setuid.txt)

## Task 6
### How to execute the malicious program
Since the `ls` command doesn't explicit the complete command path, we can make a program called `ls` in our current path be executed.
First, we have created a `malicious.c` file in the same path of the program to be executed:

// malicious.c
#include<stdlib.h>
#include<stdio.h> 
#include<unistd.h>
int main(){
    if (geteuid() != 0){
        printf("Not root\n"); 
    } else printf("Im root\n");
}

And we have compiled the program is the following way:

gcc malicious.c -o ls

In order to this program run, we must add our current path to the $PATH environment variable:

export PATH=.:$PATH

Notice that the `.` path must come before the `/bin`, so that the system finds our malicious `ls` before the one in the `/bin` folder.

After making to the proposed c file a Set-UID program, we executed it.
If we are executing our program in `sh`, our malicious code is not running as a root, but if executing in `zsh` shell, we have root permissions.