mirror of
https://github.com/roddhjav/apparmor.d.git
synced 2024-11-14 23:43:56 +01:00
doc: move fsp to its own page.
This commit is contained in:
Alexandre Pujol
parent
c68cdd14a3
commit
f6396cc956
@ -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
|
||||
|
||||
118
docs/full-system-policy.md
Normal file
118
docs/full-system-policy.md
Normal file
@ -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
|
||||
@ -132,6 +132,7 @@ nav:
|
||||
- Advanced:
|
||||
- variables.md
|
||||
- enforce.md
|
||||
- full-system-policy.md
|
||||
- Troubleshooting:
|
||||
- issues.md
|
||||
- report.md
|
||||
|
||||
Loading…
Reference in New Issue
Block a user