Provide an AppArmor profile for gitea #7246

New Issue

GiteaMirror · 2025-11-02T07:20:44-06:00

GiteaMirror commented

2025-11-02 07:20:44 -06:00

Originally created by @nodiscc on GitHub (Apr 25, 2021).

Gitea version (or commit ref): 1.13.6 installed from binary
Git version: 1:2.20.1-2+deb10u3
Operating system: Debian 10
Database: not relevant
Can you reproduce the bug at https://try.gitea.io: unknown

Description

Gitea should provide an apparmor profile allowing only required access (commands, files, directories) and document how to enable it.

Screenshots

$ sudo aa-unconfined  | grep gitea
1197 /usr/local/bin/gitea not confined

Originally created by @nodiscc on GitHub (Apr 25, 2021).   - Gitea version (or commit ref): 1.13.6 installed from binary - Git version: 1:2.20.1-2+deb10u3 - Operating system: Debian 10 - Database: not relevant - Can you reproduce the bug at https://try.gitea.io: unknown ## Description Gitea should provide an [apparmor](https://wiki.debian.org/AppArmor) profile allowing only required access (commands, files, directories) and document how to enable it. ## Screenshots ``` $ sudo aa-unconfined | grep gitea 1197 /usr/local/bin/gitea not confined ```

GiteaMirror added the type/proposal label 2025-11-02 07:20:44 -06:00

GiteaMirror commented

2025-11-02 07:20:45 -06:00

@jeannekamikaze commented on GitHub (Dec 6, 2021):

I am new to the project, so not the best person to do this, but I can help out with some guidance. I have run a fresh installation of gitea through apparmor in complain mode and created the profile below. If you think this is a good starting point, I can create a PR and we can take it from there.

A few things to note:

Like the documentation says, write access to /etc/gitea/app.ini is required by the installer, but only read access is required post-installation. I have configured the profile to allow read/write access so that the installer works out of the box, but the documentation would probably have to be updated to note that the profile can be further tweaked.
Your mileage will likely vary given the number of database backends and extra features gitea supports. I have created the profile with a default installation using Postgresql. I imagine additional rules would be required depending on the database, whether you connect to it remotely, whether gitea listens on a privileged port, etc.

Please let me know how you would like to proceed. Thank you.

/usr/local/bin/gitea flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  /etc/mime.types r,
  /proc/sys/net/core/somaxconn r,
  /sys/devices/system/cpu/online r,
  /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,
  /usr/bin/dash mrix,
  /usr/bin/git mrix,
  /usr/lib/git-core/git mrix,
  /usr/local/bin/gitea r,
  /usr/share/git-core/templates/ r,
  /usr/share/git-core/templates/** r,
  owner /etc/gitea/app.ini rw,
  owner /proc/*/cpuset r,
  owner /var/lib/gitea/data/** rwk,
  owner @{HOME}/.gitconfig rw,
  owner @{HOME}/.gitconfig.lock rw,
  owner @{HOME}/.ssh/ w,

}

@jeannekamikaze commented on GitHub (Dec 6, 2021): I am new to the project, so not the best person to do this, but I can help out with some guidance. I have run a fresh installation of gitea through apparmor in complain mode and created the profile below. If you think this is a good starting point, I can create a PR and we can take it from there. A few things to note: - Like the [documentation says](https://docs.gitea.io/en-us/linux-service/), write access to `/etc/gitea/app.ini` is required by the installer, but only read access is required post-installation. I have configured the profile to allow read/write access so that the installer works out of the box, but the documentation would probably have to be updated to note that the profile can be further tweaked. - Your mileage will likely vary given the number of database backends and extra features gitea supports. I have created the profile with a default installation using Postgresql. I imagine additional rules would be required depending on the database, whether you connect to it remotely, whether gitea listens on a privileged port, etc. Please let me know how you would like to proceed. Thank you. ``` /usr/local/bin/gitea flags=(complain) { #include <abstractions/base> #include <abstractions/dbus-session-strict> #include <abstractions/nameservice> #include <abstractions/user-tmp> /etc/mime.types r, /proc/sys/net/core/somaxconn r, /sys/devices/system/cpu/online r, /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r, /usr/bin/dash mrix, /usr/bin/git mrix, /usr/lib/git-core/git mrix, /usr/local/bin/gitea r, /usr/share/git-core/templates/ r, /usr/share/git-core/templates/** r, owner /etc/gitea/app.ini rw, owner /proc/*/cpuset r, owner /var/lib/gitea/data/** rwk, owner @{HOME}/.gitconfig rw, owner @{HOME}/.gitconfig.lock rw, owner @{HOME}/.ssh/ w, } ```

GiteaMirror commented

2025-11-02 07:20:46 -06:00

@coelner commented on GitHub (Jan 8, 2022):

Especially the hooks are missing. But it is horrible due to the restriction that each hook file needs a separate entry, because apparmor relies on a absolute path for executable files.

@coelner commented on GitHub (Jan 8, 2022): Especially the hooks are missing. But it is horrible due to the restriction that each hook file needs a separate entry, because apparmor relies on a absolute path for executable files.

GiteaMirror commented

2025-11-02 07:20:46 -06:00

@tepozoa commented on GitHub (May 3, 2022):

An update from my work - there are subtle problems you might not run into for awhile; I have by design files not owned by the git user on purpose to prevent the files from being edited by some future-unknown app-level exploit. We don't want Gitea to be able to modify files at runtime it has no business touching, such as templates in data/custom/ etc.

The apparmor profile is deployed after Gitea is initialized and has added it's first SSH key and so forth (it will make /home/.git/ssh one time only, etc.) -

remove the dbus abstractions, not needed
do not require owner on app.ini and read-only, mode 0640 root:git
allow non-owner read of items in data/custom/ (templates, images, etc.) to prevent git-user write
add more paths needed as they showed up in /var/log/kern.log in complain mode
attempt to solve the Hooks problem -- modern apparmor does allow binary wildcarding, it might be a bit dangerous in the bigger picture but seems to work (needs more people to test and debug, I don't really use hooks); I'm a little concerned we need to allow shells to just run from a security point of view.

It's not perfect but it's one step closer to the goal, still testing and debugging it over time. Debian 11 stable repo git install, Gitea 1.16.7:

#include <tunables/global>

/usr/local/bin/gitea flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  /dev/tty rw,
  /etc/gitconfig r,
  /etc/gitea/app.ini r,
  /etc/machine-id r,
  /etc/mime.types r,
  /proc/sys/net/core/somaxconn r,
  /proc/version r,
  /sys/devices/system/cpu/online r,
  /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,
  /usr/bin/basename mrix,
  /usr/bin/bash mrix,
  /usr/bin/cat mrix,
  /usr/bin/dash mrix,
  /usr/bin/env rix,
  /usr/bin/git mrix,
  /usr/lib/git-core/git mrix,
  /usr/local/bin/gitea mrix,
  /usr/share/git-core/templates/** r,
  /var/lib/gitea/** r,

  owner /proc/*/cpuset r,
  owner /var/lib/gitea/data/** rwk,
  owner /var/lib/gitea/data/gitea-repositories/*/*.git/hooks/* mrix,
  owner /var/lib/gitea/data/gitea-repositories/*/*.git/hooks/*.d/* mrix,
  owner /var/lib/gitea/log/* rw,
  owner @{HOME}/.gitconfig rw,
  owner @{HOME}/.gitconfig.lock rw,
  owner @{HOME}/.ssh/* rw,

}

Side comment: if you use the gitea dump feature, the folder where backups are stored needs to be added to your config; I run the backups on a systemd timer running as the git(ea) user so it's apparmor confined.

@tepozoa commented on GitHub (May 3, 2022): An update from my work - there are subtle problems you might not run into for awhile; I have by design files not owned by the git user on purpose to prevent the files from being edited by some future-unknown app-level exploit. We don't want Gitea to be able to modify files at runtime it has no business touching, such as templates in `data/custom/` etc. The apparmor profile is deployed _after_ Gitea is initialized and has added it's first SSH key and so forth (it will make /home/.git/ssh one time only, etc.) - - remove the dbus abstractions, not needed - do not require `owner` on app.ini and read-only, mode 0640 root:git - allow non-owner read of items in data/custom/ (templates, images, etc.) to prevent git-user write - add more paths needed as they showed up in /var/log/kern.log in complain mode - _attempt_ to solve the Hooks problem -- modern apparmor does allow binary wildcarding, it might be a bit dangerous in the bigger picture but seems to work (needs more people to test and debug, I don't really use hooks); I'm a little concerned we need to allow shells to just run from a security point of view. It's not perfect but it's one step closer to the goal, still testing and debugging it over time. Debian 11 stable repo `git` install, Gitea 1.16.7: ``` #include <tunables/global> /usr/local/bin/gitea flags=(complain) { #include <abstractions/base> #include <abstractions/nameservice> #include <abstractions/user-tmp> /dev/tty rw, /etc/gitconfig r, /etc/gitea/app.ini r, /etc/machine-id r, /etc/mime.types r, /proc/sys/net/core/somaxconn r, /proc/version r, /sys/devices/system/cpu/online r, /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r, /usr/bin/basename mrix, /usr/bin/bash mrix, /usr/bin/cat mrix, /usr/bin/dash mrix, /usr/bin/env rix, /usr/bin/git mrix, /usr/lib/git-core/git mrix, /usr/local/bin/gitea mrix, /usr/share/git-core/templates/** r, /var/lib/gitea/** r, owner /proc/*/cpuset r, owner /var/lib/gitea/data/** rwk, owner /var/lib/gitea/data/gitea-repositories/*/*.git/hooks/* mrix, owner /var/lib/gitea/data/gitea-repositories/*/*.git/hooks/*.d/* mrix, owner /var/lib/gitea/log/* rw, owner @{HOME}/.gitconfig rw, owner @{HOME}/.gitconfig.lock rw, owner @{HOME}/.ssh/* rw, } ``` Side comment: if you use the `gitea dump` feature, the folder where backups are stored needs to be added to your config; I run the backups on a systemd timer running as the git(ea) user so it's apparmor confined.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7246