hashbrowncipher

#!/usr/bin/fakeroot /bin/bash
set -o errexit
set -o nounset
set -o pipefail
OUTFILE=$2.squashfs
TMPDIR=$(mktemp -d -p .)

cleanup() {
  rm -fr $TMPDIR
}

hashbrowncipher

#!/bin/bash
# Depends on zstd (>1.3.6) and aws-cli
set -o errexit
set -o nounset
set -o pipefail

# Set kernel.core_pattern = | coredump_uploader.sh %P %s %E
PID=$1
shift
SIGNAL=$1

hashbrowncipher

I have been categorizing enclaves into a hierarchy:

• Level 0 (secret storage): allows you to store and retrieve the secret
• Level 1 (identity verification): checks who you are, then performs an operation on the secret
• Level 2 (policy enforcement): checks who you are, what you are doing, and then performs an operation on the secret

hashbrowncipher

import os
import socket
import sys
import Pyro5.api
import Pyro5.server
import pyseccomp as seccomp
import serpent


@Pyro5.server.expose

hashbrowncipher

This post is for people who have already decided that layer 7 authN/Z controls are right for their needs. This leaves the question of whether it's worth deploying a separate layer 3 control, like a VPN. Defense in depth is good, right? Who can argue with a belt-and-suspenders approach?

My general thought is that a belt-and-suspenders security measure is always a good idea if the cost of maintaining it doesn't result in underinvestment in any other security control. We can divide this cost into two categories:

1. opportunity cost
2. psychological cost

hashbrowncipher

Nonces are bad and we should stop using them

Once upon a time, there were Feistel ciphers. Because of Feistel ciphers, we got used to (1) block ciphers with (2) key schedules. This was a bad idea, but we didn't know better at the time.

Why was it a bad idea?

Block ciphers were a bad idea because they are required to be invertible: you must be able to unambiguously decrypt everything that you encrypt. This,

hashbrowncipher

Eden Sizing

There are limits to the size that Eden is allowed to be. Those limits are calculated in calculate_default_min_length:
G1YoungGenSizer::recalculate_min_max_young_length -> G1YoungGenSizer::calculate_default_min_length

G1CollectorPolicy::update_young_list_target_length is responsible for
determining the actual size of the young list. If doing a young GC, it will
call G1CollectorPolicy::calculate_young_list_target_length. This function
attempts to find the largest eden size that will allow (predicted) GC pauses to
remain under the pause time target. Presumably after a certain eden size, there

hashbrowncipher

I had a bad brush with the single version rule at work, and I’d like to warn you so that you can avoid the pain it caused me.

The best thing about monorepos

The best thing about monorepos is that they require the author of any given change to make the entire repository’s tests pass before committing that change. This puts the onus of managing incompatible changes on the original author, which:

1. Centralizes the responsibility of solving incompatibilities onto the person or team with the most knowledge of the change.
2. (In the best case) exposes any incorrect assumptions they may have about their change early-on in the process.

Largely as a result of the above property, monorepos obviate most of the overhead around dependency versioning. When dependencies are consumed at HEAD, it is no longer necessary to maintain separate artifact versioning, and the build and release pipelines for intermediate artifacts (e.g. base images, lib

hashbrowncipher

tl;dr: If you run apt-get install reproducibly, there's no reason to use "golden images".

Background (about me)

I've now run into the "how do we manage and update a base operating system" problem at three different roles over the course of many years. At each role, my colleagues and I landed on a reproducible installations using apt . Fair warning: the rest of this post will be apt flavored, although I hope that the general lessons will be useful for any operating system.

The most advanced incarnation of this system used Bazel as part of a monorepo to provide automated upgrades for hundreds of individual services. In that incarnation, it was possible to build new container images that remediated a given CVE org-wide in a single commit, which was very useful for me as a security engineer.

What are golden images?

hashbrowncipher

One of my favorite talks from fwd:CloudSec this year was Jarom Brown's AWS Presigned URLs: The Good, The Bad, and the Ugly (abstract). In his talk, Jarom demonstrates a way to use javascript within an unsuspecting user's browser to make requests to AWS. Because most AWS services provide their APIs over HTTP, he was able to use standard browser-side facilities (e.g. XMLHTTPRequest, fetch()) to synthesize requests to AWS, and then exfiltrate their responses to a server he controlled. This is most relevant in a post-compromise context, where an attacker has access to a victim's AWS keys, and gives the attacker lots of leeway for disguising or changing the source IP address presented to AWS.

The first question on my mind was "I thought CORS was supposed to stop this. Why didn't it?". It looks like the answer is that most AWS services are very happy to send an Access-Control-Allow-Origin: * header. For