TryHackMe: Operating Systems — Introduction — Learning Notes

These are my personal learning notes as I work through TryHackMe — honest notes, not an authoritative guide. Corrections welcome.

On sources & TryHackMe’s material: These are independent learning notes in my own words. They describe my experience of the room and deliberately reproduce none of TryHackMe’s room text, task content, screenshots, flags, or answers — go do the room to get those. Room names and the linked URL are used for reference only. TryHackMe and its content are the property of TryHackMe Ltd; this post is not affiliated with, authorised by, or endorsed by them.

Overview

• Room: Operating Systems: Introduction — link
• Difficulty: Info / Easy
• What it teaches: What an operating system does beneath the surface — resource coordination, the privilege boundary between the kernel and ordinary applications, the OS’s core duties, and the main OS families you’ll meet in the real world.

This is where the “computer fundamentals” thread moves from parts you can hold to the invisible layer that governs them. It’s also the first room in the series to introduce a real privilege boundary inside software, which from a security point of view is the most important idea I’ve met so far.

The airport analogy

The room frames the computer as a busy airport, and the analogy holds up well enough to keep using:

• The hardware (CPU, RAM, storage) is the physical infrastructure — runways, planes, fuel, radar.
• The users and their applications are the airlines and passengers, all wanting something at once.
• The operating system is air-traffic control.

The point the analogy makes is about conflict. Every airline wants a runway now, but runways are finite, so someone has to schedule turns. If every plane tried to take off at once, the result is a crash, not a busy airport. The control tower exists so limited resources get shared without chaos. That’s the OS’s job: many demands, finite hardware, one coordinator deciding who gets what and when.

Without an OS, every application would reach for the CPU, memory and devices directly, and they’d collide constantly. The OS is what makes “everything just works” possible — and “just works” is a lot of arbitration happening out of sight.

New to me: privilege layers

This is the concept I’d never had a name for, and the one that matters most.

Inside the OS there’s a deliberate separation of privilege:

• Kernel space — the privileged core. The kernel talks to the hardware directly: unrestricted access to CPU, memory, storage, devices.
• User space — where every normal application runs, walled off from the hardware. When an app wants to open a file, play a sound, or reach the network, it can’t do it directly. It makes a system call — a formal request to the kernel — and the kernel decides whether and how to carry it out.

In the airport terms: the kernel is the control tower, a locked room only trusted controllers enter. The airlines on the ground can’t walk into the tower or touch the radar; they radio their requests up, and the tower acts on them. One airline having a bad day can’t bring down the airport, because it was never allowed near the controls.

That last part is the security point. The boundary isn’t just tidy architecture — it’s containment. A faulty or malicious app in user space can’t directly wreck the system, because it never had direct access to begin with. This is isolation by design, before any security software is installed.

The OS’s core duties — remembered as installing and playing a game

The room lists the OS’s main responsibilities, and there are enough of them that I needed a way to make them stick. What worked was walking through one familiar sequence — installing and then playing a game — and noting each duty as it appears:

1. User management — I log in and authenticate, and I need admin rights to install anything. The OS decides who I am and what I’m allowed to do.
2. File system management — the installer places the game’s files into directories, with names, paths and permissions.
3. Process management — I run the installer; the OS creates a process for it (and later terminates it). Launching the game creates another process the OS schedules CPU time for.
4. Memory management — the game is graphics-heavy, so the OS allocates it RAM, keeps that RAM walled off from other apps, uses virtual memory (disk) if RAM runs short, and reclaims it all when I quit.
5. Device management — the OS loads the graphics and sound drivers so the game works as intended, without the game needing to know the hardware details.

The thing I want to remember is that every one of those steps has the same shape: the game, on my behalf, requests something of the OS; the OS checks it; and if it checks out, the OS does it. Install, save, run, allocate, print — all of it is request-and-approve. Once I saw that pattern, the list stopped being five separate facts and became one idea with five faces.

