Lab 4: Implementing Access Control and Debugging Refresher

Linux Extended ACLs

In lecture we discussed how UNIX systems tend to implement Access Control Lists to enable fine-grained access control beyond the default abbreviated ACL (permission bits) which are unable to express more complex per-user protection states.

In today’s lab, you will get the opportunity to work with Linux’s Extended ACLs to see how they can be used to implement fine-grained access control in a practical setting.

Linux Extended ACLs are generally not installed by default and require file system support to enable; however, once they are available, each file and directory’s ACL can be read using getfacl and modified using setfacl.

Refer to the lecture notes again to review the behavior of extended ACLs.

Some other useful links:

Glen Newell. An introduction to Linux Access Control Lists (ACLs). 2/6/2020. redhat.com
nawazadhandala. How to Use setfacl and getfacl for Extended ACL Permissions on Ubuntu. 3/2/2026. oneuptime.com
Andreas Gruenbacher. acl(5) - Linux man page. 3/32/2002. linux.die.net

Debugging Refresher

In the next unit, we will be getting into program security, and your labs will be about binary exploitation—finding and exploiting vulnerabilities like buffer overflows in programs by inspecting them at runtime and crafting a malicious input.

To prepare for that, we’ll be going through the “Debugging Refresher” so that you can familiarize yourself with gdb, the GNU Project Debugger, and its capabilities.

Make sure to read all the instructions on pwn.college as these provide helpful context and links to the documentation.

The challenges in this module are completed entirely within a debugger after they are initiated by invoking the embryogdb challenge script.

You might find these cheatsheets helpful for future reference as well:

Task 2

From the “Debugging Refresher” module:

Complete Debugging Programs

Hint 1

use r to start the challenge after running the script, and c to continue the challenge.
Complete Inspecting Registers

Hint 1

List of x86 CPU Registers
Complete Examining Memory

Hint 1

This one is tricky, as you are expected to read the disassembly of the currently running program in order to determine which value on the stack is the random number that was read from /dev/random.

Hint 2

Use the disassemble main command and continue disassembling until you find the call to the read function. This is the function used to read the random number.

Hint 3

Refer to the x86 Calling Convention to figure out which instruction is used to set the buf parameter in read. This should be a stack address and therefore likely related to either rsp (stack pointer) or rbp (stack base pointer).

Hint 4

Remember that you can use expressions like x/gx $rbp-0x32 to specify the address you want to examine.
Complete Setting Breakpoints

Hint 1

This one is basically the previous challenge repeated multiple times and without a built-in breakpoint.

You will need to set breakpoint(s) at addresses within the program, step instructions to a point(s) where you can print the random value on the stack, print it, copy it, continue execution to get to the program prompt, and paste the random value when prompted.

Rinse and repeat until the challenge gives you the flag.

Hint 2

Like the previous challenge, use disassemble main to get a clearer picture of what the program is doing.

Hint 3

Set a breakpoint at some point before and after the call to read, but before the scanf call that takes user input.

Hint 4

When you use display commands, the data you want to print will be printed whenever execution is stopped at a breakpoint.

Note: If you run display regs, you can use tui disable to go back to the regular mode.

Hint 5

If you pick the right thing to print and the right breakpoint location, you won’t need to keep typing it all out over and over :)