Making a secure and clean system on a box (or board) requires some amount of trust. To make that trust as small as possible, there are steps you can take. At the extreme end of things, you run your own sources server and compile from those known pristine sources to make a new box. Then your “trust” consists of trusting that the sources you downloaded and any updates are in fact clean. This depends on them not being intercepted via a “Man In The Middle” during download AND that the originator is trustworthy. A similar case exists if you are NOT building from source.
Now generally you can trust that the Unix / Linux community is just paranoid enough about Authority and Intruders that they put great effort into assuring their sources and their pre-compiled binary systems are pretty much clean. Unless you choose to be a Systems Programmer & Developer yourself, that is the article of trust you accept. Since it is known that there are “many eyes” looking over the code and any “random” can take a look, it is hard to do too much illicit and not get caught eventually.
For that reason, I have chosen to draw my “line of trust” at the system vendor for open source products. I simply can’t look at the sources for every line of the system. I must trust that someone else has. This is part of my disdain for “systemd”. It comes from ONE vendor and looks like maybe at most 2 or 3 guys know how it works, only one of them the main programmer, and I don’t trust his “style” of doing things. Centralized. Somewhat opaque. Red Hat sells a LOT to government; I could easily see them giving in to a request to put some special sauce inside systemd. So no, thank you very much… It is arcane enough that few folks will look at it, and fewer still understand it, and fewer still of them catch a subtle ‘trick’ hidden in it. Hard to hide such tricks in the small codes of The Unix Way. So my line of trust is drawn at the Devuan Developers. They have demonstrated the appropriate level of concern about such things.
So I need to be able to download copies of the Devuan binary image files, and stuff them onto media, to make my systems run. This means I have to put a another line of trust at “I trust my Build Box to do the Building”. So how do I make sure my Build Box is itself clean and not contaminating other systems built on it? It’s a two step process.
First, take a very clean chip with a Linux on it. Most any one will do. For example, running NOOBS and making a generic boot chip for the Raspberry Pi, or doing a ‘clean install’ onto a PC, or even just booting a Knoppix CD on a PC as it is “clean every time”. Using that is pretty much guaranteed to be clean system, you build your Build Builder system. This process picks up at that point. I’m assuming you have a newly made Linux chip you can stuff in a Raspberry Pi or similar system that can run a download from the web and do a couple of basic Linux commands like “file” and “dd”. I’d even be OK with using a Mac or Windows box to do this step, as then any infection on them would need to “cross architectures” to get into the build process, and that is very rare.
I’m leaving it up to you how to make your “bootstrap build box”. If in doubt, just do a NOOBS install on a Pi.
So, with a “most likely clean” bootstrap build system, we download a Pristine Image file from the vendor. In this case, I used the Devuan site directly. One could choose to use one of their mirrors, too. I just launched the FireFox-ESR browser and went to:
where I clicked on the file name:
devuan_jessie_1.0.0_armhf_raspi2.img.xz 23-May-2017 11:14 172M
As noted in earlier discussions, the 64 bit build is still a bit buggier AND is quite a bit slower on lots of web pages open as it swaps a LOT more for the same pages. So I’m sticking with the 32 bit build for now (and likely for at least a year to come).
That download gives you an xz file, so you need to unpack that. This uses the unxz command.
this gives you:
as your Devuan image. There is also available the SHA checksum of the file and you can download them and compare to be assured nobody swapped the bits in your binary.
That lets you NOT trust your telco and other folks who might want to give you some bogus bytes. If really worried, you can download the checksums at one place (like Starbucks or the library) and your bits at another time at home. Your “attacker” would need to bugger both downloads to different IP addresses in different places at different times in order to pull off a “Man in the Middle” on the download itself. Personally, I’m willing to trust my https encrypted connection; but depending on “what is at stake” for you, draw your line of trust where you are comfortable.
OK, to summarize where we are at this point:
On a “pretty clean” new system, you download and unpack a trusted binary image from a trusted site and check the SHA code to assure it got there as the vendor intended. Now you don’t do any OTHER internet activity AT ALL with this system. It is ONLY for that one download and making the first Build Builder. If seriously concerned about “other web intrusions” via the browser, you can instead use a command like “curl” to do that download. This cuts out trusting the browser maker…
Next, you put that image onto a micro-SD chip. I use a Targus SD to USB adapter sold at Walmart. It’s cheap and it worked. Just put the SD card in it and put that into the USB connector of your system. Then, make sure it is NOT mounted. On Linux, it will usually mount it as something like:
/dev/sdd1 130798 21620 109178 17% /media/chiefio/BE59-395A
This means you need to unmount it so you can overwrite it.
You will have a different user name, possibly root, and the particulars of the file system name change with the chip vendors.
Do also note where it came from. I got “/dev/sddx” but you might get /dev/sda or /dev/sdc or who knows. This matters a LOT as that is the target for your image. So, in my case, I’d use /dev/sdd as my target. Notice I’m not using the “1” or any other number. No partition numbers need apply, You are using the whole card.
So once it is unmounted, for sure, and you know the device name, for sure, issue the command:
dd bs=10M of=/dev/sdx if=/path/to/image/devuan_jessie_1.0.0_armhf_raspi2.img
It is rare, but some systems may not like the 10 Meg block size. If so, you can leave that out, or just make it some other number like 1M. Bigger is more efficient, until it doesn’t work ;-) You will also change the ‘x’ in that device name to the letter you got on your system for the SD card. DO NOT GET THAT WRONG as the target device will be overwritten and obliterated. Not a big deal if you followed the guidance to make a “one off” build box with a new or disposable system; but a very big deal if you do this on Your Only Office System…
This stuffs a Devuan Image onto the chip and you are now “good to go”. ALMOST.
Devuan does NOT (yet) grow the root file system to fill the SD card at boot time. So you have a 1.9 GB or so system on your chip. In my case, I used a 64 GB micro-SD card. That left about 60 GB unused and unusable. I discovered this when attempting to update and add programs to the system and ran out of disk…
There are many line commands to grow that file system. I find it MUCH easier to just use “GParted” on Debian / Devuan / Other Linux. It is the Graphical Partition Editor that lives under “preferences” in the menu of Debian for God Only Knows what reason. IF it isn’t there, do an “apt-get install gparted” to get it. Launch it. It takes a while to fondle all the disks (another reason to use a one-off bootstrap build box without disks) and present the images of partitions. The SD card ought to be the last one listed and have an ext4 partition of about 1.8 GB, and then the rest of the chip marked ‘unused’. Select the ext4 partition,
On the Pi, your working operating system has names for partitions like mmcbblk0p2 while the SD card ought to be named something like /dev/sda2. (sda1 ought to be type FAT and has the boot bits). Just right click on the ext4 partition, select resize/move from the dropdown, and set the empty bytes in “freespace following” to zero. You may need to click the cursor into another one of the size fields after typing so it updates the fields. Then click on the resize/move button. You might think you were done, but no. NOW you have to tell it to really do what you have queued up… A little ‘right arrow’ button up top turns green. Click it to actually do the resize. This can take a while to complete. When it is done, exit.
You can now mount that partition onto a Linux box (so I like using a Pi to do all this…) and I have an entry in my /etc/fstab file just for SD cards:
# The SD Card Generic <<<<<<<<<>>>>>>>>> # #LABEL=SD_ms /SD/ms vfat rw,suid,dev,exec,noauto,async,noatime 0 0 #LABEL=SD_swap swap swap sw,pri=10 0 0 LABEL=SD_builder /SD/ext ext4 rw,suid,dev,exec,noauto,async,noatime 0 0
I make a directory /SD, and two sub directories /SD/ms and /SD/ext as mount points. Then I can mount the FAT partition, or the ext partition, as desired. Note I have the FAT partition commented out. Notice too that I added “labels” to those partitions when in GParted. It makes things much easier. There’s a “label” option in the menues. IF you chose to make a swap partition, then I’ve allowed for that in the fstab entry too. So mount the ext file system:
and now you can put things in it that you will use later to finish the system build. Like a copy of the “Build Builder” script down below, or any particular configuration files you already know you want. Like /etc/network/interfaces or /etc/fstab copies. I made a directory Systems_Archive and put the stuff in there:
cd /SD/ext mkdir Systems_Archives cp /My/Home/Dir/Build_Builder Systems_Archive cp /pristine/directory/devuan_jessie_1.0.0_armhf_raspi2.img Systems_Archive
Now, at this point, you have a clean, new, from the factory Devuan Image on a fully available SD card. You have your build script, your pristine binary image, and any other stuff you might want for configuration on it. Shut down and put this chip into your PI, boot it up. You will be met with a blank black screen and a login prompt. The root account has the default password of “toor”, so log in.
I immediately do two things. Change the root password with the passwd command, and “apt-get install file” as the “file” command lets you inspect disk partitions to know what’s on them before you do anything with them, like attempt to mount them.
root@Headend:/SD/ext/Systems_Archive# file /dev/sdd2 /dev/sdd2: block special (8/50) root@Headend:/SD/ext/Systems_Archive# file -s /dev/sdd2 /dev/sdd2: Linux rev 1.0 ext4 filesystem data, UUID=01879285-fe5f-429d-8edf-63494a0563cc, volume name "SD_builder" (needs journal recovery) (extents) (large files) (huge files) root@Headend:/SD/ext/Systems_Archive#
You can see that using the -s option is the one you want. Here you also see how that Lable can be handy. It declares itself to be the “SD_builder” partition…
Ok, You have booted up, changed the password, and have in place a copy of the pristine image file and the build script. Next you run that build script to put all the other software you want in this running copy of the system in place on it. Like a windows environment. I used LXDE. So really it’s just “run the script, answer some questions about things like keyboard type, and reboot”, then you get your graphical login.
Here’s my Build Builder script. Notice all sorts of things are MISSING from it. No mysql data base, no apache server. I could likely cut it down even more, but this is what I find comfortable. Remember that the purpose of this chip is to just be a clean uncluttered AND ISOLATED USE CASE system just for building more systems in a clean and secure way. Think of it as a ‘clean room’ system when running. The ONLY time it ought to be reaching to the internet is to… well, maybe set the clock. I suspect it could be run with ethernet entirely shut off.
So here’s my script:
root@Headend:/SD/ext/Systems_Archive# cat Build_Builder echo " " echo "Download a compressed image file from a Devuan Mirror such as" echo "https://files.devuan.org/devuan_jessie/embedded/" echo " " echo "copy the downloaded Devuan PiM2 32 bit image to a work space" echo "on local media, then uncompress it with:" echo "unxz devuan_jessie_1.0.0_armhf_raspi2.img.xz" echo " " echo " Once uncompressed, copy it to an SD card (assumed mounted at /dev/sdd)" echo " " echo "With a command like: " echo "dd bs=10M of=/dev/sdd if=/path/to/devuan_jessie_1.0.0_armhf_raspi2.img" echo "It is now a runable Devuan with root:toor account:pasword" echo "BUT: It's only about 1.9 GB for the file system. Next use GPartd" echo "Which for unknown reasons is under preferences in the Debian menus" echo "Make sure the SD card is not mounted - do a df and look for it" echo "Select the ext4 partition on the SD card and choose to expand or grow" echo "it into the rest of the space on the card." echo "You now have a runable Devuan. Put it in the machine and boot it" echo "Then run the rest of this script once logged into that chip as root" echo " " # # In general, I'm encapsulating what all I did in these two postings as a script: # # https://chiefio.wordpress.com/2015/07/18/raspberry-pi-m2-unboxing-and-setup/ # # https://chiefio.wordpress.com/2015/07/22/raspberry-pi-software-setup/ # # and updating it for how to build a Pristine Build System # If you didn't already change the password while booted up, # when done, log in as 'root' password 'toor'. Change the password. # passwd # and respond with the new one when prompted. # # To properly inspect disk partitions, you need the file command. So as soon # as booted, type in apt-get install file # for use looking at partion types and content. # but if you didn't, or won't, I'll do it here: echo " " echo "apt-get install file" echo " " apt-get install file echo " " echo "Also, to change the name of your machine, edit /etc/hostname and make it" echo "what you like. " echo "Here, I'm going to just set mine by brute force write to the file." echo " " echo "echo 'Builder' > /etc/hostname " echo " " echo "Builder"> /etc/hostname echo " " echo "Next, do the 'usual' update upgrade that brings you up to the present" echo "repository status (need a network connection from here on out)" echo " " echo "You can either put 'sudo' in front of each of these commands, or just " echo "'become root' which is what I usually do. Since only the root account" echo "exists at the moment, the sudo is not needed here." echo " " echo "sudo bash" echo " " echo "then run this script with ./Build_Builder (assuming you didn't change the name" echo "and that you are 'in' the directory where it is located.)" echo " " echo "apt-get update" echo "apt-get upgrade" echo " " apt-get update apt-get upgrade echo " " echo "Install LXDE desktop" echo " " echo "This takes a very long time, like about an hour, but installs a lot of" echo "other things, like Python and wicd, so gets them out of the way early" echo " " echo "apt-get install lxde" echo " " apt-get install lxde echo " " echo "Start doing useful operational 'packages'. " echo " " # This gets the useful tools like "nslookup" for looking at Domain Names echo " " echo apt-get install dnsutils echo " " apt-get install dnsutils echo " " echo "Scrot is a tool for taking screen shots by saying 'scrot' in a terminal" echo " " echo " " echo apt-get install scrot echo " " apt-get install scrot # Normally I would install "build-essential" to get things like C compiler # and some language tools, but they were already installed on the R.PiM2. # Doing it on the Devuan just to be sure. apt-get install build-essential echo " " echo "To get NTFS disks (like USB or an NTSB formatted SD card in adapter) to " echo "work 'read write' instead of just 'read only', you need ntfs-3g" echo " " echo " " echo apt-get install ntfs-3g echo " " apt-get install ntfs-3g echo " " echo "Want an NFS (Network File System) server so you can share disks with" echo "your internal network? This will install the code, then you get to" echo "configure things like /etc/exports. Optional on a pritine build box." echo " " echo " " echo apt-get install nfs-kernel-server echo " " #apt-get install nfs-kernel-server # prior to first use. Or reboot. # In your /etc/exports file, put something like: # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # # /YourFileSystem *(rw,sync,fsid=0,no_root_squash) # But without the # in front of YourFileSystem... and with your file system... # Remember to do a #echo " " #echo "Restarting the appropriate services so NFS will work" #echo " " #echo " " #echo service rpcbind restart #echo service nfs-kernel-server restart #echo " " #service rpcbind restart #service nfs-kernel-server restart # To make the box a static IP number, you will need to # make this your own server name and IP numbers in the file: # # Here's my /etc/network/interfaces file with leading # to make it comments. # # I will make this a "dump these lines in to replace" in my running version. # echo " " echo "Remember to make your /etc/network/interfaces file have a static IP#" echo "If you are going to be using PXE boot and such" echo " " #auto lo #iface lo inet loopback #auto eth0 #allow-hotplug eth0 #iface eth0 inet static #address 172.16.16.253 #netmask 255.255.255.0 #gateway 172.16.16.254 #dns-domain chiefio.home #dns-nameservers 172.16.16.254 192.168.1.253 192.168.1.1 # #auto wlan0 #allow-hotplug wlan0 #iface wlan0 inet manual #wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf # #auto wlan1 #allow-hotplug wlan1 #iface wlan1 inet manual #wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf # Don't forget to do a # ifdown eth0 # wait a minute for it to quiet down # ifup eth0 # As I want this to be a DNS server, DHCP server, and PXE server (uses a # tftp or "Trivial File Transfer Protocol" server, all of those can come in # one package with dnsmasq. #For misc odd file system types you might want, you need to install them: #apt-get install btrfs-tools xfsprogs f2fs-tools unionfs-fuse #apt-get install hfsplus hfsutils apt-get install squashfs-tools aufs-tools # echo " " echo "And that's the end of my present install build process." echo " " # # There are several files to edit and configure. Eventually I'll add a # "here script" to dump them from this script to where they belong, or # I'll just save a copy and have a 'save / restore' copy process. # # Once I get everything configured ;-)
I’m going to be doing experiments with running from squashfs copies of /lib and /usr as just one more layer of paranoia. IF anything gets in, it can’t change the read-only copies in squashfs format, only the running bits are at risk. But if not doing that, you don’t need that last line with squashfs in it, or if doing things with Macs, you can un-comment the line with hfsplus and hfsutils.
I also left in a long block with the nfs and network interfaces stuff, but commented out. Just so it’s documented how to do it if, for some reason, you needed it. I’m not going to be doing that on my Build Builder.
After The Script
I’m now making a clean backup of the chip at this stage. Just a “dd” into an archive. I can now recover to this very clean state at any time. In the process, I have only really trusted my bootstrap builder to be mostly clean and my vendor to have clean images. I’ve slightly trusted my telco to not send me to a bogus site with fake binaries (but I know ways to fix / test that if needed). Not a very large circle of trust for this chip / system.
This chip may need some configuration, or may not. Building systems depends a lot on being root, so I don’t really need to add any non-root users. IF you feel more comfortable NOT being root all the time, add one and use “su” to become root as needed.
At this point, I’m just going to be slamming that pristine Devuan “image” file onto two more SD cards. Upsizing them to use the whole card, running my basic user system build script on them, adding my “usual user” account and any network customizations and security enhancements, and then using them for dedicated purposes.
1) Dirty Driver: A basic Devuan on an 8 GB (or maybe smaller) chip for the purpose of doing general web browsing of anywhere. Crap crawls into the chip, I don’t care. After it is built, but before first use, I’ll “dd” an image of it into Systems_Archive. Then after each use, I’ll ‘dd’ that image back onto the card. Flushing any bad bits as I go. Bits only flow one way, from the pristine saved image onto the Dirty Driver card.
2) Financial Stuff: A basic Devuan used for things like any online activity for any site with money involved. Like Paypal or online banking (that I don’t like, but I’m getting pushed into it). NEVER for any general purpose web activity.
The Dirty Driver will only be used on the Telco Router network side, so never exposed to my interior network. IF it ever gets infected with anything, it can only hit the Roku on the TV (which seems immune) and the Telco router (that isn’t my problem). But it is most likely going to be flushed before anything bad has time to happen.
The Financial Stuff system will only be used on my private network side and ONLY for 2 or 3 particular sites. As they are highly trusted, this lets me limit my circle of trust to only them. Isolated from the un-trusted stuff on the Dirty Driver. I may, or may not, re-flash this system from the saved image, depending on my level of concern.
The Build Builder just sits on the shelf, never talking to anyone. Never being exposed. Only booted to put those trusted bits onto system cards to go into other systems.
MAYBE, in a year or so, a new updated binary downloaded to it and repeat the system build process, but really, I could just re-flash the chips with their saved image, do an apt-get update and apt-get upgrade, then “dd” that updated image back to Systems_Archive as the new image. Since that would start from a re-flashed chip, the history of use and exposure would be unable to crawl back up with the update copy; as that is only trusting the Devuan vendor site.
In this way, I’ve got clean isolated and most likely safe and pristine system images to use. Any “bad thing” that crawls in can NOT get into my off line disks, nor can it get back “upstream” into my build process. It gets flushed out before the next use. I’ve also put a hard wall between my Interior Office Work on my Daily Driver, my Financial Transactions, and my Dirty Driver exposures. Fire breaks and firewalls all around. Minimized circle of trust on the build process, and isolated circles of trust on Financial, Lab Work, and Public Internet uses.
And that, boys and girls, is a big part of how I keep my systems clean and healthy in a hostile world.