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

Dan Wilder dan@ssc.com
Tue Jan 22 08:56:09 PST 2002

Presuming you actually _checked_ the signature at load time,
you'd catch a lot of problems with what Don Marti calls
"Windows Grade Hardware".  If a cache glitch, etc, happens when 
loading a binary, it won't pass the signature test.  Sparing
us many nonreproduceable results and sporadic glitches on
marginal hardware, I suspect.

Short-run this would result in a lot more of the sorts of FAQs
we see already: 

  "I was trying to compile my kernal and I got
   a message about 'caught signal 11', what should I do?  
   Why is this OS so fussy?  My computer runs Windows 
   just fine, hardly ever bluescreens".

This would, however, greatly slow down the startup of a large
program that wasn't cached already.  Instead of merely loading
the program text start page, you'd have to load the whole thing.

I'm reminded of a proprietary real-time OS I worked with for some
years.  No signatures, but every binary had a checksum, and lots
of corrupted binaries were flagged, as well as some memory problems.

On Mon, Jan 21, 2002 at 08:46:23PM -0800, woodard@redhat.com wrote:
> 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
> _______________________________________________
> linux-elitists 
> http://zgp.org/mailman/listinfo/linux-elitists

 Dan Wilder <dan@ssc.com>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549    URL http://embedded.linuxjournal.com/

More information about the linux-elitists mailing list