> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-14/linux/capabilities/privilege-escalation-linux-misconfiguration.md).

# Misconfiguration

## AppArmor Bypass via Pattern Mismatch

Examine the AppArmor profile active for your current shell (often located within `/etc/apparmord.d/`). Look specifically at path restriction rules (e.g., those using `deny` or specifying file permissions like `r`, `w`, `k`) that utilize pattern matching with wildcards like `/**` (recursive match) or `/*` (immediate child match).

AppArmor profiles use globbing for path matching, similar to shell wildcards but with specific behaviors. The `*` wildcard matches any sequence of characters *except* the directory separator `/`. The `**` wildcard, on the other hand, matches any sequence of characters *including* the directory separator `/`. It's important to note that `**` also matches the empty string at the end of a path component.

For example:

* `/foo/*` matches `/foo/bar` but not `/foo/bar/baz`. It grants access to files directly within `/foo`.
* `/foo/**` matches `/foo/`, `/foo/bar`, and `/foo/bar/baz`. It grants access to the directory `/foo` itself and everything within it recursively.
* `/var/log/** rwk,` grants read, write, and lock access to files and directories within `/var/log` and its subdirectories.

A frequent AppArmor bypass technique involves finding a pattern mismatch due to these wildcard behaviors. For instance, a profile might contain a rule like `deny /var/tmp/**`. While the administrator might intend this to restrict *all* access within `/var/tmp` and its subdirectories, the pattern `**` at the end of `/var/tmp/` matches the empty string, meaning the rule `deny /var/tmp/**` applies to paths *starting* after the `/var/tmp/` part. It does *not* inherently deny access to the `/var/tmp/` directory path itself. This allows actions such as writing files directly into `/var/tmp/`, even though access to `/var/tmp/some_subdirectory/` or `/var/tmp/some_file` might be correctly denied by the `**` matching the subsequent path components.

If you identify such a discrepancy where an action is permitted in the directory itself despite a pattern restricting its children, you can leverage this location. For example, with a rule like `deny /var/log/** w`, writing to anything *inside* `/var/log/` (like `/var/log/test.log`) is prevented, but writing directly to the directory itself (`/var/log/`) or creating files directly inside it (`/var/log/test`) might be allowed:

```bash
echo "test" > /var/log/test
```

Another common bypass arises from misunderstanding the `**` wildcard's behavior relative to path components. Consider a rule designed to prevent reading SSH private keys: `deny /home/**/.ssh/id_rsa r`. This rule intends to prevent reading `id_rsa` files located within any user's `.ssh` directory under `/home/`, such as `/home/user/.ssh/id_rsa`. However, depending on the exact path evaluation, the `**` wildcard might not match the `/` immediately preceding `.ssh/` in the path `/home/user/.ssh/id_rsa` when matched against `/home/**/.ssh/id_rsa`. This specific pattern `/**/` requires at least one directory level between the preceding and succeeding `/`. Thus, the rule might fail to match `/home/user/.ssh/id_rsa`, potentially allowing the file to be read:

```bash
cat /home/user/.ssh/id_rsa
```

Similarly, the single `*` wildcard only matches a single path component (i.e., no `/`). A rule like `deny /tmp/*` prevents access to immediate children of `/tmp`, such as `/tmp/file.txt`. However, it explicitly **allows access to files in subdirectories**, like `/tmp/dir/file.txt`, because the `*` does not match the `/` in `dir/`.

```bash
cat /tmp/dir/file.txt
```

Analyzing the specific wildcard usage and how AppArmor interprets these patterns against actual file paths is crucial for identifying potential path-based bypasses.