Christophe-Marie Duquesne:
> Any idea how to proceed?
You're running a daemon. It really shouldn't have an interactive user
interface. Remember the lessons that resulted in Session 0 Isolation in
Windows NT.
There are several poor approaches. Here are two more:
* Make your password into configuration information, that is saved by
something else in a secure place that only your daemon can access. Yes,
this has the gross disadvantage that you are writing the password to
storage somewhere, in plaintext. I mention this not because it is
good, but because it is the next thing that people think of. It is as
rife with security problems as having an interactive user interface is.
Really, this should not be a password at all. Ciphertext encrypted with
a secret private key that the daemon can decrypt using a public key that
it holds, is a step in the right direction. Remember that attackers
will know the decryption key, the encryption/decryption algorithm, and
the plaintext.
* Provide other services that mediate between your daemon and users.
This can be subdivided into the Windows NT approach and the systemd
approach. The Windows NT approach depends from the architecture of
Windows NT, in particular secured desktops. The systemd approach is to
copy the ideas of lpr and mailx, and turn password prompts into batch
jobs. The daemon drops a password request file into an input hopper,
and waits for something else to process and deal with it. The something
else is another service, possibly more than one, running interactively
on a user's logged in desktop or connected to a virtual terminal. See
https://freedesktop.org/wiki/Software/systemd/PasswordAgents/ . It of
course lacks a Secure Attention Key and provides no mechanism for users
to distinguish spoofed password requests. The resultant systemd design
choice is to prevent non-superuser processes from being able to submit
requests into the input hopper. A daemon that drops privileges cannot
use this, for example.
Received on Thu May 26 2016 - 13:16:16 UTC