3 ms·

Though security isn't just about how secure a thing could be, but how secure it is in common practice. I would trust a minimal Linux distro with a decent kernel

Though security isn't just about how secure a thing could be, but how secure it is in common practice. I would trust a minimal Linux distro with a decent kernel configuration as well, but I wouldn't trust Ubuntu server with systemd and who knows what else by default. I'd much rather have OpenBSD base; and OpenBSD base is fundamentally a minimal install with decent kernel defaults. The people in the OpenBSD community tend to focus on the minimalist configuration by default, which helps security in practice; and things are easy to configure. Running a postgresql database on top of OpenBSD base with PF blocking everything except whitelisted clients will go a long way for security. For a lot of servers, OpenBSD base with a few libraries is enough for a server application, and the work put into making base minimal and secure by default is great for that.

lmns 6y ago
I would trust a distribution with systemd _more_ than I would trust one without it. Systemd has a lot of knobs for sandboxing services now.
- dundarious 6y ago
  OpenBSD has much easier to use features such as pledge and unveil as part of libc, and led the way in W^X.
  - lmns 6y ago
    I know, but just setting MemoryDenyWriteExecute=yes is even easier.
    - dundarious 6y ago
      I’m not an active OpenBSD user, but I’m reasonably confident that the OpenBSD W^X check kills any violating process since about 2016. Applies to all executables (not just system services/daemons with conscientious maintainers who think to apply that setting) except if the filesystem is mounted wxallowed. I think that’s a strict improvement. I like systemd on Linux, but I think the systemd sandboxing is chasing OpenBSD, not the other way around.
      - tptacek 6y ago
        Doesn't systemd's sandboxing do seccomp-bpf? Pledge is an interesting system, but it's not BPF.
        dundarious 6y ago
        systemd’s syscall filtering is pretty good and comparable to pledge in terms of ease of use — both let you use nice aliases for sets of syscalls, like stdio or @aio. I’ve only _played_ with both, so my opinions are weakly held, but pledge+unveil excel for designing a system where I have full source code control/authorship, and systemd’s sandbox excels for deploying third party services. pledge+unveil just make it so easy to incrementally drop privileges after your initialization phase(s), where for systemd, so far as I know, you’d have to have separate service files for the smaller sandboxes of subsequent phases — or better yet, use seccomp-bpf directly, or even better... a pledge-like wrapper on top. Ideally your app wouldn’t need any more syscalls at startup than it needs later on though, so it’s quite legitimate to argue it’s no big deal at all, or that systemd encourages better design discipline.

lmns 6y ago

I would trust a distribution with systemd _more_ than I would trust one without it. Systemd has a lot of knobs for sandboxing services now.

dundarious 6y ago
OpenBSD has much easier to use features such as pledge and unveil as part of libc, and led the way in W^X.
- lmns 6y ago
  I know, but just setting MemoryDenyWriteExecute=yes is even easier.
  - dundarious 6y ago
    I’m not an active OpenBSD user, but I’m reasonably confident that the OpenBSD W^X check kills any violating process since about 2016. Applies to all executables (not just system services/daemons with conscientious maintainers who think to apply that setting) except if the filesystem is mounted wxallowed. I think that’s a strict improvement. I like systemd on Linux, but I think the systemd sandboxing is chasing OpenBSD, not the other way around.
    - tptacek 6y ago
      Doesn't systemd's sandboxing do seccomp-bpf? Pledge is an interesting system, but it's not BPF.
      - dundarious 6y ago
        systemd’s syscall filtering is pretty good and comparable to pledge in terms of ease of use — both let you use nice aliases for sets of syscalls, like stdio or @aio. I’ve only _played_ with both, so my opinions are weakly held, but pledge+unveil excel for designing a system where I have full source code control/authorship, and systemd’s sandbox excels for deploying third party services. pledge+unveil just make it so easy to incrementally drop privileges after your initialization phase(s), where for systemd, so far as I know, you’d have to have separate service files for the smaller sandboxes of subsequent phases — or better yet, use seccomp-bpf directly, or even better... a pledge-like wrapper on top. Ideally your app wouldn’t need any more syscalls at startup than it needs later on though, so it’s quite legitimate to argue it’s no big deal at all, or that systemd encourages better design discipline.