0

AFAIK, the few ways private information from gpg can get leaked to other users on a shared Linux machine is:

  1. someone with root access can access gpg's files

  2. someone with root access can access gpg's process memory

  3. gpg process's pages could get swapped out on disk, and anyone driven enough can access that

So, some related questions:

a) Can enabling features like SELinux fully address all 3 problems listed above?

b) As the system will have 1 user who could enable/disable SELinux, does this just shift the problem from notorious root user to notorious SELinux admin? If yes, is the latter a lesser evil than the former.

c) If a/b doesn't make sense to harden security for individuals using gpg on a shared Linux machine, is there another security hardening approach such that no user (including notorious admin/root) sees another user's secret?

Please feel free to correct if my understanding is too simple or inaccurate.

2 Answers 2

1

If you assume that even the system administrator is malicious, then the only way to protect the private key is to keep it away from the machine entirely and instead store it on a separate device like a smart card with its own cryptoprocessor or a hardware security module. This prevents raw access to the key. However, it does not prevent an admin from reading or manipulating the data that is exchanged between the shared machine and the external device. For example, if you decrypt an e-mail on the machine, then the admin can read the plaintext as well. Even worse, they can send different ciphertext to the device and trick you into decrypting it for them. And if you sign data, you cannot tell whether you're actually signing the data displayed on the screen.

SELinux is very useful for locking down users (even root), but it cannot protect against a malicious system administrator. As you correctly pointed out, an administrator could simply turn off SELinux or interfere with its operations at the kernel level. For SELinux to make sense, you have to assume that at least the admin is not a malicious actor.

1

A possible approach would be to boot from a live USB key, for example Tails - provided that USB boot is not disabled in BIOS/EFI. Then you do not use the installed system at all.

As hinted by @Ja1024 you could store your private keys on a smart card. Then use a smart card reader with its own pinpad, so that a keylogger cannot intercept the PIN.

Some attacks are still possible in theory. A hardware key logger could intercept your keystrokes including passwords. A rogue EFI image could also defeat your protections, booting your OS into a malicious environment.

Even if you don't trust the admin, you still need to have some trust in the hardware.

I would never use GPG on a shared computer, only on my own dedicated machine. At the very least it makes sense to use a smart card or even a Yubikey, so that your private keys do not reside on the host file system. Then, your remaining concern is man in the middle attacks that are not so easy to implement.

1
  • Booting from a live USB stick is not an option. Regarding "do not use the installed system at all" defeats the whole point of the question. The question here is to harden gpg usage on Linux (perhaps as much as possible), not to do amnesic communication from another computer/OS instance.
    – aackmann
    Mar 31 at 2:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .