This kind of problems is usually handled by having two stand-alone binaries: the service daemon and the user interface that communicate over a UNIX domain socket (or a network socket in case they are not running on the same machine). A prime example would be OpenSSH - check how
ssh interact to get some idea how this can be done. Replace "UNIX domain socket" with "D-Bus" if you want to get trendy or need some extra functionality that you'd have to implement.
If the action request is coming from the daemon itself (which if I understand correctly) is your particular case, it is a bit trickier. The UI part should get spawned sometimes during the X session, register itself with the daemon and when the daemon decides it needs some input, it asks the UI part to do its stuff. The last two sentences are actually where D-Bus might come in handy.
On the other hand, you should consider carefully, whether daemon actively asking for a password is the Right WayTM of doing things - daemons are usually services which answer requests rather than generating one. It might be better to let the UI actively push the password in, when user decides it is time to do that. I'm not saying that is the only good approach, just that it should be considered thoroughly first.
As far as security is concern, everything depends on how paranoid you want to get. With X you can grab the keyboard (see
XGrabKeyboard(3) man page) which should give you reasonable level of security. Or better put: if you don't use it, you have no control of the password whatsoever. Again, ssh is a good example: have a look at the
x11-ssh-askpass helper. Its homepage doesn't seem to work any more, but you can find the sources in many places, for example in the openSUSE BuildService.
You can actually even use it directly, since all it does is grabbing the keyboard and outputting the entered password on its standard output, so all you need is to spawn the askpass helper and check its
stdout. If I recall correctly,
readpass.c in OpenSSH should give you some idea about how to do it.
While all this may look a bit overcomplicated and far from secure, there are several things to consider:
several projects usually considered reasonably secure like OpenSSH and GPG use this approach.
Security is hard. Rolling out one's own security solutions usually ends with troubles (or disasters) one way or another (it can also become the usual enterprise-y: "I've got this cool thing." - "Wow, let's make it a new company tool" - 5 years later: "It's completely inextensible/broken/insecure/... - how could have anybody made this a company-wide solution?!" Substitute "company-wide solution" with "our flagship product" for hours of laughter). Also see the canonical Security SE Q&As: https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own and https://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology.
Keyboard grabbing doesn't say anything about any other application not eavesdropping on the keyboard events somewhere deeper in the stack (i.e. under the X application layer). But then again, such an application would very likely require some sort of root access, hence if you had something like that on the system, you might as well put the passwords into a plain text file named
passwords.txt in your home directory).