Process identity checks

With the term “identity of a program” we refer to a compact data set which can be used to securely and reliably distinguish a program from any other program. In the simplest case this can be a cryptographic checksum over the program’s code, but it can also be based on the program’s code signature.

Note that the term “program” used here describes applications like Safari, as well as plain executables like /sbin/ping. Once executed, all those executables become "processes" and Little Snitch verifies the identity of those running processes.

What is the purpose of identity checks?

Let’s pretend you have an application that requires a lot of internet connections, e.g. a web browser, a Bittorrent client or something similar. You have created a rule which allows any connections for it. Then pretend that another program with malicious intent has collected information on your computer, e.g. passwords from key logging, your contacts information or similar. How can the malicious program send this information back to its master? It can check whether Little Snitch is installed, but it cannot add, modify or read rules. However, instead of modifying rules, it could hijack the rules of another program by replacing that program’s code with its own. It would search for your web browser, move the browser’s executable code out of the way and copy itself to its position. Since Little Snitch rules match the on-disk path of programs, it could use the Allow-rule for any connection.

In order to prevent this hijacking of rules, Little Snitch stores a Code Requirement for every known program to check its identity. This requirement consists of a compact set of properties which securely identify the program. If a running process does not meet the requirement, an alert with a warning is shown and rules are not applied.

How does the identity check work?

When checking the identity, we want to accept all instances of the original program, and if possible, also accept legitimate upgrades of the program. The latter is only possible when the identity check is based on the code signature.

Programs without valid code signature

If the program has no code signature or if it is not cryptographically valid (the code or signature has been tampered with), we cannot use it to identify the program. In this case we make a cryptographic checksum (SHA256) over the program’s executable code. Every time a new instance of the program is launched, Little Snitch computes this checksum and compares it to the value originally stored.

Programs signed by Apple

Apple code-signs all components of the operating system. The signature contains an identifier of the program. Checks for programs signed by Apple require that:

The program is signed by Apple.
The identifier is the same as originally seen.

By storing the identifier, we can detect when an Apple-provided program is replaced by another Apple-provided program with different capabilities, e.g. if a program is replaced by a script interpreter such as Python. Script interpreters can be used to perform any operation (including network access) on behalf of another program, including malicious programs.

Programs signed by a registered developer (Developer ID)

Apple issues code signing certificates to registered developers. When Apple issues a certificate, they ensure that the certificate contains the name of the developer and a Team Identifier, uniquely identifying the developer. When a program with this type of signature is encountered, Little Snitch requires that:

The program is signed by a registered developer or by Apple.
The Team Identifier is the same as originally seen.
The program’s identifier is the same as originally seen (see “Programs signed by Apple” above).

By allowing signatures by Apple, it is possible to swap App Store versions of an application with developer-signed versions.

Programs signed by Apple for the App Store

Applications downloaded from the App Store are signed by Apple, not by the original developer. That’s because Apple needs to make final adjustments before shipping. App Store applications can be distinguished from operating system components by the kind of certificate that was used to create the code signature. For programs with this type of signature, Little Snitch requires that:

The program is signed by a registered developer or by Apple.
The Team Identifier is the same as originally seen.
The program’s identifier is the same as originally seen (see “Programs signed by Apple” above).

By allowing signatures from registered developers, it is possible to swap App Store versions of an application with developer-signed versions.

Programs with ad-hoc signature

A so-called ad-hoc signature is not really a code signature. There is no signer and no signer certificate, but a cryptographic checksum of the code is stored. Ad-hoc signatures use the same infrastructure as real code signatures in the operating system’s kernel. They can therefore detect in-memory modifications instantaneously. SHA256 sums made for unsigned code are similar, but the checksum is only checked once when the program starts. For this type of check, Little Snitch stores the program’s Code Directory Hash, a kind of checksum, over the executable’s code.

Programs signed with a third party certificate

When Apple issues a code signing certificate, they (kind-of) guarantee that the information stored in the certificate, in particular the name and Team Identifier of the developer, is correct. If a certificate is not issued by Apple, the certificate information cannot be trusted. For this type of signature, Little Snitch requires that:

The program is signed with the same private key as originally seen.
That the program’s identifier, if available, is the same as originally seen (see “Programs signed by Apple” above).

The private signature key is a secret known by the signer only. By checking this key, we ensure that the program is from the same developer and upgrades of the program can be accepted, at least until the developer generates a new key.

This type of check is also applied to self-signed certificates.