Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security and convenience #169

Closed
hakavlad opened this issue Mar 5, 2020 · 10 comments
Closed

Security and convenience #169

hakavlad opened this issue Mar 5, 2020 · 10 comments

Comments

@hakavlad
Copy link
Contributor

hakavlad commented Mar 5, 2020

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
Copy link
Contributor Author

hakavlad commented Mar 5, 2020

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
Copy link
Contributor Author

hakavlad commented Mar 5, 2020

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

@hakavlad
Copy link
Contributor Author

hakavlad commented Mar 5, 2020

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

@hakavlad
Copy link
Contributor Author

hakavlad commented Mar 5, 2020

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
Copy link
Owner

rfjakob commented Mar 5, 2020

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
Copy link
Owner

rfjakob commented Mar 5, 2020

(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
Copy link
Contributor Author

hakavlad commented Mar 5, 2020

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
Copy link
Owner

rfjakob commented Mar 5, 2020

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

@rfjakob
Copy link
Owner

rfjakob commented Mar 7, 2020

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
Copy link
Owner

rfjakob commented Mar 31, 2020

Closing this in favor of #183

@rfjakob rfjakob closed this as completed Mar 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants