RobotnixAcademy

Week 02 · overview

Week 2: Systems, Users, Processes, and Services

Last week you defined the authorized boundary and learned to separate evidence from inference.

Now we move inside the machine.

A computer that looks like one box is actually a collection of identities, processes, services, files, sockets, and resources interacting under different permissions. When something fails—or when a defensive control is too broad—you need to know which identity is doing which work, through which process, against which resource.

That is the Week 2 model.

The relationship to trace

USER / SERVICE IDENTITY
        ↓
PROCESS
        ↓
SERVICE FUNCTION
        ↓
FILE / SOCKET / OTHER RESOURCE
        ↓
EVIDENCE

Do not collapse those layers into one sentence such as “the server did it.” A server can host many processes. A process can run under a specific account. A service can be healthy while one worker process is not. A process can be listening locally without being reachable from another network.

This week

Lesson 1 — Who Is Doing What?

Build a model of users, service accounts, processes, privileges, and resources. Use a synthetic process inventory to trace responsibility instead of memorizing process names.

Lesson 2 — Process and Service State Are Evidence

Read process, service, log, and listening-socket evidence as different views of the same system. Learn what each view can—and cannot—prove.

Lesson 3 — Least Privilege Is a Relationship

Inspect a fictional service that runs with more privilege than its job requires. Design a narrower service identity and prove that the required function still works after the boundary changes.

Reflection — Trace the Responsibility Chain

Explain one Week 2 finding from identity through resource and name the evidence gap that remains.

Week 2 artifact

Create a Service Responsibility Map with:

  • identity;
  • process;
  • service purpose;
  • resources needed;
  • resources not needed;
  • observed evidence;
  • proposed least-privilege boundary; and
  • retest evidence.

You are not trying to memorize Linux administration this week. You are learning how to ask a systems question that security depends on:

Who is allowed to do what, through which running component, and how would we prove it?