Aren't systemd's security capabilities in userspace simpler to use?
Aren't systemd's security capabilities in userspace simpler to use?
Posted Jul 23, 2015 20:14 UTC (Thu) by ibukanov (subscriber, #3942)In reply to: Aren't systemd's security capabilities in userspace simpler to use? by wahern
Parent article: Domesticating applications, OpenBSD style
The right way to handle private keys is to have a separated process that handle cryptography for the main application over a pipe with private keys loaded via separated programs over another pipe. This way the crypto process would not need any file system access and the main application would not need to access private keys. It is interesting that recent OpenSSHD comes rather close to this model with sshd gaining ability to use host keys stored in ssh-sgent. I wrote "almost" as ssh-agent has to create its unix socket requiring minimal filesystem access rather accepting it on stdin.
> Sensitive configuration files.
It is better to have a unix socket in the application where administrator or scripts can send those config files. This also eliminates the need for any signals and races when the application has to be notified about changes in the files.
> Filesystem initializations.
Why not to have a separated process that does this?
In any case, I think the main purpose of tame is to add *quickly* another layer of security to existing codebase. But I am not convinced that in the long term this a right approach.