darren_moffat@blog$ cat /dev/mem

darren_moffat@blog$ cat /dev/mem | grep /dev/urandom

All | General | Security | Solaris

« Crypto no longer... | Main | Good article on the... »

Friday July 01, 2005

Signed Solaris 10 binaries ? You may have heared by now that Solaris 10 has signed binaries, you probably have questions about what this really means. I was one of the engineers who designed and developed the framework that made this possible.

What is it NOT ?

It is not an attempt to lock out 3rd party kernel module or other code from running on Solaris or OpenSolaris distributions. In fact it isn't really intended for use by Sun at all, with one exception that applies to Solaris the binary product but not OpenSolaris (this is a US export requirement because at the time of development of Solaris 10 we couldn't claim it was opens source - we still can't but we should be able to for future releases), it is really intended for use by the end administrator.

Okay so what is it then

Kernel modules, libraries and compiled programs are represented in as ELF objects in Solaris (and in many other UNIX systems too). The ELF object contains many things in addition to the text and data sections that actually describe the program code. For example an ELF object may contain debug information or a comments section that is information about revision history, it also contains information for the linker/loader.

We exploit the fact that ELF is exensible and use that to hold a cryptographic signature of the parts of the ELF object that impact the running program code, basically any ELF section that is marked that it will be taken into memory (eg. SHT_PROGBITS). We make an RSA signed SHA-1 hash of those bits and store it in a new ELF section. You do this using a new program called elfsign(1), it is in the SUNWtoo package.

At this time elfsign(1) takes a raw key and certificate from a file, but will soon (planned for a Solaris 10 update release) have the ability to take it from an PKCS#11 token that is available via the Solaris Cryptographic Framework.

So what do you do with these signatures then ?

As of the initial release of Solaris 10, for the most part nothing happens with them unless the admin explicitly askes for verification of a paritcular binary, for example:

$ elfsign verify -e /lib/libc.so.1
elfsign: verification of /lib/libc.so.1 passed.
$ elfsign verify -e /usr/bin/vi
elfsign: verification of /usr/bin/vi passed.
$ elfsign verify -e /kernel/genunix
elfsign: verification of /kernel/genunix passed.

The one exception to this where the system will require verification of an ELF object before using it is for Solaris Cryptographic Framework plugins (user & kernel). Sun was required to do this due to US Export Law, OpenSolaris should not be bound by this requirement since it is open source.

Can I sign my own stuff ?

Yes you can, unfortunately though we didn't have time to make the elfsign(1) commands as user friendly for this part as we had hoped. This will be easier to use in the future. This was because the request sub command of the elfsign(1) command was originaly designed just for use by people signing cryptographic providers and as such asks some questions and creates a certificate request that isn't appropriate for the general case.

I can deal with that just tell me what to type to get a key and certificate

Okay here goes but I did say this wasn't going to be pretty just now...

$ elfsign request -k mykey -r newreq.pem
Enter Company Name / Stock Symbol or some other globally unique identifier.
This will be the prefix of the Certificate DN:

Enter anything in there we are going to change it later anyway, then answer 'n' to the next two questions. If you have a real Certificate Authority already then you can send that request to them, note to them that the request DN will look a bit strange and should be changed to match your local policy. If you don't have one setup or don't want to use it then follow the instructions below to create a local CA using OpenSSL.

$ mkdir demoCA
$ cp /etc/sfw/openssl/openssl.cnf demoCA

Edit the following _default values to match your organisation, I recommend just leaving the country and state ones blank, eg:

countryName_default             = 
stateOrProvinceName_default     = 
0.organizationName_default      = Example Sun ISV Ltd

Now create your local CA:

$ export SSLEAY_CONFIG=demoCA/openssl.cnf
$ perl /usr/sfw/bin/CA.pl -newca

Just take the default answer for everything, other than the passphrase why you need to give one longer than 4 chars in length. Once that is done we can use this new CA to sign the request we generated above.

I've got a key and cert how do I sign now ?

This part is easy and is intended to be easily integrated into your existing build system, (probably in a Makefile or as part of your release engineering process):

$ elfsign sign -k mykey -c mycert -e libmystuff.so.1

Thats it signed! In order for the verify subcommand of elfsign(1) to work you need to put the certificate into /etc/certs. Any name that isn't already taken will do since the name of the file is not significant.

$ cp mycert /etc/certs/Example_ISV_Ltd

You should now be able to do this:

$ elfsign verify -e libmystuff.so.1
elfsign: verification of /lib/libc.so.1 passed.

To be sure it all worked I recommend copying the signed binary and cert to a completely different system.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

( Jul 01 2005, 08:31:10 PM BST ) Permalink Comments [2]

Trackback URL: http://blogs.sun.com/darren/entry/signed_solaris_10_binaries

Comments:

Is there a way how to enable verification of binaries per system/directory ? Say I want to disallow running unsigned/unverified binaries on whole system/in certain directory.

Posted by Vladimir Kotal on November 06, 2006 at 03:14 PM GMT #

Not at this time, hopefully in a future relase of Solaris.

Posted by Darren J Moffat on November 06, 2006 at 04:27 PM GMT #