set a group and user for the service
remove default null config
it's required, now it throws an error pointing to the option
set myself (module author) as maintainer
Since v2021.5.0 home-assistant uses the ifaddr library in the zeroconf
component to enumerate network interfaces via netlink. Since discovery
is all over the place lets allow AF_NETLINK unconditionally.
It also relies on pyroute2 now, which additionally tries to access files
in /proc/net, so we relax ProtectProc a bit by default as well.
This leaves us with these options unsecured:
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3
✗ DeviceAllow= Service has a device ACL with some special devices 0.1
✗ IPAddressDeny= Service does not define an IP address allow list 0.2
✗ PrivateDevices= Service potentially has access to hardware devices 0.2
✗ PrivateUsers= Service has access to other users 0.2
✗ SystemCallFilter=~@resources System call allow list defined for service, and @resources is included (e.g. ioprio_set is allowed) 0.2
✗ RestrictAddressFamilies=~AF_NETLINK Service may allocate netlink sockets 0.1
✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1
✗ SupplementaryGroups= Service runs with supplementary groups 0.1
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
✗ ProcSubset= Service has full access to non-process /proc files (/proc subset=) 0.1
→ Overall exposure level for home-assistant.service: 1.6 OK 🙂
libbrotli wasn't listed as a dependency for the AppArmor profile of the transmission-daemon binary.
As a result, transmission wouldn't run and would fail, logging this audit message to dmesg:
audit[11595]: AVC apparmor=DENIED operation=open profile=/nix/store/08i1rmakmnpwyxpvp0sfc5hcm106am7w-transmission-3.00/bin/transmission-daemon name=/proc/11595/environ pid=11595 comm=transmission-da requested_mask=r denied_mask=r fsuid=70 ouid=70
This reverts commit d9e18f4e7f.
This change is broken, since it doesn't configure the proper database
username in keycloak when provisioning a local database with a custom
username. Its intended behavior is also potentially confusing and
dangerous, so rather than fixing it, let's revert to the old one.
