2 changed files with 264 additions and 0 deletions
@ -0,0 +1,107 @@
|
||||
Linux |
||||
|
||||
Joachim Desroches |
||||
|
||||
BIG FAT WARNING |
||||
Craft v.s. Science |
||||
|
||||
1. Linux: About and Philosophy |
||||
2. Shell |
||||
3. Asymmetric Cryptography |
||||
4. SSH and PGP |
||||
5. Git |
||||
6. Practical tools |
||||
|
||||
1. Linux |
||||
|
||||
kernel |
||||
|
||||
# Linux is actually only the kernel, and needs a bunch of userland utilities |
||||
# to be of any use. Usually though, when we say linux, we mean the whole OS. |
||||
|
||||
operating system |
||||
|
||||
# Additionally to interacting with the hardware, it comes with the usual |
||||
# facilities we expect of an OS: compiler, user management, logging... |
||||
|
||||
(em)power users |
||||
|
||||
# General purpose, but of philosophy aimed at power users. Know what you are |
||||
# doing, think before you type, read the docs. |
||||
|
||||
files |
||||
|
||||
# Most powerful concept is that everything is a file. Indexed in the FSH, and |
||||
# can be accessed and manipulated that way. Example: disk, serial port. |
||||
# config!! |
||||
|
||||
distributions |
||||
|
||||
# Names like ubuntu, Alpine, Debian are distros. Usually represent a package |
||||
# manager and a usage philosophy. |
||||
|
||||
2. Shell |
||||
|
||||
# -> GNUGEN's presentation |
||||
|
||||
3. Asymmetric Cryptography |
||||
|
||||
secret + key > encrypted |
||||
encrypted - key > secret |
||||
|
||||
share key |
||||
|
||||
public key |
||||
private key |
||||
|
||||
secret + public key > encrypted |
||||
encrypted - public key > garbage |
||||
|
||||
encrypted - private key > secret |
||||
|
||||
RSA, ECDSA |
||||
|
||||
signing |
||||
|
||||
secret + private key > signature |
||||
signature - public key > valid! |
||||
|
||||
5. SSH and PGP |
||||
|
||||
# Main crypto usage in our tooling |
||||
|
||||
PGP: Pretty Good Privacy |
||||
GPG: GNU Privacy Guard |
||||
|
||||
# We'll go into GPG if we have time and interest, for now let us stay on SSH. |
||||
|
||||
SSH: Secure SHell |
||||
|
||||
remote access |
||||
|
||||
authentication keys |
||||
|
||||
private & public SSH keys |
||||
|
||||
# Give the server your public, and show you can decrypt the challenge |
||||
|
||||
some policy |
||||
|
||||
# Secrets are important! Don't let them be stolen |
||||
|
||||
password-protected accounts |
||||
encrypted hard drives |
||||
|
||||
# I'd say that's good enough for us for now. More would take too much |
||||
# resources to enforce. Ideally, password-protect with something in your head |
||||
# or your password manager. |
||||
|
||||
5. Git |
||||
|
||||
# -> GNUGEN's presentation |
||||
|
||||
6. Practical tools |
||||
|
||||
PuTTY, WSL - SSH for windows |
||||
|
||||
gitforwindows.org |
@ -0,0 +1,157 @@
|
||||
--- |
||||
author: Joachim Desroches |
||||
date: 2021-02-15 |
||||
fontsize: 11pt |
||||
geometry: margin=2.5cm |
||||
keywords: |
||||
- Linux |
||||
- e-Durable |
||||
lang: en-US |
||||
mainfont: Times New Roman |
||||
papersize: A4 |
||||
subject: Linux usage and administration |
||||
subtitle: Simple and Effective Tools |
||||
title: Linux and Tools Introduction |
||||
toc-depth: 2 |
||||
toc: true |
||||
... |
||||
|
||||
\pagebreak |
||||
|
||||
# About Linux |
||||
|
||||
## Big fat warning |
||||
|
||||
As I'm sure you all know, system administration is a craft and not a science. It is made up of accumulated knowledge, |
||||
empirical rules and experience. I give a high-level overview of the most important concepts I could think of over the WE |
||||
here, but only though usage, habit and trial and error can anyone get fluent in *nix. This doesn't mean you shouldn't |
||||
read the fine manual though :) |
||||
|
||||
## Linux is a Kernel |
||||
|
||||
Linux is actually only the kernel, and needs a bunch of userland utilities to be of any use. Usually though, when we say |
||||
Linux, we mean the whole OS, so including the usual additional facilities we expect: logging, user and privilege |
||||
management, compilers... |
||||
|
||||
Though you can build it to be anything, the main philosophy change between Linux and windows/MacOS - or rather, between |
||||
windows/MacOS and everything else - is that we don't take users for idiots. Think before you type, because your actions |
||||
are powerful and irreversible. If you remove a file, it is lost. If you have the permission to do an action, the system |
||||
will neither warn nor stop you. It is expected that you read and understand the documentation. Once you are used to |
||||
this, you find the safeguards and child barriers on common desktop OSes to be an absolute PITA! |
||||
|
||||
## Everything is a file |
||||
|
||||
The most powerful concept in the *nix philosophy is that everything should do one thing and do it well. This is not the |
||||
subject of this paragraph. |
||||
|
||||
The second most powerful concept in *nix is that everything is a file. Disks, network sockets, serial and USB ports, and |
||||
all the physical and virtual resources the system has access to is represented as files. This means that you can treat |
||||
the contents of a disk like the contents of a text file, and that the same simple mechanisms provided by the kernel can |
||||
be reused everywhere in system programming. This makes code readable and palatable. |
||||
|
||||
In a similar design fashion, most tools in the \*nix world are configured using a *configuration file*. Several syntaxes |
||||
exist, but are usually one form or another of key-value store. This is the reason why you see « hackers » always going |
||||
around in text interfaces: in the *nix world, [your text editor is your mollusc](https://i.pinimg.com/originals/62/94/21/62942194e24eae5f38dceee5f1a3a2fc.jpg). |
||||
Different editors exist: you'll probably encounter nano and vim at some point in your career. Vim takes some time to |
||||
learn but is really nice to use, nano is very simple and easy to use. |
||||
|
||||
## Distributions |
||||
|
||||
Names like Ubuntu, Alpine, Debian are *distributions* of the GNU/Linux operating system. Usually, a distribution is |
||||
tied to a package manager (a way to distribute software) and a design / usage philosophy. Debian makes a rock-solid OS |
||||
with tried and tested software, Ubuntu strives to be user-friendly, making the beaten track easy and anything else a |
||||
pain, and Alpine is a minimal system that gives maximal control to the user. They all use the same kernel, but come with |
||||
different pre-installed mechanisms and software. |
||||
|
||||
# The Shell |
||||
|
||||
The shell is the program that presents you with a prompt containing some (configurable) information, munches the text |
||||
you type it and *interprets* the *commands* represented by what you typed. Several exist, but you're probably good |
||||
sticking with `bash(1)`. A command is modified by the context in which it is run: the current working directory |
||||
(obtained through `pwd`, modified with `cd`) and the environment variables (obtained through `env`, modified with `set` |
||||
and `export`). The command you typed is executed in this context and passed the rest of your line as *arguments*, which |
||||
can be both (long and short) flags, or actual data to munch (numbers, file names, gibbering magical incantations). |
||||
|
||||
Shells also come with a scripting language, a minimal programming language consisting of the usual control facilities |
||||
(if/else, while, for) and mechanisms to chain commands (`||`, `&&`, `|`, `;`). Scripts are either executed through the |
||||
interpreter directly (`sh myscript.sh`) or contain a shebang to tell the computer how to execute it (`#!/bin/sh`). |
||||
|
||||
You manipulate directories and files using `cd`, `ls`, `mv`, `cp` and text editors. You become administrator using |
||||
`sudo`, and read the fine manual using `man`: so the manual's manual is `man man`. |
||||
|
||||
# Asymmetric Cryptography |
||||
|
||||
In traditional cryptography, one or more parties hold a key, used to encrypt and decrypt the secret. However, this poses |
||||
the question of how to securely distribute the keys. Various methods have been used throughout history, up to the naval |
||||
codebooks used as the subject of so many WWII submarine war movies. However, these solutions were never really |
||||
practical. |
||||
|
||||
A solution to this discovered in the second half of the twentieth century is asymmetric cryptography. I'll skip the |
||||
mathematical details, you can go readup on RSA if you're interested, it's just a super smart application of high-school |
||||
arithmetic using primes and moduli. This time you have two keys, a public and a private one. It is *hard* to derive one |
||||
from the other, but they are linked in such a way that if you encrypt something with one, you can decrypt it with the |
||||
other (and only the other). Therefore, everyone wanting to encrypt something to you can encrypt is using your public |
||||
key, and only the holder of the private key, i.e. you, can decrypt it. Inversely, if you encrypt something with your |
||||
private key, e.g. the hash of a message to act as a signature, then people can use your public key to verify the claim |
||||
that you own the private key. |
||||
|
||||
For the longest time, we've used the RSA algorithm to provide this (factoring prime numbers as I mentioned above). In |
||||
the recent years, elliptic curve cryptography has gained some traction, usually seen as ECDSA. It achieves better |
||||
security with much fewer bits and work from the computer: if you have a choice, use ECDSA or ED25519 for your keys. If |
||||
using RSA, use 3072 bit size (2048 not enough, 4096 too much). But really, use elliptic curves. |
||||
|
||||
You can also authenticate (sign) data by encrypting it (or a hash of it, which is more practical) with your private key: |
||||
people can check using your public key that you do indeed own the associated private key, which is how we identify |
||||
people on the internet (your identity = knowledge). |
||||
|
||||
Note that asymmetric cryptography is both slower and weaker than symmetrical crypto, which is why most protocols use |
||||
asymmetrical cryptography to authenticate, and then exchange session-wide symmetrical keys for encryption. See a HTTPS |
||||
certificate for example, the Wikipedia page on TLS, &c... |
||||
|
||||
# SSH and PGP |
||||
|
||||
The two main places where we use cryptography in our tooling is SSH and PGP. |
||||
|
||||
## PGP |
||||
|
||||
PGP stands for Pretty Good Privacy and is a way to authenticate and encrypt files; mostly we use it to secure our |
||||
emails. You can generate a PGP key using thunderbird and send it to people. You'll be able to receive encrypted emails |
||||
from people who own your public key, verify signatures of people of whom you own the public key, as well as sending |
||||
encrypted emails to them. |
||||
|
||||
## SSH |
||||
|
||||
SSH is the Secure SHell, and is a remote access protocol to get a shell on a remote machine you can internet to. It uses |
||||
asymmetrical cryptography to authenticate servers (against DNS spoofing / ARP poisoning). It knows several mechanisms to |
||||
authenticate users to the server, dumbly a user/password combination, better a user/keypair combination. You keep your |
||||
private key secure on your laptop, copy the public key to the server, and it can then check that you own the key that |
||||
you claim you own (identity = knowledge). On Windows, you can use the PuTTY generator to generate an ED25519 key for |
||||
yourself. Save the public and private keys someplace on your drive that you'll remember: you'll need to access the |
||||
public key to copy it to servers you are supposed to access. |
||||
|
||||
## Policy |
||||
|
||||
Secrets are important! Don't let them be stolen. Considering our current size, threat model and device policy, my |
||||
security recommendations are: |
||||
|
||||
* security keys (PGP & SSH) will only exist on an individual work device (your laptop). They will be tied to one person |
||||
(you) and you will be held accountable for anything happening using that key. This means no copying of the key on |
||||
OneDrive or AppleCloud or whatever! |
||||
* You will use the security mechanisms your OS provides to lock your session automatically and use a strong, mandatory |
||||
session password. This is CRITICAL. |
||||
* Your drive will be encrypted using Bitlocker for Windows, the APFS crypto volume mechanisms on MacOS and LUKS in |
||||
Linux. This is CRITICAL. |
||||
* Password-protection of the keys is optional but recommended with the above rules. |
||||
|
||||
Bus-factor considerations for access keys are currently being discussed by our technical security consulting team |
||||
(a.k.a Tim and I). We'll get back to you on that. |
||||
|
||||
# Git |
||||
|
||||
Git is a text version tracking system, saving you from version hell. There are plenty of very well done documents on git |
||||
out there, just know that it exists and that tracking changes by hand is dumb and must cease. It also helps to share |
||||
work done on common files, using [code.recycled.cloud](https://code.recycled.cloud). You can use |
||||
[gitforwindows.org](gitforwindows.org) if you use that OS, or just install git using `brew` or whatever package manager |
||||
is available for your platform. Compile it with butterflies if you like XKCD. |
||||
|
||||
That's all folks! |
Loading…
Reference in new issue