bo.x0.rs

From Hack Manhattan Wiki

Superseded by Rack Manhattan

bo.x0.rs is Hack Manhattan's in-house minimalist hackerspace-tinker-tolerant bullshit cloud running on a kindly donated ThinkPad T410, so far without backups.

Why: ease communal development of space projects (ex: hmbot dev deployment), trying out Linux software, run space related services like VPN, space webcam proxied (for security and logs), dropboxes for members (nextCloud?), etc. Some of the architecture decisions are inspired by Qubes OS

For work in progress, see the git repository.

Implementation

Status: the management container does not exist yet, functionally speaking. Unpriviliged containers and some of the planned services are operational though - kindly assembled by manual labour. No IPv6 setup yet.

Host

Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz
MemTotal: 8028864 kB                                                                                                                                                                                                                                                       
/dev/sda: 111.8 GiB (SSD)
/dev/sdb: 931.5 GiB (USB HDD)
Ethernet: f0:de:f1:03:00:0f (Wake-on-LAN enabled)

Host Network

There is a bridge setup letting guest containers get DHCP addresses (IPv4 & IPv6). Additionally there are:

  • 10.8.0.0/24 - OpenVPN addresses, bridged and routed via 192.168.42.103. Can reach everything in the space and vice versa.
  • 10.133.7.0/24 - isolated. Can be reached, but can't reach anything on the HM network itself. Exception: may use Tor via SOCKS on 10.133.7.1:9050 for system updates. For very elite projects.
  • 10.0.59.1/24 - torified. Transparent proxying via Tor. Can be reached, but will route all traffic via Tor. For paranoid projects that need internet.
  • 10.0.93.0/24 - virtual network routed via 192.168.42.100. Depricated.

Current containers

  • web 192.168.42.104 & 2001:470:8b1c:0:216:3eff:fe10:ff03
    • Hosts Sousveillance
    • Proxies the camera
    • Proxies clickycloud, minio and git for use from outside the space
  • vpn 192.168.42.103 & 10.8.0.1 & 2001:470:8b1c:0:216:3eff:fe10:ff02
    • OpenVPN for access to the space network (and its regular internet connection) from afar.
      • Currently no automatic user-making process. Bug mz for an account.
  • management 192.168.42.101 & 2001:470:8b1c:0:216:3eff:fe10:ff01
    • Still in development
  • hmbot 10.0.93.5
    • Defunct
  • clickycloud 192.168.42.105 & 2001:470:8b1c:0:216:3eff:fe10:ff05
    • Hosts https://cloud.bo.x0.rs/, Nextcloud based digital storage for HM members/bo.x0.rs users.
      • Meant for: personal digital storage, shared group folders (for projects, photos etc.)
      • Soon: User accounts (and their passwords) are shared with the management container
      • Current: if you want access, send your desired username to mz (Slack, E-Mail, whatever you prefer)
  • minio 192.168.42.107 & 2001:470:8b1c:0:216:3eff:fe10:ff89
  • dns 192.168.42.106 & 2001:470:8b1c:0:216:3eff:fe5e:1fa9
    • A Bind9 host that provides internal name records for *.bo.x0.rs.
    • Hosts Hesiod style records for convenient access to communal networked infrastructure (logging in with your own usernames and keys rather than sharing a password)
  • git 192.168.42.109 & 2001:470:8b1c:0:216:3eff:fe5e:201a
  • teletron8000 192.168.42.108 & 2001:470:8b1c:0:216:3eff:fe5e:e2ee
    • Hosts Figment/Maker Faire Phone games locally!

"Specification"

Management Container

  • Pull SSH keys and username from https://wiki.hackmanhattan.com/index.php?title=User:$username/ssh&action=raw pages on the wiki, where $username is filtered by a whitelist only editable on the host (kind of inspired by Noisebridge's pony (RIP) but less permissive)
    • Probably TOFU, manually approve changes pulled from the wiki? In case the Wiki gets compromised
  • User passwords are expired on account creation so that on first login via SSH key users are forced to set their own password
  • Users are allowed to create new minimal Debian stretch containers and can choose from different network setups (default: IPv6 on)
    • Static IPv4 allocation
    • NAT
    • Static IPv4 allocation + Tor (IPv6 outgoing off)
    • Tor (IPv6 outgoing off)
    • Isolated (incoming IPv6 on, outgoing off)
  • Users can remove or expire containers they put in place
  • The management container can reach every container on the network but does not see them in the file system, mainly to enable users to bounce into isolated containers via ssh (see ProxyCommand)
  • $HOME on management container could be a tmpfs with exceptions (~/.ssh/ and ~/$(who).ovpn come to mind)
  • Users can't give new mknod priviliges to containers, host admins must intervene
  • Provide simple how-to via motd
  • When creating a new user container, tool waits for configuration dump by the host and displays access information

Maybe

  • Container types other than Debian stable (for example OpenWRT or any VNC enabled $distro) may be provided if someone puts in the respective work
  • Automatically mount broken container rootfs into user $HOME: go fix (it) yourself - the exception to the rule of management container not seeing user files? (Problem with that though: file permissions)

User container

  • User created containers are automatically started at boot. If a container fails to boot a certain amount of times, the autostart flag is removed and access ceases until host admins intervene.
  • All users with root access can expire containers, getting them automatically discarded. $ date -d "next Monday" +%s > ~root/discard
  • User containers are allowed to nest containers (making it possible for people to use Docker if they really want to)

Maybe

  • Make all containers reachable via name.bo.x0.rs?

Host

  • Runs Debian stretch with the latest backports kernel, backports LXC and LXCFS and systemd (to make systemd based unprivileged containers work - no real root for you).
  • Is full disk encrypted, password is shared with the HM board
  • Containers are located on a zfs mount. Minimise hard disk space waste etc.
  • The host has an inotifywait process that checks for new configuration arrivals and puts the new unprivileged containers in place, generates new SSH host keys, adds the users' SSH keys to root@, creates a summary file in the users home on the management container
  • Runs a daily systemd-timer at 4am to check for expiration of containers

Maybe

  • Have a container that acts as provider for network booting (for public terminals, raspberry pi etc.)


Retrieved from "https://wiki.hackmanhattan.com/index.php?title=Bo.x0.rs&oldid=9066"