[linux-elitists] System-wide certification key (equivalent of root access)

Seth David Schoen schoen@loyalty.org
Fri Jan 18 10:53:17 PST 2002


I was thinking about the possibility of having a public key or keys
which would be kept in a world-readable file in /etc (for example,
/etc/system-signing-key or /etc/certification-keys) and used to verify
signatures on various things on a system.  Something which was
properly signed with that key would be implicitly trusted (by any
software which was written to be aware of this mechanism), so that
the ability to sign with that key would be equivalent to having root
access.  (The principle would be that anyone who's capable of
generating a fake signature with the certification key would also be
capable of replacing any binary on the system with a fake version, so
this should introduce no new security risks if the key is kept at
least as secure as the root password.)

The particular application I thought of was ssh host key signing, so
you could get host keys from a network administrator and they'd be
pre-signed with a key you trusted implicitly, so that you could know
whether or not a host key is correct without having to type "yes" when
ssh prompts you.

But I also imagine these certification keys extending to other cases
in which only a system administrator can do something (like attest
that a host key is right), but that _thing_ might be handled within a
regular user's account.

So another possible application is setuid scripts.  Currently
something like suidperl will check that a script is setuid root and
owned by the appropriate user and has the appropriate permissions and
so on.  But I could also imagine a system where a wrapper like
suidperl checked for a system certification key signature before
running something as root.

A generalization of this approach could lead you closer to a
capabilities system (and I know that the Linux kernel has some
embryonic capabilities support, but it's not done with cryptography,
just with particular flags asserted or not asserted).  Why shouldn't
we have an infrastructure that allows us to trust or distrust programs
or configuration files based on who has signed them, instead of based
on what their ownership, location, or file permissions are?

Signing is also much more resistant to compromise of a local system.
If you have a _requirement_ that something be signed in order to be
accepted from a non-root user, then someone who takes over that user's
account still can't change it (because that would invalidate the
signature).

(I know I'm dealing with a few different problems, because for example
the ability to know whether a foreign host key is correct is different
to know from the ability to know whether a particular operation should
be _permitted_ on the local system.  So maybe there are different but
overlapping kinds of implicit trust, like implicit trust that an
assertion is true, and implicit trust that a contemplated operation will
not violate local security policy.)

-- 
Seth David Schoen <schoen@loyalty.org> | Reading is a right, not a feature!
     http://www.loyalty.org/~schoen/   |                 -- Kathryn Myronuk
     http://vitanuova.loyalty.org/     |



More information about the linux-elitists mailing list