mirrors/apparmor.d
1
0
Fork 0
mirror of https://github.com/roddhjav/apparmor.d.git synced 2024-11-14 23:43:56 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: update fsp structure.

Browse Source
This commit is contained in:
Alexandre Pujol 2024-03-24 13:24:26 +00:00
parent 77016661dc
commit 444b9ef77a
No known key found for this signature in database
GPG Key ID: C5469996F0DF68EC
3 changed files with 30 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/development/dbus.md
View File

@ -18,7 +18,7 @@ For more access, simply use the [`dbus: talk`](#dbus-directive) directive.
## Dbus Directive
We use a special [directive](directives.md) to generate more advanced dbus access. The directive format is on purpose very similar to apparmor dbus rule.
We use a special [directive](directives.md) to generate more advanced dbus access. The directive format is on purpose very similar to the apparmor dbus rule.
**Format**
@ -30,7 +30,7 @@ We use a special [directive](directives.md) to generate more advanced dbus acces
: Access type. Can be `own` or `talk`:
- `own` means the profile own this dbus interface. It is allowed to send and receive from anyone on this interface.
- `own` means the profile own the dbus interface. It is allowed to send and receive from anyone on this interface.
- `talk` means the profile can talk on a given interface to the profile owning it (that must be given under the `label` option).
**`<bus>`**
@ -43,7 +43,7 @@ We use a special [directive](directives.md) to generate more advanced dbus acces
**`[label=AARE]`**
: Name of the profile
: Name of the profile. Mandatory for `talk` access.
**`[interface=AARE]`**

8
docs/development/directives.md
View File

@ -2,7 +2,7 @@
title: Directives
---
`apparmor.d` supports build directives, they are processed at build time of the project, when running `make`. They are valid apparmor comment, `apparmor_parser` can be used on a profile even if the directives have not been processed. They should not end with a comma. Multiline directive is not supported.
`apparmor.d` supports build directives, they are processed at build time of the project, when running `make`. They are valid apparmor comment, therefore, `apparmor_parser` can be used on a profile even if the directives have not been processed. They should not end with a comma. Multiline directive is not supported.
The directives follow the format:
```sh
@ -25,7 +25,7 @@ See the [dbus page](dbus.md#dbus-directive).
## Only, Exclude
The `only` and `exclude` directive can be used to filter individual rule or rule paragraph depending on the target distribution of distribution family.
The `only` and `exclude` directives can be used to filter individual rule or rule paragraph depending on the target distribution of distribution family.
**Format**
@ -63,7 +63,7 @@ The `only` and `exclude` directive can be used to filter individual rule or rule
## Exec
The `exec` directive is useful to allow executing transition to a profile without having to manage the possible long list of profile attachment (that varies depending on the distribution). The directive parse and resolve the attachment variable (`@{exec_path}`) of the target profile and include it in the current profile.
The `exec` directive is useful to allow executing transition to a profile without having to manage the possible long list of profile attachment (it varies depending on the distribution). The directive parse and resolve the attachment variable (`@{exec_path}`) of the target profile and include it in the current profile.
**Format**
@ -103,7 +103,7 @@ The `exec` directive is useful to allow executing transition to a profile withou
## Stack
[Stacked](https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorStacking) profiles can be hard to maintain. The *parents* profile need to manage its own rules as well as always include stacked profile rules. This directive automatically include the stacked profile rules into the parent profile.
[Stacked](https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorStacking) profiles can be hard to maintain. The *parent* profile needs to manage its own rules as well as always include the stacked profile rules. This directive automatically include the stacked profile rules into the parent profile.
**Format**

40
docs/full-system-policy.md
View File

@ -67,43 +67,47 @@ The profiles dedicated for full system policies are maintained in the **[`_full`
### Systemd
In addition to systemd services (`systemd-*`) that have their own profiles, systemd itself, is confined using:
**`systemd`**
- [x] **`systemd`**: For systemd as PID 1, designed such as:
- It allows internal systemd access,
- It allows starting all common root services.
This profile aims to confine PID 1. Systemd is (kind of obviously) a highly privileged program. The purpose of this profile is to transition to other less privileged program as soon as possible. On high security environments, it can also be used to strictly limit the list of allowed privileged program.
- [ ] **`systemd-user`**: For `systemd --user`, designed such as:
- It allows internal systemd user access,
- It allows starting all common user services.
- It allows internal systemd access,
- It allows starting all common root 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`:
To work as intended, all privileged services started by systemd **must** have a profile. For a given distribution, the list of these services can be found under:
```sh
/usr/lib/systemd/system-generators/*
/usr/lib/systemd/system-environment-generators/*
/usr/lib/systemd/system/*.service
```
- [ ] For `systemd-user`
The main [fallback](#fallback) profile (`default`) is not intended to be used by privileged program or service. Such programs must have they dedicated profile and will fail otherwise. This is a **feature**, not a bug.
**`systemd-user`**
This profile is for `systemd --user`, it aims to confine userland systemd. It does not require a lot of access and is only intended to handle user services.
- It allows internal systemd user access,
- It allows starting all common user services.
To work as intended, userland services started by `systemd --user` **should** have a profile. For a given distribution, the list of these services can be found under:
```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`:
```
!!! info
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:
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 fallback 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**.