bo.x0.rs

From Hack Manhattan Wiki
Jump to: navigation, search
Box0rs-logo.svg
bo.x0.rs is Hack Manhattan's in-house minimalist hackerspace-tinker-tolerant bullshit cloud running on a kindly donated ThinkPad T420, 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-2520M CPU @ 2.50GHz
MemTotal: 8058712 kB
/dev/sda: 149.1 GiB
/dev/sdb: 931.5 GiB
Ethernet: 00:21:cc:c5:be:63 (Wake-on-LAN enabled)

Host Network

  • 10.0.93.0/24 - bridged and normally routed. Reached by everything in the space, reaches everything in the space. "Do what thou wilt shall be the whole of the law"
  • 10.8.0.0/24 - OpenVPN addresses, bridged and routed. 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.

Current containers

  • web 10.0.93.4
  • vpn 10.0.93.3 & 10.8.0.1
    • 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 10.0.93.2
    • Doesn't do anything yet
  • hmbot 10.0.93.5
    • Doesn't do anything yet
  • clickycloud 10.0.93.6
    • 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 along with the output of python3 -c 'import crypt;print(crypt.crypt("put your password in here"))' to mz


"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 stretch (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.)