Linux – How to limit access to the private ssh key using SELinux policies

fedoralinuxSecurityselinuxssh-keys

I'm using Fedora distro – with its preinstalled SELinux policies. I want to limit unsecured access to my private keys in ~/.ssh folder – to prevent leaking by possible malware, that may run under my account. Root-kits are out of question.

Update #1:
I want to solve an enterprise problem with newbie Fedora users – without USB tokens, etc. They may use a very weak passphrase. It will be ok, if only the root user and ssh client programs will have access to private keys. There is no need for the actual human user to see private key – I don't know the reason to look at private key, even once, for anyone.

How can I do that? Suggest using SELinux.

Best Answer

The appropriate way to hide private keys from those who are allowed to use them is a hardware security module (a smartcard or something works well). You can do this with some effort for SSH keys (a google search turns up this tutorial about it with some clunky hardware and GPG).

However, if you are worried about something that isn't a shell from getting one, bearing in mind that lots of exploits get you a shell, AppArmour can constrain filesystem permissions in this way, though I believe doing it inside home directories is a little more tricky to manage for multi-user systems.

SELinux can do this too; you put a security label on the files and only allow ssh to read them.

Bear in mind that a user is generally able to create their own SSH keys, and is usually the owner of them, meaning that they can adjust whatever labels and permissions are put. This is an assumption that exists.

If you are going to run viruses, there are some rules you can follow that will make you much safer than any of this:

  • Machines that intentionally run viruses should be somewhat isolated. Specifically, they should be unable to act as a jump box to anything. They should have limited network access (on their own VLAN), down to the bare minimum required. They should never, ever have credentials like X.509 private keys or SSH private keys on them which will allow them to authenticate to anything.
  • You need to retain the ability to rebuild these machines, offline, rapidly. This makes snapshotted VMs very appetizing for this type of research.
  • Nothing you care about should be stored on machines used to run viruses.
  • If the viruses are of your own making or their operation is under your control, wherever possible, make them inert. C&C addresses should be blackholes (192.0.2.1, an IP reserved for testing and documentation, is a good one; 0.0.0.0 can also be appropriate; blackhole.iana.org is a good DNS name). If they need to be real addresses, you can host a special testing C&C for them on the restricted network.
  • Be very careful if you use someone else's C&C and a virus you don't control. If you are doing this it is best if you do it at the local console on a separate internet connection not associated with your LAN in any way.

If you're worried about accidentally running a virus, selinux might help you, though the real solution to this is common sense and due care.

You can also protect your private keys with passwords, which causes them to be encrypted, though viruses can get your keystrokes to bypass that.

Related Topic