Server security / Stage 8 of 10 · step 4 of 5

The service is denied access

~20 min

Not running Starting usually ~20 s

Situation

The intranet knowledge base — the lab-kb service, the kb-server application — moved to a new disk last week: the articles were moved from /var/lib/kb to /srv/kb, and the path in /etc/kb-server/kb.conf was updated. Since then the knowledge base does not open:

curl -s http://127.0.0.1:8098/

A colleague has already checked the permissions: directories 755, files 644. The service user can read an article — sudo -u kb cat /srv/kb/howto/vpn.md. Next to it on the same disk lies /srv/hr — exports of the HR department.

Task

lab-kb serves the main page with the list of articles and the articles themselves from /srv/kb, new ones included. The application code and the article path in the settings stay the same.
Do not weaken the protection of the service: the process runs under its AppArmor profile kb-server in enforce mode.
The service gets only read access to /srv/kb. It still cannot write there or read /srv/hr and /etc/shadow.
Do not edit the packaged profile file /etc/apparmor.d/usr.local.bin.kb-server — a package upgrade replaces it. Keep your rules in /etc/apparmor.d/local/usr.local.bin.kb-server: the fix has to work after the profile is loaded from disk as well.

There is no internet on the machine; everything you need is already installed. Run administrative commands with sudo.

Lab goals

0 of 4

lab-kb serves the main page and the articles from /srv/kb, new ones included; the application code and the article path are unchanged — not checked yet
The service process runs under the kb-server profile in enforce mode — not checked yet
The profile gives the service only read access to /srv/kb — /srv/hr, /etc/shadow and writing to /srv/kb stay closed to it — not checked yet
Your rules are in /etc/apparmor.d/local, the packaged profile file is unchanged; after the profile is loaded from disk the service works — not checked yet

Hints

0 of 3 open · they open one at a time

Hint 1

Show the solution after 3 failed checks

Security · picked for this lab

AppArmor

Cheat sheet

$_ — insert into the terminal

sudo aa-status profiles and modes
journalctl -k | grep -i 'apparmor.*denied' what is being blocked
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx log only
sudo aa-logprof extend a profile from the logs
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx block again
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx reload

Modes and commands

Profiles live in /etc/apparmor.d/. Two modes:

enforce — violations are blocked;
complain — only logged (for debugging/rollout).

bash

sudo aa-status                                    # overview
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx   # → complain
sudo aa-enforce  /etc/apparmor.d/usr.sbin.nginx   # back to enforce
sudo aa-disable  /etc/apparmor.d/usr.sbin.nginx   # disable the profile
sudo apparmor_parser -r /etc/apparmor.d/profile   # reload
sudo apparmor_parser -R /etc/apparmor.d/profile   # unload a profile
sudo systemctl reload apparmor

The apparmor-utils package provides the aa-* helpers; without it, only apparmor_parser is available.

Profiles and rollout

A profile's structure (simplified): the path to the binary plus access rules (capabilities, paths with r/w/ix), plus #include <abstractions/...> and #include <tunables/...>.

Semi-automatic tuning of a profile against real behavior:

bash

sudo aa-genprof /usr/bin/myapp    # profile from a test run
sudo aa-logprof                   # rules from denial logs

A typical cycle: aa-complain → run the workload → aa-logprof (accept the generated permissions) → aa-enforce.

"Permission denied" even though the permissions (rwx) look right

AppArmor is blocking it. Check the denials:

bash

sudo journalctl -k | grep -i 'apparmor.*denied'
sudo dmesg | grep -i 'apparmor.*DENIED'

A line like DENIED ... operation="open" ... name="/path" shows what the profile did not allow.

The service works, but cannot access a new directory

The profile does not allow that path. For debugging, use aa-complain, run the workload, then aa-logprof will extend the profile, followed by aa-enforce.

The profile is not reread after an edit

sudo apparmor_parser -r <profile> (or reload apparmor). A syntax error will be shown by the parser.

I want to temporarily disable it for one service

sudo aa-complain <profile> (soft) or aa-disable. Turning AppArmor off entirely in production is not a good idea — it is a real loss of protection.

A snap app and AppArmor

Snap uses its own profiles (confinement); denials are also visible in journalctl -k (see snap snap connections).

The service is denied access

Situation

Task

Signing in is needed to start the machine

Modes and commands

Profiles and rollout

"Permission denied" even though the permissions (rwx) look right

The service works, but cannot access a new directory

The profile is not reread after an edit

I want to temporarily disable it for one service

A snap app and AppArmor