selfprivacy-api and selfprivacy-api-worker systemd services hardening #36

Open
opened 2023-07-01 04:19:45 +03:00 by alexoundos · 3 comments
Member

Currently, selfprivacy-api service runs under root user! In addition to that, none of the systemd hardening options are in use. Common options are described here.

As for selfprivacy-api-worker service it is unclear which privileges it must have.

Currently, [`selfprivacy-api` service runs under `root` user](https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-config/src/commit/65b5a1977756549240eae05005d1f6b5feef126d/api/api-module.nix#L65)! In addition to that, none of the systemd hardening options are in use. Common options are described [here](https://git.selfprivacy.org/alexoundos/articles/src/branch/master/article.md#common-hardening-options-execution-environment-configuration). As for `selfprivacy-api-worker` service it is unclear which privileges it must have.
Author
Member

Currently, selfprivacy-api service needs access to /etc/nixos/userdata/userdata.json file, which is only accessible by root user (owned by root with 600 mode). It needs to be decided how we change userdata.json file permissions (and maybe its location).

Currently, `selfprivacy-api` service needs access to `/etc/nixos/userdata/userdata.json` file, which is only accessible by `root` user (owned by `root` with 600 mode). It needs to be decided how we change `userdata.json` file permissions (and maybe its location).
Author
Member

Today (2024-04-17) we decided that SelfPrivacy API service:

  1. needs to be first modified to call systemd services for tasks, which require root access.
  2. will be given permission to start only those systemd services, which are:
    • listed in SP module definition
    • hardcoded
  3. will most likely be granted permissions from security.sudo.extraRules, populated with specific systemd start commands (with services names from SP modules definitions and hardcoded ones)
Today (2024-04-17) we decided that SelfPrivacy API service: 1. needs to be first modified to call systemd services for tasks, which require root access. 2. will be given permission to start only those systemd services, which are: - listed in SP module definition - hardcoded 3. will most likely be granted permissions from `security.sudo.extraRules`, populated with specific `systemd start` commands (with services names from SP modules definitions and hardcoded ones)
Author
Member
https://www.synacktiv.com/en/publications/systemd-hardening-made-easy-with-shh
inex added this to the Security hardening and audit, monitoring project 2024-06-19 16:46:17 +03:00
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: SelfPrivacy/selfprivacy-nixos-config#36
No description provided.