Add February introduction to Linux presentation.
This commit is contained in:
parent
b45ed93191
commit
bff72f1700
2 changed files with 264 additions and 0 deletions
107
2021-02-15-introduction-linux/linux_introduction.txt
Normal file
107
2021-02-15-introduction-linux/linux_introduction.txt
Normal file
|
@ -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
|
157
2021-02-15-introduction-linux/linux_introduction_handout.md
Normal file
157
2021-02-15-introduction-linux/linux_introduction_handout.md
Normal file
|
@ -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 a new issue