On 08/27/2010 06:36 PM, Michael Smith wrote:
Hi all,
In our (mozilla/xulrunner-based) application, we're trying to set up a
secure connection to a server that requires a client certificate.
Rather than the normal case of a client certificate belonging to the
user, and just added to the certificate store, we want to have a
certificate that nominally belongs to the application, and is secret
from the user (strange, but that's what I'm stuck with).
The specific requirements are that we not store it unencrypted in the
filesystem - and simply setting a password on the key db isn't an
option, as that would interfere with the _user's_ use of the key db
for any of their certificates, and that it must not be available in
the UI (so we want to somehow hide it from the 'View Certificates' UI
- or at least not be exportable from there).
Can anyone suggest an approach to implementing this?
System services (e.g. daemons) have a very similar requirement for
accessing their security information and being able to operate
unattended. The usual solution for system services is to create a
"system" user (typically a uid less 1024, but that varies by OS). The
security information is placed in a file only that user can read. Upon
start up the process will switch it's effective uid to that uid. However
if your application is a normal user process running under the uid of
the user that won't work. It works in the case of a system service
because those processes start with root privileges and can "drop
privileges" to the daemon uid after they've begun executing.
Very much akin to what I described above are the requirements for
storing a host certificate for machine authentication when joining a
domain. But once again the storage of that cert is protected by root
level privileges.
Another possible approach would be akin to what Cyrus SASL saslauthd
does. saslauthd is a tiny root daemon process who purpose is to access
authentication information on behalf of an unprivileged process. The
unprivileged process sends a request to saslauthd which is running with
root privileges and requests it perform an authentication on it's
behalf. In fact the basic concept is not all that different from RADIUS.
If your application is a normal user application running under the uid
of the user who started and you have no way to install and start a
system daemon then I can't think of a mechanism that couldn't be
compromised and/or wouldn't require user intervention. Anybody else have
better ideas?
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
