Security and convenience

[hakavlad]

I hope that this thread will end with the adoption of the second unit service and release 1.5 (with -m changes, of course). Let's go!

[hakavlad]

1st service (earlyoom.service):

[Unit]
Description=Early OOM Daemon
Documentation=man:earlyoom(1) https://github.com/rfjakob/earlyoom
Conflicts=earlyoom-root.service

[Service]
SyslogIdentifier=earlyoom
EnvironmentFile=-:SYSCONFDIR:/default/earlyoom
ExecStart=:TARGET:/earlyoom $EARLYOOM_ARGS
Restart=always
TasksMax=1
MemoryMax=10M
MemorySwapMax=0
AmbientCapabilities=CAP_KILL CAP_IPC_LOCK CAP_SYS_NICE
ProtectHome=true
DynamicUser=true
SupplementaryGroups=adm
PrivateNetwork=true
ProtectSystem=strict
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
MemoryDenyWriteExecute=yes
LockPersonality=yes
RestrictNamespaces=yes
CPUSchedulingResetOnFork=true
RestrictRealtime=yes


[Install]
WantedBy=multi-user.target

2nd service (earlyoom-root.service):

[Unit]
Description=Early OOM Daemon
Documentation=man:earlyoom(1) https://github.com/rfjakob/earlyoom
Conflicts=earlyoom.service

[Service]
SyslogIdentifier=earlyoom-root
EnvironmentFile=-:SYSCONFDIR:/default/earlyoom
ExecStart=:TARGET:/earlyoom $EARLYOOM_ARGS
Restart=always
TasksMax=10
MemoryMax=50M
CapabilityBoundingSet=CAP_KILL CAP_IPC_LOCK CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE CAP_SETUID CAP_SETGID CAP_SYS_RESOURCE CAP_SYS_NICE
InaccessiblePaths=/home /root
ProtectSystem=strict
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
MemoryDenyWriteExecute=yes
LockPersonality=yes
RestrictNamespaces=yes
CPUSchedulingResetOnFork=true
RestrictRealtime=yes

[Install]
WantedBy=multi-user.target

[hakavlad]

I want to offer a scheme that offers a combination of maximum security and convenience. Just install 2 unit services with earlyoom package.

[hakavlad]

BTW, -p flag will not provide niceness changes without CAP_SYS_NICE. -p option is broken now (I offer fixed units here).

[hakavlad]

earlyoom.service vs earlyoom-root.service

TasksMax=1
MemoryMax=10M
MemorySwapMax=0

->

TasksMax=10
MemoryMax=50M

DynamicUser=true
SupplementaryGroups=adm

->

User=root

AmbientCapabilities=CAP_KILL CAP_IPC_LOCK CAP_SYS_NICE

->

CapabilityBoundingSet=CAP_KILL CAP_IPC_LOCK CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE CAP_SETUID CAP_SETGID CAP_SYS_RESOURCE CAP_SYS_NICE

PrivateNetwork=true

->

PrivateNetwork=false

ProtectHome=true

->

InaccessiblePaths=/home /root

SyslogIdentifier=earlyoom

->

SyslogIdentifier=earlyoom-root

Conflicts=earlyoom-root.service

->

Conflicts=earlyoom.service

earlyoom-root.service provides good security and sandboxing without compromising on functionality.
earlyoom.service provides strongest security and sandboxing.
Delivery of a package with two service files will provide convenience and security as much as possible.

[rfjakob]

My plan is to implement the notifications differently, this sudo stuff is unsustainable imo.

earlyoom will send a dbus message to the system bus, and there will be tiny daemon running as the user that listens for those messages and show a notification

[rfjakob]

(not my idea, the idea is from here, german only unfortunately, but there is some python example code: https://wiki.debianforum.de/Desktop-Notification_von_Systemservice_mittels_dbus )

[hakavlad]

Did you test it? Is it really possible to notify all users without sudo+notify-send if the daemon started as root/nonroot/dynamicuser?

[rfjakob]

Not yet, no. If you need root rights to send to the system bus then this will all not work.

[rfjakob]

Seems to work ok (edit: both runs as the same, normal user)

$ dbus-send --system --type=signal / net.nuetzlich.SystemNotifications.Notify "string:hello world"

$ dbus-monitor --system
[...]
signal time=1583570854.999879 sender=:1.1278 -> destination=(null destination) serial=2 path=/; interface=net.nuetzlich.SystemNotifications; member=Notify
   string "hello world"

[rfjakob]

Closing this in favor of #183