diff --git a/docs/development/structure.md b/docs/development/structure.md index 0e1c0659..44c6e6ea 100644 --- a/docs/development/structure.md +++ b/docs/development/structure.md @@ -174,73 +174,3 @@ The possible solutions are: * The easiest (and unfortunately less secure) workaround is to ensure the programs do not run with no new privileges flag by disabling `NoNewPrivileges` in the systemd unit (or any other [options implying it](https://man.archlinux.org/man/core/systemd/systemd.exec.5.en#SECURITY)). * Inherit the current confinement (`ix`) * [Stacking](https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorStacking) - - -## Full system policy - -!!! quote - - AppArmor is also capable of being used for full system policy - where processes are by default not running under the `unconfined` - profile. This might be useful for high security environments or - embedded systems. - - *Source: [AppArmor Wiki][apparmor-wiki]* - -### Enable - -!!! danger - - Full system policy is still under early development, do not run it outside a development VM! **You have been warned!!!** - -This feature is only enabled when the project is built with `make full`. [Early policy](https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorInSystemd#early-policy-loads) load must be enabled, in `/etc/apparmor/parser.conf` ensure you have: -``` -write-cache -cache-loc /etc/apparmor/earlypolicy/ -``` - -### Structure - -The profiles for full system policies are maintained in the **[`_full`][full]** group. - -**systemd** - -In addition to systemd services (`systemd-*`) that have their own profiles, systemd itself, is confined using: - -- [x] **`systemd`**: For systemd as PID 1, designed such as: - - It allows internal systemd access, - - It allows starting all common root services. -- [ ] **`systemd-user`**: For `systemd --user`, designed such as: - - It allows internal systemd user access, - - It allows starting all common user services. - -These profiles are only intended to confine themselves. Any services started by systemd must have their corresponding profile. It means that for a given distribution, the following services must have profiles: - -- [ ] For `systemd`: -```sh -/usr/lib/systemd/system-generators/* -/usr/lib/systemd/system-environment-generators/* -/usr/lib/systemd/system/*.service -``` - -- [ ] For `systemd-user` -```sh -/usr/lib/systemd/user-environment-generators/* -/usr/lib/systemd/user-generators/* -/usr/lib/systemd/user/*.service -``` - -To be allowed to run, additional root or user services may need to add extra rules inside the `usr/systemd.d` or `usr/systemd-user.d` directory. For example, when installing a new privileged service `foo` with [stacking](#no-new-privileges) you may need to add the following to `/etc/apparmor.d/usr/systemd.d/foo`: -``` - @{lib}/foo rPx -> systemd//&foo, - ... -``` - -**Fallback** - -!!! warning "Work in Progress" - -In addition to systemd profiles, a full system policy needs to ensure that no program run in an unconfined state at any time. When full policy mode is enabled, special fallback profiles `default` and `default-user` are used to ensure this. PAM rule can be used to configure it further. - -[apparmor-wiki]: https://gitlab.com/apparmor/apparmor/-/wikis/FullSystemPolicy -[full]: https://github.com/roddhjav/apparmor.d/blob/main/apparmor.d/groups/_full diff --git a/docs/full-system-policy.md b/docs/full-system-policy.md new file mode 100644 index 00000000..f234d8f3 --- /dev/null +++ b/docs/full-system-policy.md @@ -0,0 +1,118 @@ +--- +title: Full system policy +--- + +!!! danger + + Full system policy is still under early development: + + - Do not run it outside a development VM! + - This is an **advanced** feature, you should understand what you are doing + + **You have been warned!!!** + +!!! quote + + AppArmor is also capable of being used for full system policy where processes are by default not running under the `unconfined` profile. This might be useful for high security environments or embedded systems. + + *Source: [AppArmor Wiki][apparmor-wiki]* + + +## Install + + +This feature is only enabled when the project is built with `make full`. [Early policy](https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorInSystemd#early-policy-loads) load **must** also be enabled. + +In `/etc/apparmor/parser.conf` ensure you have: +``` +write-cache +cache-loc /etc/apparmor/earlypolicy/ +Optimize=compress-fast +``` + +**:material-arch: Archlinux** + +In `PKGBUILD`, replace `make` by `make full`: +```diff +- make ++ make full +``` + +**:material-ubuntu: Ubuntu & :material-debian: Debian** + +In `debian/rules`, add the following lines: + +```make +override_dh_auto_build: + make full +``` + +**:simple-suse: OpenSUSE** + +In `dists/apparmor.d.spec`, replace `%make_build` by `make full` +```diff +- %make_build ++ make full +``` + +**Partial install** + +Use the `make full` command to build instead of `make` + + + +## Structure + +The profiles dedicated for full system policies are maintained in the **[`_full`][full]** group. + +### Systemd + +In addition to systemd services (`systemd-*`) that have their own profiles, systemd itself, is confined using: + +- [x] **`systemd`**: For systemd as PID 1, designed such as: + - It allows internal systemd access, + - It allows starting all common root services. + +- [ ] **`systemd-user`**: For `systemd --user`, designed such as: + - It allows internal systemd user access, + - It allows starting all common user services. + +Both `systemd` and `systemd-user` should not fallback at all. I am working on some new profiles to ensure that 99% of program started by system have a profile. + +These profiles are only intended to confine themselves. Any services started by systemd must have their corresponding profile. It means that for a given distribution, the following services must have profiles: + +- [x] For `systemd`: +```sh +/usr/lib/systemd/system-generators/* +/usr/lib/systemd/system-environment-generators/* +/usr/lib/systemd/system/*.service +``` + +- [ ] For `systemd-user` +```sh +/usr/lib/systemd/user-environment-generators/* +/usr/lib/systemd/user-generators/* +/usr/lib/systemd/user/*.service +``` + +To be allowed to run, additional root or user services may need to add extra rules inside the `usr/systemd.d` or `usr/systemd-user.d` directory. For example, when installing a new privileged service `foo` with [stacking](#no-new-privileges) you may need to add the following to `/etc/apparmor.d/usr/systemd.d/foo`: +``` + @{lib}/foo rPx -> systemd//&foo, + ... +``` + +### Fallback + +In addition to the `systemd` profiles, a full system policy needs to ensure that no program run in an unconfined state at any time. The fallbacks profiles consist of a set generic specialized profiles: + +- **`default`** is used for any *classic* user application with a GUI. It has full access to user home directories. +- **`bwrap`, `bwrap-app`** are used for *classic* user application that are sandboxed with **bwrap**. + +!!! warning + + The main fallback profile (`default`) is not intended to be used by priviligied program or service. Such programs **must** have they dedicaded profile and would break otherwise. + +Additionally, special user access can be setup using PAM rules set such as a random shell interactively opened (as user or as root). + +[apparmor-wiki]: https://gitlab.com/apparmor/apparmor/-/wikis/FullSystemPolicy +[full]: https://github.com/roddhjav/apparmor.d/blob/main/apparmor.d/groups/_full diff --git a/mkdocs.yml b/mkdocs.yml index 15d8a8ed..cbb7a227 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -132,6 +132,7 @@ nav: - Advanced: - variables.md - enforce.md + - full-system-policy.md - Troubleshooting: - issues.md - report.md