Filesystem Permissions

Hackero Next Aug 23, 2024

As mentioned in previous posts, Hackero now includes support for filesystem permissions. In this post, I’ll provide a brief explanation of how these permissions work and what they are used for.

Understanding Permissions

Permissions are closely tied to system users, which are discussed in detail here

Each directory can be assigned an owner, typically a system user, who controls access to the directory.

In addition to ownership, each directory can have permissions set for two actions: reading (viewing the content) and writing (modifying the content). These permissions are enforced based on the directory’s owner.

Permission Read (r) Write (w)
Owner (o) Only Owner can read content Only Owner can modify content
Everyone (e) Every user can read content Every user can modify content

For example, assigning a directory "write" permission for the owner and "read" permission for everyone else allows only the owner to modify files, while others can only view them, as you might have already guessed.

Permissions are also applied recursively. This means that the permissions set on a higher-level directory will determine whether its subdirectories can be accessed.

/
/foo (e/e)
/foo/bar(o/o)
/foo/bar/baz(e/e)

Permissions are in (r/w) format

In the example above, even if the directory /foo/bar/baz is set to allow everyone access, only the owner can read and write to it if the parent directory’s permissions restrict access to the owner. Since permissions are inherited from parent directories, the owner’s restrictions on higher-level directories, such as /foo/bar, will apply to subdirectories as well.

However, the root user bypasses all these restrictions and has complete access to the entire filesystem. Gaining root access essentially grants you the ability to explore and modify every directory, regardless of its set permissions.

How This Relates to Gameplay

Hacking a process on a system no longer automatically grants you root access. Instead, you obtain the credentials of the user running that process. This makes the configuration of each process critical to your success.

Process owned by system user spacecow

Even if you don’t gain root access immediately after exploiting a process, it’s still worth investigating the filesystem. You might uncover valuable information or even discover ways to escalate your permissions and eventually gain root access.

This approach introduces more strategic decision-making when setting up defenses. You have greater control over how to protect your system. Using non-root users for processes is highly recommended, and ensuring those users don’t have full access to sensitive files is even more crucial.

That’s all for now—more details will be shared soon!

Tags