2020-10-24 23:49:00
One of the benefits of teaching Linux to a group of young adults, is that it forces me to go back to the books myself. The Linux+ objectives cover a few things I haven't worked with yet (such as MDM), but also touches on things I haven't given much thought yet. Case in point: PAM.
Just about every Linux sysadmin certification exam requires that you can work with Pluggable Authentication Modules. They want you to make your SSHd or SU authenticates correctly, or to include pam_tally. So we learn about /etc/pam.conf and /etc/pam.d/* and how to setup an auth or session stack correctly.
What led me down a rabbithole was this: what if I want to make a Python app that authenticates users? I found references to python-pam and other modules, but most discussions ended with: "You need to run as root, or add your application user to the shadow group."
Initially this felt odd to me because, aren't we teaching everybody that services shouldn't run as "root"? In the end it does make sense, of course, because if any arbitrary user could (ab)use PAM to verify another user's password that'd be problematic. The process might be very noisy, but you could still try to brute-force the password.
One source of confusion was the pam_unix documentation, which states:
"A helper binary, unix_chkpwd(8), is provided to check the user's password when it is stored in a read protected database. This binary is very simple and will only check the password of the user invoking it. It is called transparently on behalf of the user by the authenticating component of this module. In this way it is possible for applications like xlock(1) to work without being setuid-root."
Stupidly my brain glossed over the important parts (I need sleep) and latched onto the "without being setuid-root". The important part being that it "will only check the password of the user invoking it".
What made me finally understand the workings of unix_chkpwd is a project of Marco Bellaccini's that I found on Github -> chkpwd_buddy. It should me the proper way of interacting with unix_chkpwd as a non-root user: FIFO pipes.
$ mkfifo /tmp/myfifo
$ echo -ne 'testing\0' > /tmp/myfifo &
$ /sbin/unix_chkpwd tess nullok < /tmp/myfifo
$ echo $?
0
$ echo -ne 'testing\0' > /tmp/myfifo &
$ /sbin/unix_chkpwd testaccount nullok < /tmp/myfifo
$ echo $?
7
$ sudo -i
# mkfifo /tmp/rootfifo
# echo -ne 'testing\0' > /tmp/rootfifo &
# /sbin/unix_chkpwd tess nullok < /tmp/rootfifo
# echo $?
0
# echo -ne 'testing\0' > /tmp/rootfifo &
# /sbin/unix_chkpwd testaccount nullok < /tmp/rootfifo
# echo $?
0
Root can verify both my "tess" password and the one on "testaccount", while I could only verify my own password with my normal account.
What's interesting, is that only the failed validation attempt shows up in journalctl. The successful attempts are not registered:
$ sudo journalctl -t unix_chkpwd
Oct 22 16:08:53 kalivm unix_chkpwd[86131]: check pass; user unknown
Oct 22 16:08:53 kalivm unix_chkpwd[86131]: password check failed for user (test)
To sum it up, if you want a Python app to authenticate the running-user's identity, you can use the python_pam module. But if you want the Python app to authenticate any/every user, then it will need to run as "root".
kilala.nl tags: teaching, work,
View or add comments (curr. 0)
2020-10-06 19:30:00
Sometimes you just have an odd need or craving! You just have to have some spicy curry udon after midnight! You just have to get an old RAID controller to work in your homelab! Or in this case: you just really have to get VirtualBox and Hyper-V to play nice on Windows 10.
That's something that just wouldn't fly until recently. But now it'll work!
I would like to extend my warmest thanks to my colleage Praveen K-P, who worked with me to figure all of this out. =)
These instructions are a work-in-progress and the solution is not 100% rock-solid.
Some mathematical functions, such as SHA2 or CRC, may fail depending on the OS you run in the VM. This means that outright installing an OS from DVD or ISO may fail during extraction: SHA1 or SHA2 checksums won't match up and the installer will refuse to continue. This is likely caused by the layered CPU virtualization and is under research with the VirtualBox team.
Also, please be careful when choosing base images for your VirtualBox VMs! Do not assume that you can trust every VM image on the Vagrant repositories! Only install images from trusted providers such as:
Installing untrusted base images may lead to malware infections or worse.
Kali Linux is one of the distributions whose installation fails due to the caveat involving mathematical functions. So let's use Vagrant instead, which pulls pre-built images from an online repository.
Open Powershell. Run the following commands:
cd $HOME
mkdir Vagrant; cd Vagrant;
vagrant init kalilinux/rolling
Before continuing, edit the "vagrantfile" file (e.g. with Notepad) and replace this line:
config.vm.box = "kalilinux/rolling"
With the following configuration. Edit the amount of RAM and CPUs to your liking. Me, I like 6GB and 3 cores.
config.vm.define "kali" do |kali|
kali.vm.box = "kalilinux/rolling"
kali.vm.hostname = "haxor"
kali.vm.provider "virtualbox" do |vb|
vb.gui = true
vb.memory = "6144"
vb.cpus = 3
vb.customize [ "modifyvm", :id, "--paravirtprovider", "minimal" ]
end
kali.vm.synced_folder '.', '/vagrant', disabled: true
kali.vm.provision "shell", inline: <<-SHELL
echo "Here we would install..."
[[ ! -d /etc/gcrypt ]] && mkdir /etc/gcrypt
[[ ! -f /etc/gcrypt/hwf.deny ]] && echo "all" >> /etc/gcrypt/hwf.deny
SHELL
end
Save the configuration file and now run the following in Powershell:
vagrant up kali
The init-command sets up your "Vagrant" directory and basic configuration file. By editing the "vagrantfile" we can change a lot of the behavior, including the way Kali perceives the VirtualBox hypervisor. We also tweak GCrypt, so it will refuse to try hardware accellerated cryptography. Both are required to make hashing and other maths work better.
The up-command actually starts the build of the VM, after which it is booted. The first installation will take a few minutes, after that you can just manage the VM using the VirtualBox user interface.
The Kali Linux Vagrant build includes the full graphical user interface! But you can also ssh -P 2222 vagrant@localhost to login to the VM. Be sure to create your own account and to change all passwords!
Your Linux distribution may have problems performing SHA2 calculations correctly. According to this source, it’s “Because apt use sha256 method from libgcrypto20, but optimized too much. We can deny this opt. using configuration file /etc/gcrypt/hwf.deny.”
$ sudo bash
# mkdir /etc/gcrypt
# echo all >> /etc/gcrypt/hwf.deny
In addition, we learned that in our nested situation (VirtualBox on top of Hyper-V) it may be a good idea to change your VM's "paravirtualization interface" from "Normal" to "Minimal". #TIL that this is not about how VBox provides better performance, but about what paravirtualization information is passed to the guest OS. In my case this change did fix hashing problems. This change can be made manually by editing the VM settings in VirtualBox (VM → Settings → System → Acceleration → Paravirtualization interface), or in the Vagrant file:
vb.customize [ "modifyvm", :id, "--paravirtprovider", "minimal" ]
Vagrant.configure("2") do |config|
config.vm.define "kali" do |kali|
kali.vm.box = "kalilinux/rolling"
kali.vm.hostname = "haxor"
kali.vm.network "forwarded_port", guest: 22, host: 2222, host_ip: "127.0.0.1"
kali.vm.network "forwarded_port", guest: 3389, host: 2389, host_ip: "127.0.0.1"
kali.vm.provider "virtualbox" do |vb|
vb.gui = true
vb.memory = "6144"
vb.cpus = 3
vb.customize [ "modifyvm", :id, "--paravirtprovider", "minimal" ]
end
kali.vm.synced_folder '.', '/vagrant', disabled: true
kali.vm.provision "shell", inline: <<-SHELL
echo "Here we would install..."
[[ ! -d /etc/gcrypt ]] && mkdir /etc/gcrypt
[[ ! -f /etc/gcrypt/hwf.deny ]] && echo "all" >> /etc/gcrypt/hwf.deny
SHELL
end
config.vm.define "centos8" do |centos8|
centos8.vm.box = "centos/8"
centos8.vm.hostname = "centos8"
centos8.vm.box_check_update = true
centos8.vm.network "forwarded_port", guest: 22, host: 2200, host_ip: "127.0.0.1"
centos8.vm.provider "virtualbox" do |vb|
vb.gui = false
vb.memory = "1024"
vb.cpus = 1
vb.customize [ "modifyvm", :id, "--paravirtprovider", "minimal" ]
end
centos8.vm.provision "shell", inline: <<-SHELL
echo "Here we would install..."
[[ ! -d /etc/gcrypt ]] && mkdir /etc/gcrypt
[[ ! -f /etc/gcrypt/hwf.deny ]] && echo "all" >> /etc/gcrypt/hwf.deny
SHELL
centos8.vm.synced_folder '.', '/vagrant', disabled: true
end
end
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2020-09-06 21:18:00
It's been a while in coming and I'm very happy they finally made it! Red Hat have joined the large number of companies who now offer at-home test taking for their professional certifications.
I quite enjoyed the way CompTIA handled their at-home examinations, but it looks like Red Hat have taken a very different approach. I still need to take the EX407 exam, so I'd better take a quick look!
Back in 2013 I was one of the first hundred people to use the Red Hat Kiosk exams, still have the souvenir key chain on my laptop bag. Let's see if their at-home tests work better than the Kiosk ones.
kilala.nl tags: work, studies,
View or add comments (curr. 0)
2020-08-13 11:35:00
It's become a bit of a hobby of mine, to take part in CompTIA's "beta" exams: upcoming versions of their certification tests, which are given a trial-run in a limited setting. I've gone through PenTest+, Linux+ and CySA+ so far :)
After failing to get through the payment process at PearsonVue a friendly acquaintaince at CompTIA helped me get access to the Cloud+ beta (whose new version will go live sometime early next year).
I sat the beta test this morning, using the new online, at-home testing provided by PearsonVue. Generally speaking I had the experiences as outlined in the big Reddit thread.
Most importantly, on MacOS the drag-n-drop on PBQs is really slow. You have to click and hold for three seconds before dragging something. Aside from that the experience was pleasurable and it all worked well enough.
I'm not as enthused about the Cloud+ beta as I was about Linux+ and PenTest+ at the time. The questions seemed very repetitive, sometimes very predictable (if "containers" was an option, two out of three times it'd be the correct answer) and some just unimaginative (just throw four abbreviations or acronyms at the test-taker, two or three of which are clearly unrelated). Knowing CompTIA I assume there will be plenty of fine-tuning happening in the next few months.
I'm pretty sure I didn't pass this one, but I'm happy to have had the chance to take a look :)
kilala.nl tags: work, studies,
View or add comments (curr. 0)
2020-08-12 15:35:00
This Reddit thread offers a plethora of information on the at-home, online test taking offered by PearsonVue.
Big lesson I learned as MacOS user: disable Little Snitch and other filtering / security software while you're taking the test. It feels dirty, but to ensure the software does not encounter any hickups (which may result in you botching the test) you're going to have to. Better yet, don't disable, but quit the software because any popups on your screen will also alert the proctor.
Just to be safe, I made a dummy user account on my Macbook, so I can remove all trace of the software afterwards. Luckily it runs from your downloads folder and doesn't need any admin-level access.
kilala.nl tags: work, studies,
View or add comments (curr. 0)
2020-08-09 19:39:00
It's hilarious how stuck in one's ways one can get. I mean, I've always typed:
netstat -a | grep LISTEN | grep ^tcp
While prepping slides for my students, imagine my mirth when I learned "there's a flag for that". Man, it pays to read man-pages.
netstat -l4
ss -l4
#EternalNewbie 💖
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2020-08-01 20:21:00
The Dell R410 in my homelab has served me very well so far! With a little upgrade of its memory it's run 20 VMs without any hassle. Finding this particular configuration when I did (at a refurbishing company) was a lucky strike: a decent price for a good pair of Xeons and two large disks.
I've been wanting to expand my homelab, to mess around with vMotion, Veeam and other cool stuff. Add in the fact that I'd love to offer "my" students a chance to work with "real" virtualization (using my smaller R410) and you've got me scouring various sources for a somewhat bigger piece of kit. After trying a Troostwijk auction and poking multiple refurbishers I struck gold on the Tweakers.net classified ads!
Pictured above is my new Dell R710, the slightly beefier sister of the R410. It has space for more RAM, for more disk drives and most importantly (for my own sanity): it's a 2U box with larger fans which produces a lot less noise than the R410. The seller even included the original X5550 CPUs seperately.
So! From the get-go I decided to Frankenstein the two boxes, so I could actually put the R410 to use for my students while keeping a bit more performance in my homelab.
Moving that RAID1 set from the R410 to the R710 was an exciting exercise!
I really did not want to loose all of my VMs and homelab; I've put a year into the environment so far! Officially and ideally, I would setup VMware ESXi on the R710 and then migrate the VMs to the new host. There are many methods:
Couldn't I do it even faster? Well sure, but you can't simply move RAID sets between servers! Most importantly: you'll need similar or the same RAID controllers. In a very lucky break, both the R410 and the R710 have the Dell/LSI Perc 6i. So, on a wish and a prayer, I pludged the RAID set and told the receiving Perc 6i to import foreign configuration. And it worked!
After booting ESXi from the SD card, it did not show any of the actual data which was a not-so-fun surprise. Turns out that one manual re-mount of the VMFS file system did the trick! All 24 VMs would boot!
So far she's a beaut! Now, onwards, to prep the R410 for my students.
kilala.nl tags: sysadmin, work,
View or add comments (curr. 0)
2020-07-10 13:45:00
It's official! After passing the theoretical exam in June and completing the practical, virtual classroom assessment this week, I'm now officially CTT+ certified: CompTIA CTT+ Virtual Classroom Trainer Certification.
Many thanks to the people who supported me; you know who you are! 💝
kilala.nl tags: work,
View or add comments (curr. 0)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.