The OS is a security layer in its own right

The room makes a point worth holding onto: before any antivirus, firewall or security tool exists, the OS is already enforcing security. Several of the duties above are security controls when you look again:

• Authentication — proving who you are (the login step).
• Permissions — the OS controlling what each user and app may read, write or run (the approve/deny on every request).
• Isolation — keeping each process in its own box. (A correction to my own first guess here: there are two different walls, and it’s worth not confusing them. The kernel/user-space split is the privilege boundary — who may touch hardware. Process isolation is memory management keeping one app’s RAM out of another app’s reach. Same instinct — walls — but two separate walls doing two separate jobs.)
• System protection — guarding critical system files and settings from unauthorised change.

So authentication, permissions and isolation aren’t things you bolt onto an OS. They’re things the OS already is.

Connects to my bigger goal

Two connections — one across my earlier posts, one toward the security work I’m building.

First, this room is the middle piece of a stack I’ve been assembling. Two rooms ago (“Inside a Computer System”) I ended on a question: firmware runs below the OS, so a bootkit can sit underneath the OS entirely. This room supplies the other half. The stack, in order:

• Firmware sits below the OS (runs before it, hands control to it).
• The kernel is the privileged core of the OS.
• User space sits above the kernel — where the applications live, including the antivirus and security tools.

Line those up and the danger from the first post has a clear shape. Your security software runs in user space. It depends on the kernel beneath it, which depends on the firmware beneath that. Anything that establishes itself below the layer your defences run in is looking down on them. That’s why “below the OS” was worth flagging, and it took three rooms to be able to say it properly.

Second, the OS duties are a map of where attacks happen. Categorising what the OS does also categorises the ways it can be abused:

• Going through the Security+ material a while back, I remember malware that exploits memory, which maps to memory management. The OS deciding how RAM is allocated and isolated is exactly the machinery such attacks target.
• From my own experience, running as a non-admin user limits the damage a lot of simpler malware can do, which maps to user management and permissions. I’d put this carefully, though: a non-admin account raises the wall, it doesn’t guarantee containment. Plenty of malware runs fine at user-level privilege, and privilege-escalation exploits exist to climb that wall. So it’s a real and worthwhile mitigation, not a force field. (Overstating what a control guarantees is its own kind of mistake.)

The same three duties — user management, permissions, isolation — are the raw material under the access-control ideas I keep meeting in compliance work: least privilege, authentication, segregation of duties. Those frameworks aren’t inventing new mechanisms; they’re insisting you use the ones the OS already provides. Seeing the mechanism first makes the rule read less like bureaucracy and more like a reminder.

Where I got stuck / have to revisit

Not stuck, but this is the first room I know I’ll need to reread, because of the number of responsibilities the OS carries. The game-installation walkthrough is my scaffold for now, but the formal terms inside that story — authentication, permissions, isolation, system protection — are ones I want to pin down individually rather than by anecdote.

The room also has a hands-on lab (investigating a “mystery” second-hand computer). I’m not writing up what it contains — go poke at it yourself — but using the OS to interrogate its own hardware and file system was a good practical echo of everything above.

Revisit

• System calls — the request-and-approve pattern is the heart of it; I want to see what a system call actually looks like up close.
• Kernel-level vs user-level attacks — now that I can see the privilege line, the next question is what changes for an attacker on the wrong side of it, and how they try to cross.
• The formal security terms, pinned down one by one rather than as a story about installing a game.

Lessons Learned

• The privilege boundary is the big idea: kernel space can touch hardware, user space must ask. That separation is containment by design.
• Every OS duty has the same shape — an application requesting something and the OS approving it — which is also a map of where things can be attacked.
• The OS is a security layer before any security tool exists: authentication, permissions, isolation and system protection are built in, not bolted on.
• The stack lines up: firmware below the OS, kernel at the core, security tools in user space — which is why something running below the kernel is so dangerous.

References

• The room’s guided tasks and static site on TryHackMe