You are not logged in.

#1 2018-12-09 22:23:08

mnot
Member
From: Melbourne, Australia
Registered: 2015-10-14
Posts: 7
Website

Systemd sandboxing in packages

Just curious - why don't more packages take advantage of systemd's sandboxing mechanisms?

E.g., for one of mine, I use:

# Sandbox
NotifyAccess=main
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=tmpfs
BindReadOnlyPaths= [ paths that the app needs access to ]
DevicePolicy=closed
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true

# Resource Limits
CPUQuota=50%
MemoryLow=40M
MemoryHigh=50M
MemoryMax=60M
MemorySwapMax=60M

Offline

#2 2018-12-09 22:45:02

Slithery
Forum Moderator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 3,197

Re: Systemd sandboxing in packages

That's a question for the upstream developers.


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#3 2018-12-09 22:47:49

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 21,112
Website

Re: Systemd sandboxing in packages

A well written service or daemon should chroot and drop privileges itself anyways.  What does systemd sandboxing add to this?  How would it work with programs that should be able to work with various files (e.g., most programs).  Why would I want to limit CPU use of a program I chose to run?  If I want to run a CPU-intensive number crunching process, I want it to use my CPU.  If programs use CPU resources for no reason there is a much better solution than sandboxing: pacman -Rsn $bad_program.

General or global sandboxing sounds more like nannying.

Last edited by Trilby (2018-12-09 22:48:45)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#4 2018-12-09 22:50:17

mnot
Member
From: Melbourne, Australia
Registered: 2015-10-14
Posts: 7
Website

Re: Systemd sandboxing in packages

Looking at the packages I use as a sample, a lot of service files are provided by arch, not upstream.

E.g., apache, prosody, varnish, nginx.

There are certainly some cases where a service needs greater access, or where coming up with universal defaults for this is difficult (or impossible), but it seems to me that there are some baseline things that can be done.

Offline

#5 2018-12-09 22:51:48

mnot
Member
From: Melbourne, Australia
Registered: 2015-10-14
Posts: 7
Website

Re: Systemd sandboxing in packages

Trilby - that's true, but defence in depth is a valid way to assure security.

Offline

Board footer

Powered by FluxBB