Ishimoto Shinobu basedjakfan2

Building a Secure Arch Linux Device

Locking down a linux machine is getting easier by the day. Recent advancements in systemd-boot have enabled a host of features to help users ensure that their machines have not been tampered with. This guide provides a walkthrough of how to turn on many of these features during installation, as well as reasoning for why certain features help improve security.

The steps laid out below draw on a wide variety of existing resources, and in places I'll point to them rather than attempt to regurgitate full explanations of the various security components. The most significant one, which I highly encourage everyone to read, is Rod Smith's site about secure boot, which is the most comprehensive and cogent explanation of UEFI, boot managers and boot loaders, and secure boot. Another incredibly useful resources is Safeboot, which encapsulates many of the setup steps below in a Debian application.

SSH keypair setup for GitHub (or GitHub/GitLab/BitBucket, etc, etc)

Create a repo.

Make sure there is at least one file in it (even just the README.md)

Generate a SSH key pair (private/public):

ssh-keygen -t rsa -C "[email protected]"

security and hardening options for systemd service units

A common and reliable pattern in service unit files is thus:

NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
DevicePolicy=closed
ProtectSystem=strict

Bootstrapping Rust and Cargo on FreeBSD/aarch64

At the time of this writing, Rust and Cargo are available on FreeBSD/amd64 and FreeBSD/i386 only, whether it is from rustup or from the FreeBSD ports tree. Here is how I could bootstrap Rust and Cargo for FreeBSD/aarch64 from FreeBSD/amd64.

Base system for the target

To be able to cross-compile anything, you need a userland for the target.

From a release

NOTE: This was first authored on 26 Feb 2014. Things may have changed since then.

C++'s Templates

C++'s templates could be seen as forming a duck typed, purely functional code generation program that is run at compile time. Types are not checked at the initial invocation stage, rather the template continues to expand until it is either successful, or runs into an operation that is not supported by that specific type – in that case the compiler spits out a 'stack trace' of the state of the template expansion.

To see this in action, lets look at a very simple example:

template

	#!/bin/sh

	# Download binutils, gcc, the linux kernel, glibc

	# define the prefix
	export PREFIX=/opt/armhf

	# change PATH to include the target directory
	export PATH=$PREFIX/bin:$PATH

	while {
	let x = foo();
	bar(x);

	x != 0
	} {}