Access Control on my Mind

I just started watching Westworld for the first time. Yes I know I’m late to the party, but such a show is a dangerous thing for me since I’ll binge all available episodes in one shot if given the chance.

I loved the first season overall, but a scene from Season 1 Episode 9 stood out to me (Spoilers for Season 1 below!)

In the scene, Bernard requires Dr. Ford’s approval in order to access his own earliest memories. As a security guy I found this compelling. How does one go about implementing an access control system for someone else’s mind?

The Bank Pin Setup

One toy problem setup is as follows:

  1. I start a savings account for my future child.
  2. When they are old enough to remember, I give them the bank pin but XOR’d with another number.
  3. I promise to give them the second number when they turn 18.

Note: in this toy problem we must ignore the simple approach of asking a gullible bank attendant for your PIN. I expect my future child to be quite charming so this is a legitimate and effective strategy.

Upon completion, I have stored a value in my child’s memory (saving on my own limited mental capacity) and they require my assistance to access it.

How does this work for Hosts?

Bernard being a walking computer (SPOILER) definitely makes this setup even more feasible. Perhaps there is a secure enclave built within him that immediately encrypts all memories? Or more simply Dr. Ford can just extract, encrypt and reinsert Bernard’s memories during a maintenance session.

The Split Personality Setup

A more interesting question for humans is how could I hide information from another personality residing in my mind? If I knew my alternative personality lacked patience, I could encode the encryption key in some kind of puzzle.

Funnily enough, I’ve already successfully tested this theoretical approach. Being clever and distrustful, past Michael (me but referred to in third person to emphasize the difference in personality) decided to save his Ledger seed phrase in a random permutation and encrypt that permutation order with a long phrase secured by a puzzle. This way anyone with the physical backup would still need one more step in order to get my paltry crypto assets (literally not worth much more than the Ledger itself).

Surprise surprise, while I had tested this recovery two weeks after implementing it, I recently revisited it and found I no longer knew how to decode the garbage I had written down. Cue an annoying migration of assets to a temporary wallet.

Verdict: Westworld is accurate, humans can hide knowledge from themselves in their own mind, I’m always too clever for my own good.

Advertisement

ecryptsfs and ssh don’t play nice together

I encountered the most aggravating issue today. My zeal for security combined with my lack of understanding was my downfall.

Recently I bootstrapped a server with a fresh Ubuntu installation. When asked if I wanted to encrypt my home directory, I didn’t hesitate for a second. No baddie was pulling my files off my disk, no hell no.

When ungodly winds struck LA last weekend, the power went out. Nine times out of ten, any wind over 15mph and LA’s grid is struggling.

So I turn this machine on again, and go to SSH in. It prompts me for my password.

Strange, I absolutely had my public key installed on the server.

I ran ssh-copy-id again for good measure.

Same problem.

I scoured Google with vague terms “SSH public key still prompts for password send help”

And then it worked! I ran ssh and it logged me in smoothly, no-hassle, as God intended.

Did I fix it? Take Note: When something works without any change to the system, no you did not fix it. I’m looking my fellow programmers dead in the eyes right now.

I carried on, logged out and tried again. Once again prompted for the password.

OH I logged out of all my sessions! I could only SSH with public key authentication when I was already logged in with a separate session.

What the devil is this bullshit … ecryptfs … my home directory was only decrypted and mounted when I had an active login session.

Where do SSH keys live by default? /home/user/.ssh/authorized_keys.

 

SSL for Everything Else

Last post I mentioned how easy it was to setup SSL with AWS Certificate Manager.

But what about all your other servers? Are we going to cough up $16 per year for a single-domain SSL certificate from Gandi?

Negatory.

Let’s talk about Let’s Encrypt. I downloaded their Linux version and got down to business.

Here is a running tally of my steps.

  1. Google “nginx letsencrypt” and find this DigitalOcean guide.
  2. Stop my nginx server to free up port 80, which is used in the letsencrypt process.
  3. run $ ./letsencrypt-auto certonly –standalone
  4. Enter my domain name.
  5. Make 15 seconds worth of changes to my server blocks in nginx.
    1. Redirect port 80 -> 443
    2. Setup a block for port 443 SSL, all in the guide
  6. $ sudo service nginx start

It took 5 minutes to fully setup.

I love it when life is stupid easy.

Silly Security

No one gives a shit about my servers. They host a few funny sites and services mostly for personal consumption.

But recently I made the mistake of reading the details of the security update offered for my Mac.

So I set off to secure my shit once!

High Level Strategy:

  1. No more password authentication on my front-facing servers, ssh key auth only from a single control server.
  2. Design a hardened login scheme for the central control server.

Central Server Login Scheme:

Normal Setup

  • Create “intendeduser”, my user for personal, everyday activity.
  • Add “intendeduser” to sudoers
  • Install fail2ban, which mitigates brute force attacks to some extent.
  • Disable root login

Tiered Users

I made a duplicate of the nobody user, somebody:

$ useradd somebody -d /nonexistent -s /bin/sh

The somebody user would have no privileges, and would simply serve as the first stage in a 2-stage auth scheme. Remotely, you could ssh in as “somebody”, but no other user. A second ssh intendeduser@localhost would be required to complete the login as the intended user.

This was accomplished by adding the following to my /etc/ssh/sshd_config file:

AllowUsers somebody intendeduser@localhost

This allows “somebody” to ssh in from anywhere, but only allows us to ssh in as “intendeduser” locally.

Note: I wonder if localhost doesn’t actually guarantee local access only. I’ll investigate more later.

Issues

The “somebody” user still has a significant amount of access. He/she can browse and read the majority of the files on the machine. Guessing the “intendeduser” would be pretty trivial.

In my next post, I’ll discuss a solution using a chroot jail!

Possible Improvements:

Quick list of things that came to mind

  • Two-Factor authentication using a PAM (Pluggable authentication module)
  • Switch ssh port (I didn’t just for convenience)
  • Limited login time before “somebody” user is automatically logged out