This article presents a Linux kernel module capable of verifying digital signatures of ELF binaries before running them. This kernel module is available under the GPL license at http://sourceforge.net/projects/disec, and has been successfully tested for kernel 2.5.66 and above.

Why Check the Signature of Your Binaries Before Running Them?
The problem with blindly running executables is that you are never sure they actually do what you think they are supposed to do (and nothing more). Viruses spread so much on Microsoft Windows systems mainly because users are frantic to execute whatever they receive, especially if the title is appealing. The LoveLetter virus, with over 2.5 million machines infected, is a famous illustration of this. Yet Linux is unfortunately not immune to malicious code either. By executing unknown and untrusted code, users are exposed to a wide range of Unix worms, viruses, trojans, backdoors, and so on. To prevent this, a possible solution is to digitally sign binaries you trust, and have the system check their digital signature before running them: if the signature cannot be verified, the binary is declared corrupt and the operating system will not let it run.

Related Work
There have already been several initiatives in this domain, such as Tripwire, BSign, Cryptomark, and IBM's Signed Executables, but we believe the DigSig project is the first to be both easily accessible to all (available on Sourceforge, under the GPL license) and to operate at the kernel level (see Table 1).

 

The DigSig Solution
To avoid reinventing the wheel, we based our solution on the existing open source project BSign, a Debian userspace binary signing package. BSign signs the binaries and embeds the signature in the binary itself. Then, at kernel level, DigSig verifies these signatures at execution time and denies execution if the signature is invalid.

Typically, in our approach, binaries are not signed by vendors, rather we hand over control of the system to the local administrator, who is responsible for signing all binaries he or she trusts with his or her private key. Then, those binaries are verified with the corresponding public key. This means you can still use your favorite (signed) binaries: no change in habits. Basically, DigSig guarantees only two things: (1) if you signed a binary, nobody other than you can modify that binary without being detected, and (2) nobody can run a binary that is not signed or is badly signed. Of course, you should be careful not to sign untrusted code: if malicious code is signed, all security benefits are lost.

How Do I Use DigSig?
DigSig is fairly simple to use. First, you need to sign all binaries you trust with BSign (version 0.4.5 or higher). Then you need to load DigSig with the public key that corresponds to the private key used to sign the binaries.

The following shows step by step how to sign the executable "ps":

$ cp 'which ps' ps-test
$ bsign -s ps-test // Sign the binary
$ bsign -V ps-test // Verify the validity of the signature

Next, install the DigSig kernel module. To do so, a recent kernel version is required (2.5.66 or higher), compiled with security options enabled (CONFIG_SECURITY=y). To compile DigSig, assuming your kernel source directory is /usr/src/linux-2.5.66, you do:

$ cd digsig
$ make -C /usr/src/linux-2.5.66 SUBDIRS=$PWD modules
$ cd digsig/tools && make

This builds the DigSig kernel module (digsig_verif.ko), and you're probably already halfway through the command to load it, but wait! If you are not cautious about the following point, you might secure your machine so well you'll basically freeze it. As a matter of fact, once DigSig is loaded, verification of binary signatures is activated. At that time, binaries will be able to run only if their signature is successfully verified. In all other cases (invalid signature, corrupted file, no signature...), execution of the binary will be denied. Consequently, if you forget to sign an essential binary such as /sbin/reboot, or /sbin/rmmod, you'll be most embarrassed to reboot the system if you have to. Therefore, for testing purposes, we recommend you initially run DigSig in debug mode. To do this, compile DigSig with the DSI_DIGSIG_DEBUG and DSI_DEBUG flags set in the Makefile:

EXTRA_CFLAGS += -DDSI_DEBUG -DDSI_DIGSIG_DEBUG -I $(obj)

In debug mode, DigSig lets unsigned binaries run. This state is ideal to test DigSig, and also list the binaries you need to sign to get a fully operational system.

Once this precaution has been taken it's time to load the DigSig module, with your public key as argument. BSign uses GnuPG keys to sign binaries, so retrieve your public key as follows:

$ gpg --export >> my_public_key.pub

Then log as root, and use the digsig.init script to load the module.

# ./digsig.init start my_public_key.pub
Testing if sysfs is mounted in /sys.
sysfs found
Loading Digsig module.
Loading public key.
Done.

This is it: signature verification is activated. You can check the signed ps executable (ps-test) works:

$./ps-test
$ su
Password:
# tail -f /var/log/messages
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps-test
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds: Found signature
section
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds: Signature
verification successful

But, corrupted executables won't run:

$ ./ps-corrupt
bash: ./ps-corrupt: Operation not permitted
Sep 16 15:55:20 colby kernel: DSI-LSM MODULE - binary is ./ps-corrupt
Sep 16 15:55:20 colby kernel: DSI-LSM MODULE Error - dsi_bprm_compute_creds: Signatures
do not match for ./ps-corrupt

