felipe/apparmor.d
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

doc: move fsp to its own page.

Browse source
This commit is contained in:
Alexandre Pujol 2024-01-27 23:14:30 +00:00
parent c68cdd14a3
commit f6396cc956
No known key found for this signature in database
GPG key ID: C5469996F0DF68EC
3 changed files with 119 additions and 70 deletions
Download patch file Download diff file Expand all files Collapse all files

70
docs/development/structure.md
View file

@ -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