Operating Systems 2026F Lecture 8

Readings

The following readings are supplemental but may help you understand what has been covered in previous classes:

UNIX permissions

• Operating System Concepts, Section 13.4.2, Access control (p. 552-554)

setuid

• Operating System Concepts, Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories

• Operating Systems: Three Easy Pieces, Chapter 39: Interlude: Files and Directories

Topics

• Introduction to networking
• UNIX accounts
• password security
• Public key cryptography
• ssh configuration and usage

Video

Video from the lectures given on October 8th and 9th, 2026 are now available:

• Lecture 8A
• Lecture 8B

Unfortunately the screen capture got messed up with these, my apologies.

Notes

Lecture 8A

Lecture 8A
----------

Wooclap: ALMBSXY

Why tutorials then assignments?
 - we can grade only so much
 - but I also want to encourage you to judge whether you understand something or not

How does the Internet work?
 - postcards going this way and that

Why postcards?
 - because they show who they are from and who they are for
 - limited in size
 - "public"

What if you wanted to communicate a lot of information via postcards?
 - break up the message into postcard-sized chunks
 - number the postcards

But then what if they arrive out of order, get delayed, or get lost?
 - need some way of checking what information is missing

IP <- postcards (packets)
TCP <- strategy for getting continuous communication over IP packets,
       making sure it is reliable
UDP <- let me manage the postcards myself

So how can we protect these postcards?
 - cryptography!

Classic cryptography relies on shared secrets
 - both sides know the "password"

But a shared secret only works if both parties have been previously introduced
 - not the case on the Internet!

In the 1970's, cryptographers figured out something much more clever:
public key cryptography

public key cryptography splits the "secret" into two:
 - a public key that is shared with everyone
 - a private key that is...private


With public key cryptography, you can
 - send a secret message to anyone you have the public key for
 - verify the authenticity & integrity of a message for anyone you have the public key (check the digital signature)

Now the sharing a secret key problem - we can just send a key as a public key-encrypted message
 - but how do I know I have the right public key?


To enable passwordless login to an openstack VM
 - generate an SSH key pair
 - copy the public key (the .pub  file) to the .ssh/authorized_keys file
   on the openstack VM
 - add the key pair to your local ssh agent
   - this varies depending on your operating system, but is
     generally "ssh-add" and the private key file

The purpose of ssh-add is to add your unlocked private key to your local ssh agent
 - the idea is that you don't want to keep having to unlock your private key, but you want your private key to be protected on disk

PASSWORDS
 - so passwords are stored locally, but does that mean if someone logs into your computer they automatically know your password?
 - passwords are stored with secure hashes
   - the hash of the password is remembered, not the password
   - if you have the hash you only know the password if you guess it correctly

Lecture 8B

Lecture 8B
----------
wooclap: EUJSUZN

There are textbook resources
 - read them for contextual information

but you need to approach the material intentionally
 - I can't build a conceptual model for you


Before explaining SSH, we need to explain why we need it
So...networking

Why postcards?
 - have a sender and a receiver (source and destination)
 - limited size
 - "public" - anyone who handles the postcard can read it

packets are basically postcards
 - and that's what is sent around on the Internet

If you want to send a lot of information, that means a lot of postcards
 - what order?
 - what if one gets lost? Delayed?
 - privacy?
 - integrity (no changes)
 - authenticity (correct sender)?

The Internet was built originally with NO SECURITY
 - no privacy, integrity, authenticity

Instead it was "best effort"
 - mistakes will be made

Internet routers - think the post office

So how do we solve the security problem? By using cryptography!
 - classic cryptography is all about ciphers for encryption

symmetric key cryptography:
  plaintext + secret key => ciphertext
  ciphertex + secret key => plaintext

Old: substitution ciphers, enigma
Recent: DES
Current: AES

The challenge of symmetric key cryptography is a chicken & egg problem:
 - how do you share a key?

Solution: public key cryptography

public key cryptography:
  plaintext + public key => ciphertext
  ciphertex + private key => plaintext

public and private key are a matched pair that are generated together

But how do I make sure things haven't been changed in transit?
 - integrity, authenticity?

secure hash functions
 - generating hashes from a document are easy
 - finding a document with a given hash is hard

So if I have the hash of a document and the hash is correct, I know I got the right document

But then, how do I know I got the right hash?

public key cryptography (digital signature):
  hash + private key => signature
  signature + public key => hash

To check a signature of a document:
  compute hash(document)
  hash(document) ?= hash from signature

If they match, then document is authentic (came from owner of key) and hasn't been changed

(don't implement your own cryptography!)

So how do I know I have the right public key for someone?
 - well, we can just use digital signatures again!

certificate: public key + metadata (name, expiration, etc)

setuid bit
 - goes with the execute bit
 - when execve is run, makes the euid of the process the uid of the executable

euid: effective uid, the real uid the kernel uses to decide access

normally uid=euid for a process, but setuid lets this change