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

woodard@redhat.com woodard@redhat.com
Mon Jan 21 20:46:23 PST 2002


That is a really interesting idea Seth. 
The idea that this prompted for me was to make a more secure operating
system. Imagine if you tweaked the binary loader in the kernel to only
load or execute code which were signed.

You install the operating system. At the end of the install process,
the installing SA is asked to sign all binaries. Then depending on
some /proc file system file the kernel would either:
a) refuse to load or execute all binaries that are not signed.
b) refues to load or execute any setuid binaries that are not signed.
c) allow all binaries.

The same choices could said of scripts.
For backward compatibilities the defaults would be:
    allow all binaries
    allow all non-setuid script
but if you needed a more secure box then you would force all binaries
and all scripts to be signed before they could be executed.

You could also add an option to log the fact that someone tried to run
an unsigned program.

Another option would be to allow multiple system wide signatures and
then allow the package managers such as the debian projec redhat and
the system adminstrator sign packages. That might make package updates
easier.

Dang, I wish I'd thought of this idea a few years ago when I was
taking my kernel internals class. This would have been a wonderful
project to implement.

The only problem I see is that this would put cryptography in the
kernel and I don't know if that is allowed yet.

-ben

> 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/     |
> _______________________________________________
> linux-elitists 
> http://zgp.org/mailman/listinfo/linux-elitists




More information about the linux-elitists mailing list