Posts

How to defuse XZ Backdoor (or alike) in SSH Daemon

XZ Backdoor in SSH Background Someone planted a backdoor in XZ compression, which is believed to affect SSH. More details can be found. Although it was never shipped to production version of any distro. Even if you are using unaffected version I suggest you defuse any similar backdoors. https://www.openwall.com/lists/oss-security/2024/03/29/4 https://news.ycombinator.com/item?id=39865810 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users The Kill Switch The backdoor has a kill switch, it does not activate if it detects that someone is observing it (debugger attached...etc). An easy way to defuse the backdoor is to just define TERM environment variable causing the backdoor to think it's being observed and it would disable itself hopefully this is not specific to this backdoor but any similar one.  mkdir /etc/systemd/system/sshd.service.d/ echo -e "[Service]\nEnvironment=TERM=xt

Piece of Miraculous Literature: Modern Story Telling

Image
Introduction For those who study modern literature, there are many known " Literary Elements " (like plot, theme, character, pace and tone, ...) and " Literary Techniques/Devices " ( Flashback , Cliffhanger , Narrative hook , ...) that was developed over time. With regards to story telling, many structural principles of modern storytellers can be explained using analysis based on Aristotle Poetry, where the story is all about a "knot" that get tied or revealed, the play has two parts: complication and unraveling with respect to the "knot". Freytag's Analysis of a store, proposed in 1863 by Gustav Freytag (a German writer) which is a model of an arc of 5 parts: exposition/introduction rising action (rise) climax falling action (return or fall) denouement (catastrophe) Although it's advocated for modern story telling, it's still lakes more advanced structures used by modern story tellers as we are going to see later.

How to make responsive GTK+ applications

Image
Introduction This weekend I've made a GTK+ application, I've done my best to make it responsive by applying my old Android development experience. Android make it clear that you should not block UI thread (main thread) not non-UI tasks like: disk IO (read a file) network IO (request remote API) internal SQLite database intensive computations  Let me quote : "You should not perform the work on the UI thread, but instead create a worker thread and do most of the work there." private class MyTask extends AsyncTask... { protected Long doInBackground(URL... urls) { // worker thread } protected void onProgressUpdate(Integer... progress) { // ui thread } protected void onPostExecute(Long result) { // ui thread } } GTK+ GTK+ is not threadsafe, in the sense all calls to GTK+ should be from a single thread that is the main thread or the UI thread, which seems similar to Android. We have a class that loads the glade XM

DIY Docker using Skopeo+OStree+Runc

Image
Docker is awesome, but what is even more awesome about UNIX philosophy is that you can use combine small tools to create a something that work like docker. Actually Dockerlite used BTRFS and LXC to make a toy version of docker. In this post we are going to discuss show how one can pull a Docker image and run the containers without a docker daemon, of course we do this for fun. We are going the achieve the following: ability to pull docker images space efficient  storage of images and containers even better that docker (not just reuse layers, but even files) run the container We are going to use OSTree : content addressable storage, git-like for OS Images, space efficient and uses hardlinks Skopeo : a way to pull all kinds of images and convert them to all kinds of storage Runc (or any OCI runtime like bubble wraps oci ) In this post we are going to run everything as non-root regular user (to make it even more challenging) let's create a bare OSTr

Making minimal graphical operating system

Image
Back in my first days of Linux I had a bootable floppy disk with fully functional Linux distro (a kernel, a shell and busybox tools and lua scripting). Maybe that was not much, but it was less than 2MB and would work on an old 386 PC with 4MB of RAM. But shell is boring, graphical minimal Linux distros was several hundreds of mega bytes and need hundreds of MB of RAM. Embedded devices typically have a minimal Linux with busybox or alike running with no graphical interface but instead they have some sort of web interface exposed to some port. If you tried to run a minimal graphical Linux distro let's say XFCE on an embedded device (let's say a raspberry pi) you would notice that most of its limited resources are taken by Xorg the legacy graphical server. Introducing Wayland Wayland is a new different approach to graphical interface, instead of sending drawing instruction over a legacy protocol (with so many extensions) to a legacy daemon (with so many extensions) that

Summary of kubernetes features and terminologies

Image
Introduction Kubernetes had won the container orchestration war. Here is a summary of its features. It's an API, command line and UI. It uses etcd to keep its state. Every thing is done via Yaml or JSON (your choice). General Node : a machine or instance (used to be called "minion") Namespace: a grouping of resources Label: a tag applied to a resource ex. role=frontend Annotations: another form of meta data  Workloads Container  ( spec ) : the building block of deployable service or runnable task using linux containers ex. docker image and params to pass at runtime. Typically created in a Pod see below Pod  ( spec ) : one of more containers scheduled to nodes together and thus can share volumes. Most common pods have a single container but there are use cases for more (ex. nginx and php-fpm) . If you replicate a pod to have 3 replicas it would have 3 nginx and 3 php-fpm. If php-fpm created a file in the volume, nginx can see it. Typically created

Bootstrapping Alpine Linux QCow2 image

Introduction Alpine Linux is a minimal distro with package manager ( APK ) that is based on busybox and musl library . Like the  CirrOS , it's very lightweight, but unlike it, it's full featured. In case you don't know me, my Linux distro of choice is Fedora/CentOS, in this post I'm going to bootstrap a QCow2 cloud image of Alpine Linux on my distro of choice. Using docker to bootstrap a working chroot Type mkdir alpine35-root docker run --rm -ti -v $PWD/alpine35-root:/data alpine:3.5 apk --arch x86_64 -X http://nl.alpinelinux.org/alpine/v3.5/main/ -U --allow-untrusted --root /data --initdb add alpine-base  and you should get a line like this OK: 6 MiB in 16 packages so now we have a working alpine chroot in the directory alpine35-root Creating Bootable QCoW2 Image Because I don't want to format my hard disk by mistake and because I know Murphy's law, I'll take those 6MB as tarball and continue on a VM. dd if=/d