💾 Archived View for gemini.greenleader.xyz › technotes.gmi captured on 2022-04-28 at 18:02:31. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I'm mostly a blue-team security guy and backup systems engineer in a primarily Windows environment. This means that a lot of my work is done in browsers and from Powershell. Initially, I'll be doing a lot of my work from a Windows HVM (see my post from 2022-03-16 on how to get that imported), but once I get VPN/networking connecting me to the office, I'll be migrating that load to AppVMs, appropriately segmented for the level of access I'm using.
Today I set up the template VM I'm using for my work appVMs. I'm running the Debian 10 template; there's a Debian 11 template available, but there's still some bugs (for example, it can't mount exfat partitions, even with the appropriate packages installed). I'll be installing remmina for RDP access, codium for, well, coding, Chromium, Edge, and PowerShell.
First, I cloned the template to "debian-10-work". Then I enabled networking on the template (some of the installs require going out to the web for curl/wget actions).
Let's do the easy ones first:
apt install remmina apt install chromium
Next, codium (reference: https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo#option-1-recommended):
wget -qO - https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg \
| gpg --dearmor \
| sudo dd of=/usr/share/keyrings/vscodium-archive-keyring.gpg
echo 'deb [ signed-by=/usr/share/keyrings/vscodium-archive-keyring.gpg ] https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs vscodium main' \
| sudo tee /etc/apt/sources.list.d/vscodium.list
sudo apt update
sudo apt install codium
I had some major issues with the Edge install; for some reason I couldn't get their signing key to work following the instructions on the official site (https://www.microsoftedgeinsider.com/en-us/download?platform=linux-deb) which caused apt update to fail. I undid all of that, but did eventually get it going. More on that after PowerShell.
pwsh (reference: https://docs.microsoft.com/en-us/powershell/scripting/install/install-debian?view=powershell-7.2#installation-on-debian-10-via-package-repository):
wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb sudo apt-get update sudo apt-get install -y powershell
After I finished the PowerShell install, I checked the apt keys (apt-key list) and found that the same key was used for both PowerShell and Edge. So, I tweaked the line to import the repo, tried again, and it worked!
sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/edge stable main" > /etc/apt/sources.list.d/microsoft-edge.list' apt update apt install microsoft-edge-stable
Phew! That's working well now. Now if the 20GB image file with my HVM would quit crashing part way through downloading, I could move in full-time. Next up, trying to get NDES/SCEP enrollment working and get connected to our VPN.
Finally received my Purism Librem 14v1 (not their fault on the delay). Here are my first impressions and some of my initial setup concerns.
I ordered the 32GB / 1TB / SeaBIOS + coreboot / Qubes version. First impression at unboxing is that this is a really attaractive laptop. Nice sharp corners, matte finish, no markings on the top or inside, minimal markings on the bottom. Gives me vibes like a "murdered out" car. Screen is nice, too. I like that sticker life, but I'm go
ing to keep the back clean until it starts getting scratched.
On first boot, you're prompted for your LUKS password. I wasn't given one. I checked the FAQ and support site without luck. I gave up and emailed, but while I was waiting, I found a blog post from the CEO (https://puri.sm/posts/qubes-now-a-preinstall-option-for-librem-14-and-mini/) that mentioned it was blank. Facepalmed, hit the enter key, and was taken to the Qubes OOBE. That was fairly straight forward, especially since I've installed Qubes before. I created a user and set the encryption password and was on my way...
Or so I thought. They shipped the machine with Qubes 4.0 installed. The whonix templates included were the deprecated -15 ones. I could have reinstalled Qubes, but I wanted to get the whole "new user" experience, so I toughed it out.
System time was *way* off. I had to fix that before updates would work (due to cert validity), and it took a reboot before it kicked in. Then I performed a distribution upgrade to get to 4.1: https://www.qubes-os.org/doc/upgrade/4.1/
From dom0:
sudo qubes-dom0-update -y qubes-dist-upgrade sudo qubes-dist-upgrade --all
reboot
sudo qubes-dist-upgrade --resync-appmenus-features
The whonix installs were still on -15, so had to import the new templates:
sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=reinstall qubes-template-whonix-ws-16 sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=reinstall qubes-template-whonix-gw-16
Re-assign the App VMs to the updated templates (don't forget to change the DispVM setting in the -ws VM) and delete -15 templates:
qubes-dom0-update --action=remove cubes-template-whonix-ws-15 qubes-dom0-update --action=remove cubes-template-whonix-gw-15
I also went ahead and installed the Debian 11 template:
sudo qubes-dom0-update --action=install qubes-template-debian-11
That's it for now. I've got to start adding apps to my templates, setting up my app vms, and importing the Windows HVM that I need. Also need to try to see if I can get OpenConnect working (I was working on it on a tester for the past month, but could never get it to work in our environment).
Fairly straight-forward here.
- Create your VM in Hyper-V (I imaged it via SCCM to get a fully standard work build).
- Install the Qubes Windows tools (xenbus, xenvbd drivers, qubes-tools-4.0.1.3).
- Shutdown the VM.
- Convert the disk image from vmdk to raw format:
qemu-img convert -f vhdx -O raw <path to vmdk> <path to target .raw file>
- Copy the file to dom0 (run from dom0):
qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10.img
- Create the HVM (set the RAM, label, and machine name as you wish):
qvm-create --property=virt_mode=hvm --property=memory=4096 --property=kernel='' --label red --standalone --root-move-from /home/user/win10.img win10
Reference: https://www.qubes-os.org/doc/standalones-and-hvms/#converting-virtualbox-vms-to-qubes-hvms
Reference: https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md
I'm super pumped to get my Librem 14 in a few weeks. Since I work remote I don't have to worry about jealous coworkers, but on the other hand I don't get to show off, either :(.
OK, here we go, time to write up how *I* installed i3 on OpenBSD 7.0. Hopefully the format will translate from my notes.
Reference: https://ronvalente.net/posts/install-i3-on-openbsd/
Reference: https://www.nxfury.com/lock-down-your-laptop-with-openbsd-part-2
pkg_add i3-gaps i3status rofi rxvt-unicode chromium irssi w3m vim openbsd-backgrounds
sed -i 's/xconsole/#xconsole/' /etc/X11/xenodm/Xsetup_0
echo 'xset b off' >> /etc/X11/xenodm/Xsetup_0
Not using this on the Mini.
rcctl enable apmd rcctl set apmd flags -A rcctl start apmd mkdir /etc/apm # append next two lines to /etc/apm/suspend: #!/bin/sh pkill -USR1 xidle chmod +x /etc/apm/suspend
I'm not familiar with this; just following the guide. Apparently some groups get more resources than others, so you have to make these mods for performance reasons:
usermod -G staff labadmin
Modify the staff: entry in /etc/login.conf to look like this:
staff:\ :datasize-cur=1024M:\ :datasize-max=8192M:\ :maxproc-cur=512:\ :maxproc-max=1024:\ :openfiles-cur=4096:\ :openfiles-max=8192:\ :stacksize-cur=32M:\ :ignorenologin:\ :requirehome@:\ :tc=default:
The only ones I had to modify in my config away from default were macproc-cur, maxproc-max, and I had to add the openfiles and stacksize values.
Then, append this to /etc/sysctl.conf:
# shared memory limits (chrome needs a ton) kern.shminfo.shmall=3145728 kern.shminfo.shmmax=2147483647 kern.shminfo.shmmni=1024 # semaphores kern.shminfo.shmseg=1024 kern.seminfo.semmns=4096 kern.seminfo.semmni=1024 kern.maxproc=32768 kern.maxfiles=65535 kern.bufcachepercent=90 kern.maxvnodes=262144 kern.somaxconn=2048
sysctl.conf did not exist when I started.
Run as user, not root:
mkdir -p ~/.config/gtk-3.0
nano ~/.config/gtk-3.0/settings.ini
Add these lines:
[Settings] gtk-theme-name=Adwaita gtk-icon-theme-name=Adwaita gtk-font-name=Arimo 9 gtk-toolbar-style=GTK_TOOLBAR_ICONS gtk-toolbar-icon-size=GTK_ICON_SIZE_SMALL_TOOLBAR gtk-button-images=1 gtk-menu-images=1 gtk-enable-event-sounds=1 gtk-enable-input-feedback-sounds=1 gtk-xft-antialias=1 gtk-xft-hinting=1 gtk-xft-hintstyle=hintslight gtk-xft-rgba=rgb gtk-cursor-theme-size=0 gtk-cursor-theme-name=Default gtk-key-theme-name=Default
As root:
cp /usr/local/share/examples/i3status/i3status.conf /etc
From the nxfury page:
Lastly, let's configure i3 to actually launch. Open /etc/X11/xenodm/Xsession in a text editor and go to the end of the text file. There will be a portion saying exec fvwm. Remove that line entirely and replace it with exec i3. Now search for anything in this file saying xconsole and remove it (this prevents automatic launching of a console in your desktop.)
Note that this is just "exec i3" not with the prefix variable or any of that nonsense.
Skipping the intel section, not relevant on Mac Mini.
Referenced guides don't include i3lock.
pkg_add i3lock
pkg_add xautolock
At the end of ~/.config/i3/config, add the following lines:
bindsym $mod+Shift+m exec i3lock -c 000000 exec --no-startup-id xautolock -time 15 -locker "i3lock -c 000000"
The first line binds mod-shift-m to lock the screen.
The second starts when i3 starts and locks your screen after 15 minutes.
That wraps it up for now. Stay tuned!
It's taken me a little while to get around to writing up the i3 install. I'll get to that later. For now, let's take a look at getting my current favorite BBS software, SyncTERM, installed and configured for OpenBSD.
I was initially excited because a pkg_add syncterm worked. Unfortunately, the version in the repo wasn't compiled with ssh support. Annoying. I tried downloading the current .tar.gz of the release version (1.1p), but had trouble compiling. I finally got it working with the latest version in git.
References:
Meatlotion's Linux compile instructions: https://www.erb.pw/how-to-install-syncterm-for-linux-from-source/
Bugs 40, 41, and 80 from the SyncTERM bug tracker: https://sourceforge.net/p/syncterm/tickets
A lot of searching and learning about compiling in OpenBSD.
Note that I may have missed a dependency here. Shouldn't be too hard to find it.
Run this as root:
pkg_add unzip gcc git
git clone https://gitlab.synchro.net/main/sbbs.git
cd sbbs/src/syncterm
st_path=$(pwd | sed 's/\/syncterm$//g')
gmake SRC_ROOT=$sst_path
gmake install
which syncterm
It installed to /usr/local/bin/syncterm on my system. Running "syncterm -iSF" runs it full screen, stretched to fit. SSH works as you would expect.
I've been messing around with various alternate Android ROMs for a long time. It's always an adventure - get root, unlock the bootloader, find the right ROM for your exact version of the device, flash it, brick it, recover it, try again, etc.
Usually I'll end up with LineageOS, without any Google services. However, after work got me a Pixel 3 for (cough) testing, I finally had a chance to try Graphene OS.
The Pixel 3 is the oldest supported device for GrapheneOS and may fall off before too long. When buying a phone for GrapheneOS, make sure you can unlock the bootloader - the carrier-provided versions don't allow this and prevent you from installing alternate ROMs. The eBay listing should mention this, or you can ask the carrier. If the IMEI starts with "3", it's a Verizon phone and definitely won't work.
All that said, installing GrapheneOS is the *easiest* alternate ROM install I've ever done. Their web-based installer is flawless. Once booted into the phone you'll find that it's extremely minimal. The first thing to do is go install F-Droid and Aurora so you can easily install other apps. The device is very smooth and the interface is visually appealing.
In terms of drawbacks, the first is that, as all of the supported devices are Pixel 3 and later, you can't buy a phone that has a MicroSD slot; you're committed to the storage on the phone and no more. The second drawback, for some users, is that since Google Play services are not installed, some apps won't work (including Microsoft Intune, if you need it for work).
I'm currently daily driving this as my "personal" phone (I need a full Android experience for work). I'll follow up in a few days with some more impressions.
I began the dual boot install today; the practice runs I took while waiting for the install kit for the second drive paid off. I'm going to document the actual installer steps below. My environment:
- Mac Mini 2011 (MacMini5,2) with dual SSDs, labeled DISK0 and DISK1.
- DISK0 has MacOS Catalina (dosdude1 patched).
- DISK1 is blank.
- The OpenBSD install image (install70.img) is installed on a USB stick.
- Network is connected via Ethernet.
Step-by-step process:
Insert the installer into the Mini.
Hold down the ALT key and power on the Mini.
From the boot menu, select "Windows" (which is actually OpenBSD - the boot menu is just stupid).
At the Welcome choose (i) for install.
At the keyboard layout prompt hit enter for the default.
Enter your host name.
Configure your network interface (on the Mini bge0 is the ethernet interface name).
Choose [autoconf] for IPv4.
Don't bother with IPv6.
Choose [done].
Enter the root password twice.
Set sshd to start by default.
Do you want the X Window System to be started by xenodm: yes.
Setup a user (actually enter the username here - the installer gets snarky if you enter "yes")
Enter the full name, password twice.
Allow root ssh: No.
Enter your timezone.
Select root disk: In my case it's wd1 since wd0 is the MacOS disk.
Use whole disk GPT (this is important - if you go MBR your ability to make certain changes later can be impeded.)
Accept the layout (in hindsight I think I should have modified this for more space on the EFI partition - more about this later).
Don't initialize any additional disks.
Install sets: The installer glosses over part of this; if you didn't know ahead of time that you need to remount sd0 you'll get confused about where you're supposed to find them from.
Location of sets: disk
Is the partition already mounted? No
Which disk contains the media? sd0
Which partition has the install sets? a
Pathname to the sets? 7.0/amd64
Select all (default) and choose done.
Continue without verification.
Installation begins.
Location of sets: done
Exit to Shell, Halt, or Reboot? Halt <--- This doesn't seem to work right on the Mini. Need to investigate.
Remove media, power off.
Hold ALT and power on. You'll see DISK0 (The MacOS install) and "Windows".
Boot into MacOS and make sure it still works.
While in MacOS, this is a good time to purge "Windows".
I found this related article: [Rename EFI Boot Partition "EFI Boot"](https://apple.stackexchange.com/questions/343707/rename-efi-boot-partition-efi-boot). I wanted to add the OpenBSD icon, but I didn't leave enough space on the EFI partition. *Alexa, this is so sad. Play Despacito.*
diskutil mount disk1s1 bless --folder /Volumes/NO\ NAME/efi/boot --label "OpenBSD"
Reboot, hold ALT key again, boot into OpenBSD. SUCCESS!
To do:
- Wireless
- Shutdown / Halt
- Suppress "can't read the disk" message in MacOS.
I recently picked up a Mac Mini 2011 (MacMini5,2