If the permissive debug mode is set, signature verification is skipped for unsigned binaries. Otherwise, the control is strictly enforced in the normal behavior:

$ ./ps
bash: ./ps: cannot execute binary file
# su
Password:
# tail -f /var/log/messages
Sep 16 16:05:10 colby kernel: DSI-LSM MODULE - binary is ./ps
Sep 16 16:05:10 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds:
Signatures do not match

DigSig, Behind the Scenes
The core of DigSig lies in the LSM hooks placed in the kernel's routines for executing a binary. The starting point of any binary execution is a system call to sys_exec(), which triggers do_execve(). This is the transition between user space and kernel space.

The first LSM hook to be called is bprm_alloc_security, where a security structure is optionally attached to the linux_bprm structure that represents the task. DigSig does not use this hook as it doesn't need any specific security structure.

Then, the kernel tries to find a binary handler (search_binary_handler) to load the file. This is when the LSM hook bprm_check_security is called, and precisely when DigSig performs signature verification of the binary. If successful, load_elf_binary() gets called, which eventually calls do_mmap(), then the LSM hook file_mmap(), and finally bprm_free_security().

 

So, this is how DigSig enforces binary signature verification at kernel level. Now, a brief explanation of the signing mechanism of DigSig's userland counterpart: BSign. When signing an ELF binary, BSign stores the signature in a new section in the binary. To do so, it modifies the ELF's section header table to account for this new section, with the name "signature" and a user defined type 0x80736967 (which comes from the ASCII characters "s", "i", and "g"). You can check your binary's section header table with the command readelf -S <binary>. It then performs a SHA1 hash on the entire file, after having zeroed the additional signature section. Next it prefixes this hash with "#1; bsign v%s" where %s is the version number of BSign, and stores the result at the begining of the binary's signature section. Finally, BSign calls GnuPG to sign the signature section (containing the hash), and stores the signature at the current position of the signature section. A short compatibility note: GnuPG adds a 32-byte timestamp and a signature class identifier in the buffer it signs.

 

On a cryptographic point of view, DigSig needs to verify BSign's signatures, i.e., RSA signatures. More precisely, this consists in, on one side, hashing the binary with a one-way function (SHA-1) and padding the result (EMSA PKCS1 v1.5), and, on the other side, "decrypting" the signature with the public key and verifying this corresponds to the padded text.

PKCS#1 padding is pretty simple to implement, so we had no problems coding it. Concerning SHA-1 hashing, we used Linux's kernel CryptoAPI:

• We allocate a crypto_tfm structure (crypto_alloc_tfm), and use it to initialize the hashing process (crypto_digest_init).
• Then we read the binary block by block, and feed it to the hashing routine (crypto_digest_update).
• Finally, we retrieve the hash (crypto_digest_final).

• Only the RSA signature verification routines have been kept. For instance, functions to generate large primes have been erased.
• Allocations on the stack have been limited to the strict minimum.

The first set of benchmarks has been performed by comparing how long it takes to run an executable with or without DigSig. To do so, we used the command "time" over fast to longer executions. The following benchmark has been run 20 times:

% time /bin/ls -Al   # times /bin/ls
% time ./digsig.init compile    # times compilation with gcc
% time tar jxvfp linux-2.6.0-test8.tar.bz2 # times tar

On a Pentium 4, 2.2GHz, with 512MB of RAM, with DigSig using GnuPG's math library, we obtained the results displayed in Table 2. They clearly show that the impact of DigSig is quite important for short executions (such as ls) but soon becomes completely negligible for longer executions such as compiling a project with gcc, or untarring sources with tar.

 

Second, we measured the exact overhead introduced by our kernel module. To do so, we basically compared jiffies at the beginning and at the end of bprm_check_security. In brief, jiffies represent the number of clock ticks since the system has booted, so they are a precise way to measure time in the Linux kernel. In our case, jiffies are in milliseconds. We have run each binary 30 times (see Table 3) for DigSig compiled with GnuPG.

 

The results show that, naturally, the digital signature verification overhead increases with the executable's size (which is not a surprise because it takes longer to hash all data).

Finally, to assist us in optimizing our code, we have run Oprofile, a system profiler for Linux, over DigSig (see Table 4). Results clearly indicate that the modular exponentiation routines are the most expensive, so this is where we should concentrate our optimization efforts for future releases. More particularly, we plan to port ASM code of math libraries to the kernel, instead of using pure C code.

 

Conclusion and Future Work
We've shown how DigSig can help you in mitigating the risk of running malicious code. Our future work will focus on two main areas: performance and features.

Obviously, as signature verification overhead impacts all binaries, it is important to optimize it. There are several paths we might follow such as caching signature verification, sporadically verifying signatures, or optimizing math libraries.

From a feature point of view, we recently implemented digital signature verification of shared libraries: if malicious code is inserted into a library, all executables (even signed ones) that link to this library are compromised, which is a severe limitation. This implementation is currently in the testing phase and will be released soon.

References