Re:Who Watches Watchmen? – Integrating Elixir Applications w...
by the8472 on Tuesday January 18, 2022 @04:26AM
(#29976906)
With that many options it seems easy to miss something. A whitelist approach would be preferable. The application failing because you missed something would be more obvious than some subtle security hole.
Re:Who Watches Watchmen? – Integrating Elixir Applications w...
by jiripospisil on Tuesday January 18, 2022 @05:17AM
(#29977188)
There's already a ticket precisely for that but it has been closed in as a duplicate https://github.com/systemd/systemd/issues/20247
Re:Who Watches Watchmen? – Integrating Elixir Applications w...
by acdha on Wednesday January 19, 2022 @12:23PM
(#29996663)
This leaves me wishing there was some kind of report-only tooling where you could do something like, say, freeze the system calls used in a test run to reduce trial-and-error, similar to how you can use SELinux with audit2allow to get a decent starting point. Does anything like that already exist?
Re:Who Watches Watchmen? – Integrating Elixir Applications w...
by hauleth on Tuesday January 18, 2022 @03:05AM
(#29976393)
Oh, I didn't know about `SocketBindDeny=` and `SocketBindAllow=`. This option may be a little troublesome in case of Distributed Erlang, but in recent versions it can be circumvented. Thanks, I will add it as a better option than adding capabilities.
'systemd-analyze security' is a fine thing, just make sure to use the latest version of systemd because it was really buggy in the past. For example, the version that ships in RHEL 8 is so buggy it's practically useless.
I came up with this for most of my services that do require a JIT compiler (so Java, dotnet, etc):
You might want to throw away InaccessiblePaths if your application calls external binaries. The stuff I typically write shouldn't do it.Some of these flags are not strictly necessary because they should be enabled by other switches, but I prefer to keep them to make configuration more obvious and to mitigate possible bugs (there were some in the past).
If your application needs to store anything locally, add some combination of these:
and you can read the resulting path in environment variables RUNTIME_DIRECTORY / STATE_DIRECTORY / CACHE_DIRECTORY / LOGS_DIRECTORY / CONFIGURATION_DIRECTORY if your systemd is new enough.systemd will make sure that your limited user can read and write these paths, including their content.
Add this if your application does not use a JIT compiler:
And this to prevent it from listening on wrong ports in an event of misconfiguration. These firewalling flags can be useful if your service does not do much networking to external APIs: