How can users ssh private keys be protected from root stealing and attempting to brute force them? I cannot use selinux as the vendor will not support the app when it's in use? Thanks

  • 5
    you can't - root has access to everything - that's the risk of using someone else's server. – schroeder Jan 21 '16 at 18:32
  • root is root. On a UNIX-like system, root is god. – armani Jan 21 '16 at 18:46

Do not give the keys away from your owned and maintained hardware. If you don't have a root on your computer, user Smart Card (or Yubikey).

As already said, nothing protects your keys (or data) from physical access and root user. Not even SELinux (root can do everything, if is unconfined!). Cryptography does the job only partially (encrypted keys can be brute-forced, but it is not feasible if you have passphrase strong enough). But trusted hardware can not be brute forced and you know exactly when it is used (requires confirmation, pin, whatever).

  • Thanks yeah I was wondering if the only option was a HSM. – yeleek Jan 21 '16 at 19:03
  • It's more trusted computation platforms than trusted storage platforms that are needed. E.g. a TPM. Extra steps need to be taken to evaluate information leakage in certain contexts. And in other contexts, yes, SELinux can be enough depending on the type of incidents you expect from root and from the role policy of the system. Other approaches include experimental isolated library OSs from Microsoft e.g. Haven – Steve Dodier-Lazaro Jan 22 '16 at 0:11
  • 1
    More over. Root user can deploy a slightly modified version of any program which can simply report whatever passwords have been entered by users on the system using those programs. I.e. these can be regular programs like ssh, su etc. – Ross Jan 24 '16 at 5:41

You really do want SELinux, or an alternative such as AppArmor, SMACK, or AKARI/TOMOYO.

Take these examples from the book SELinux System Administration --

Consider the example of the shadow file again. A MAC system can be configured so that the file can only be read from and written to by particular processes. A user logged on as root cannot directly access the file or even move it around. He can't even change the attributes of the file:

root# id uid=0(root) gid=0(root)

root# cat /etc/shadow

cat: /etc/shadow: Permission denied

root# chmod a+r /etc/shadow

chmod: changing permissions of '/etc/shadow': Permission denied

This is enforced through rules that describe when the contents of a file can be read. With SELinux, these rules are defined in the SELinux policy and are loaded when the system boots. It is the Linux kernel itself that is responsible for enforcing the rules, and does so through LSM (Linux Security Modules).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.