News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Perspectives
July 1, 2005
Signed Solaris 10 binaries ?
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