Inspect Files, Processes, and Permissions

Once you can move through a Linux filesystem, the next step is learning how to inspect system state without changing it blindly.

A defender often begins with three questions:

1. What files are here?
2. What is running?
3. Who is allowed to do what?

Those questions connect directly to confidentiality, integrity, and availability.

File metadata tells a story

A detailed listing can show more than a filename.

Example:

$ ls -l
-rw-r----- 1 student analysts 842 Sep 10 09:14 login-events.txt
-rwxr-xr-x 1 student analysts 218 Sep 10 08:55 collect-status.sh

Read the first permission string:

-rw-r-----

The first character identifies the object type in this simplified example. The remaining positions show permissions for:

• owner
• group
• others

Common permission letters are:

• r = read
• w = write
• x = execute

For login-events.txt, the owner can read and write. The group can read. Others have no listed permissions.

You do not need to memorize every Linux permission feature today. You do need to recognize that access is encoded into the filesystem.

Permissions are security controls

Suppose a log contains fictional account events.

If every user can modify it, integrity is weak.

If every user can read sensitive data inside it, confidentiality may be weak.

If nobody who needs the file can read it, availability is affected.

A permission choice can influence all three parts of the CIA Triad.

Read process state

Programs that are currently executing appear as processes.

Teacher-approved inspection commands may include:

ps
ps aux

A synthetic process listing might show:

USER       PID  COMMAND
student   1204  bash
student   1277  python3 status_monitor.py
root       611  sshd

What does that prove?

It shows the processes present in the supplied snapshot.

It does not automatically prove that a process is safe or malicious.

A suspicious-looking name can be legitimate. A normal-looking name can be misleading. Process names are evidence, not verdicts.

Inspect before escalating

Use this fictional situation:

A student reports that the lab VM is "acting weird." A process named sync-helper appears in the supplied process list.

Weak response:

Kill it. It sounds suspicious.

Stronger response:

Record the process ID, user, command path, start context, and any teacher-provided logs before deciding what action is justified.

Why?

Because deleting the process can destroy useful evidence and may break a legitimate service.

Search within text

The grep command searches text for a pattern.

Basic example:

grep "FAILED" login-events.txt

If the lab log contains:

09:02 LOGIN SUCCESS user=alex
09:04 LOGIN FAILED user=guest
09:05 LOGIN FAILED user=guest
09:08 LOGIN SUCCESS user=maria

then the command can filter the failed events.

This is more useful than manually scanning hundreds of lines.

Week 13 will return to grep and more advanced CLI work. For now, the goal is to understand filtering as evidence reduction.

Search does not equal analysis

Suppose you run:

grep "FAILED" login-events.txt

and get 25 results.

You can conclude that the supplied log contains 25 matching lines.

You cannot automatically conclude:

• there were 25 attackers
• the account was compromised
• the password was guessed
• the failures came from outside the organization

You need context.

Lab: build a system snapshot

Use the teacher-provided terminal environment.

Create a System Snapshot with these sections.

Location

Record:

pwd

Files

Use a detailed listing for the supplied evidence directory.

Record:

• filenames
• sizes
• timestamps
• permissions

Processes

Inspect the supplied process state.

Choose three processes and record:

• user
• process ID
• command name
• whether you have enough evidence to classify the process

Log filter

Use grep on a teacher-provided log to find one approved pattern such as:

• FAILED
• ERROR
• DENIED

Record the command and the number of matching lines.

Permission reasoning challenge

Use these fictional requirements:

File A: class-notes.txt

All students may read it. Only the teacher should modify it.

File B: private-feedback.txt

Only the individual student and teacher should read it.

File C: lab-tool.sh

Students may execute the approved script but should not edit the master copy.

For each file, explain the desired access in plain language.

Do not jump straight to a numeric chmod value unless your teacher asks. First prove that you understand the security requirement.

Evidence preservation

A defender should know when not to modify a system.

If you are collecting evidence from a supplied lab scenario, changing file timestamps, deleting processes, or editing logs can make later analysis harder.

Use this rule:

Observe first. Record what you saw. Change state only when the exercise authorizes a change.

Build an analyst note

Write a short note using this structure:

Observation

What command did you run, and what did it return?

Interpretation

What might the result mean?

Limitation

What does the result not prove?

Next safe action

What additional evidence would help?

Use one file-permission observation, one process observation, and one log-search observation.

Evidence for Lesson 2

Submit:

• System Snapshot
• three permission-requirement explanations
• three analyst notes

Finish with:

The command that gave me the most information without changing system state was ________ because ________.

Good command-line work is not typing quickly. It is using small, explainable observations to build a reliable picture of the system.