Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux system. In this guide, we will walk you through the steps to install Podman Desktop on Ubuntu 22.04 LTS.

Install Podman

First, update your package list and install Podman:

sudo apt-get update
sudo apt-get -y install podman

Install Podman Compose

To install podman-compose, follow these steps:

1. Install python3-pip:

sudo apt-get -y install python3-pip

2. Install podman-compose using pip3:

sudo pip3 install podman-compose

Install Podman Desktop

To install Podman Desktop, we will use Flatpak. First, install Flatpak:

sudo apt install flatpak

Then, install Podman Desktop from Flathub:

flatpak install --user flathub io.podman_desktop.PodmanDesktop

Finatlly you can run Podman Desktop with:

flatpak run io.podman_desktop.PodmanDesktop

Fix CNI Plugin Problem

It can be that you are facing the following problem with Podman Compose:

WARN[0000] Error validating CNI config file /home/mike/.config/cni/net.d/cni-podman1.conflist: [plugin bridge does not support config version "1.0.0" plugin portmap does not support config version "1.0.0" plugin firewall does not support config version "1.0.0" plugin tuning does not support config version "1.0.0"]

It can be fixed with the following installation:

sudo snap install curl

curl -O https://archive.ubuntu.com/ubuntu/pool/universe/g/golang-github-containernetworking-plugins/containernetworking-plugins_1.1.1+ds1-3build1_amd64.deb

sudo dpkg -i containernetworking-plugins_1.1.1+ds1-3build1_amd64.deb

More infomation about the background you can found in this blog post and in this bug report

Optional: Create Desktop Entry for Podman Desktop

To create a desktop entry for Podman Desktop, create a symbolic link to the application:

ln -s ~/.local/share/flatpak/exports/share/applications/io.podman_desktop.PodmanDesktop.desktop ~/.local/share/applications/

As you can see, Flatpak already offers a .desktop file; we just need to link it to the correct folder. This step creates a symbolic link to the Podman Desktop application in your local applications directory. This allows your desktop environment to recognize and display the Podman Desktop application in your application menu, making it easier to launch.

Edit the desktop entry to set the correct icon path:

vim ~/.local/share/applications/io.podman_desktop.PodmanDesktop.desktop

Change the Icon= line to:

Icon=<your_home_path>/.local/share/flatpak/exports/share/icons/hicolor/128x128/apps/io.podman_desktop.PodmanDesktop.png

Finally, restart your desktop environment to apply the changes. For X11, you can do this by pressing [ALT] + [F2], entering r, and pressing enter.

Further Resources

• Podman Installation Documentation

• Podman Compose Repository

• Podman Desktop Installation

Memory dumps are a crucial tool for analyzing the state of a program. With tools like gcore or gdb, developers can save the memory of a running process for debugging or to understand unexpected behavior. However, memory dumps can also expose sensitive information, such as passwords or cryptographic keys, if these are present in memory at the time of the dump. In this article, I’ll show you how to create memory dumps using gcore, analyze them, and highlight the importance of handling them securely.

What is gcore?

gcore is a simple command-line tool that is part of the GNU Debugger (gdb). It allows you to create core dumps, which are snapshots of a process’s memory, without terminating the process itself. These dumps contain:

• The state of the heap, stack, and other memory segments.
• Information about variables and data used by the program during runtime.

Example: Creating a Dump with gcore

Step 1: Create a Test Program

Let’s create a simple program that holds sensitive information, such as a password, in memory. The program will display its PID and remain active for a few minutes to allow analysis.

#include <iostream>
#include <string>
#include <thread>
#include <unistd.h> 
#include <chrono>

int main() {
    std::string password = "SuperSecret123";
    std::cout << "Program is running... PID: " << getpid() << std::endl;

    // Keep the program running
    std::this_thread::sleep_for(std::chrono::minutes(5));

    return 0;
}

Compile the program:

g++ -o memory_test memory_test.cpp

Run it:

./memory_test

The program will display the PID and remain active for 5 minutes.

Step 2: Create a Dump with gcore

While the program is running, you can create a memory dump using gcore:

1. Find the process ID (PID) if you don’t already have it from the program’s output:

ps aux | grep memory_test

1. Create a dump with gcore:

gcore -o dumpfile <PID>

This generates a file named dumpfile., which contains the entire memory content of the process.

Step 3: Analyze the Dump

Use tools like strings to inspect the contents of the dump:

strings dumpfile.<PID> | grep "SuperSecret123"

If the password was not securely erased from memory, it will appear in the dump.

Alternatively: Creating the dump with GDB

Step 1: Attach to a Running Process

To analyze a specific process, you need to attach gdb to it using its process ID (PID). For example:

gdb -p <PID>

Replace with the actual process ID of the target process. Once attached, gdb will pause the process, allowing you to debug or inspect it.

Step 2: Focus on Specific Memory Regions

Use the info proc mappings command to identify memory regions, such as the heap, stack, or code segments. For example:

(gdb) info proc mappings

This command displays memory regions with their start and end addresses, permissions, and associated paths. You can use this information to select the regions you want to analyze or dump.

Step 4: Combine Interactive Debugging with Memory Dumping

After inspecting the memory, you can dump specific memory regions to a file. For example, to dump the heap region:

(gdb) dump memory heap_dump.bin 0xheap_start 0xheap_end

Replace 0xheap_start and 0xheap_end with the actual addresses of the heap region obtained from info proc mappings

Why Does This Matter?

This example demonstrates how easily sensitive data like passwords or tokens can be extracted from memory if they are not securely cleared. In security-critical applications, developers should:

• Securely erase data immediately after use (see this article)
• Disable dumps when they’re not needed.

ulimit -c 0

Conclusion

gcore and gdb are powerful tools for analyzing the state of a program, but it also highlights potential security risks if sensitive data remains in memory. By securely clearing data and disabling unnecessary dumps, developers can better protect their applications from data leaks.

Further Resources

• gcore Documentation
• GNU Debugger Documentation
• Core Dumps on Linux (Linux Manual)

HAProxy vs. NGINX

In one of my previous posts, I talked about a simple load balancing setup with NGINX. This article will shed more light on the usage of the NGINX alternative, HAProxy.

While NGINX was mainly developed as a high performance web server, HAProxy focused primarily on load balancing and traffic management.

The following table shows the key aspects of HAProxy compared to NGINX.

HAProxy Example

Setup

The following example is based on the NGINX example. To set up the containers, we use Podman. Alternatively Docker can also be used.

The project structure looks as follows:

.
├── app
│   ├── Dockerfile
│   └── index.php
├── compose.yaml
└── haproxy
    └── haproxy.cnf

As architecture, we use an HAProxy server that employs the Round Robin pattern to connect the frontend to three PHP servers that are providing a simple website. The website includes the hostname of the server we are connected to. With that, we can easily verify that our setup works.

The diagram below shows the basic architecture:

Configuration

A simple Round Robin configuration looks like this:

global
    log /dev/log local0
    log /dev/log local1 notice
    maxconn 200

defaults
    log     global
    option  httplog
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms

frontend http_front
    bind *:8080
    mode http

    default_backend backend_servers

backend backend_servers
    mode http

    balance roundrobin
    server app1 app1:80 check
    server app2 app2:80 check
    server app3 app3:80 check

    http-request set-header X-Backend-Hostname %[src]

Below you can find a short explanation of each part of the configuration.

Global Section

• log /dev/log local0 & local1 notice: Logs to system log with specified facilities and priority.
• maxconn 200: Limits concurrent connections to 200.

Defaults Section

• log global: Uses global logging settings.
• option httplog: Enables detailed HTTP request logging.
• timeout connect 5000ms: 5-second timeout for connections.
• timeout client/server 50000ms: 50-second timeout for client/server interactions.

frontend (http_front)

• bind :8080: Listens on port 8080 for all IPs.
• mode http: Operates in HTTP mode.
• default_backend backend_servers: Routes traffic to the backend backend_servers.

Backend (backend_servers)

• mode http: Operates in HTTP mode.
• balance roundrobin: Distributes traffic evenly among servers.
• server app1/app2/app3: Defines backend servers on port 80 with health checks.
• http-request set-header X-Backend-Hostname %[src]: Adds client source address as a header (X-Backend-Hostname).

Conclusion

After setting up NGINX and HAProxy, I conclude that, in this context, both load balancers perform well. The differences in the setup is quite small. I plan to continue testing more complex setups, such as those involving SSL/TLS, with both load balancers.

In this guide, we will walk through the steps to set up a simple load balancing environment using NGINX and Podman. This setup will distribute traffic across multiple instances of a PHP web application in round robin mode.

Prerequisites

• Podman installed
• Podman compose installed

An instruction for Ubuntu 22.04 can be found here.

Setup

The complete example can be found on GitHub.

First, let’s structure our project directory as follows:

.
├── app
│   ├── Dockerfile
│   └── index.php
├── compose.yaml
└── nginx
    └── nginx.conf

The App: Simple php Web Interface

Create a simple PHP web interface that shows the current hostname in app/index.php:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Hostname Example</title>
</head>
<body>
    <h1>Welcome to the Server</h1>
    <p>Served from: <strong><?php echo gethostname(); ?></strong></p>
</body>
</html>

The App: Dockerfile

Create a Dockerfile in app/Dockerfile to build the PHP application:

FROM php:8.2-apache
COPY index.php /var/www/html/

NGINX Configuration

Create an NGINX configuration file in nginx/nginx.conf:

events {}

http {
    upstream backend {
        server app1:80;
        server app2:80;
        server app3:80;
    }

    server {
        listen 80;

         location / {
            proxy_pass http://backend;

            # Backend-Hostname als Header übergeben
            proxy_set_header X-Backend-Hostname $upstream_addr;
        }
    }
}

Compose everything

Create a compose.yaml file to define the services:

version: "3.9"

networks:
  default:
    name: loadbalancer1_default

services:
  app1:
    build:
      context: ./app
    container_name: app1
    hostname: app1
    ports:
      - "8081:80"

  app2:
    build:
      context: ./app
    container_name: app2
    hostname: app2
    ports:
      - "8082:80"

  app3:
    build:
      context: ./app
    container_name: app3
    hostname: app3
    ports:
      - "8083:80"

  loadbalancer:
    image: docker.io/nginx:alpine
    container_name: loadbalancer
    ports:
      - "8080:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app1
      - app2
      - app3

Start and test

To start the environment, run:

podman-compose up

Then, open your browser and navigate to http://localhost:8080/. You should see the PHP web interface served from different backend servers, demonstrating the load balancing setup.

Conclusion and Key Learnings

In this guide, we have set up a basic load balancing environment using NGINX and Podman. Here are the key learnings from this exercise:

1. Containerization with Podman: We learned how to containerize a simple PHP application using Podman.
2. Load Balancing with NGINX: We configured NGINX to distribute traffic across multiple instances of our PHP application.
3. Service Composition with Podman Compose: We used Podman Compose to define and manage multiple services, making it easier to orchestrate our application and load balancer.
4. Practical Networking: We explored how to set up networking between containers to enable communication and load balancing.

With these steps, you have a foundational understanding of how to set up load balancing for containerized applications using NGINX and Podman. This setup can be expanded and customized further based on your requirements.

In software development, it is often necessary to securely erase sensitive data from memory as soon as it is no longer needed. This is especially true for passwords, tokens, or other confidential information in security-critical applications. While the concept sounds straightforward, there are some important nuances to consider. In this article, I’ll explain why a simple memset is not sufficient to securely erase memory and provide an overview of alternatives.

The Problem: Why Erasing Isn’t Always Secure

A developer might assume that overwriting memory with a function like memset is enough to erase sensitive data. A naive implementation might look like this:

void insecure_clean(void* ptr, size_t size) {
    memset(ptr, 0, size);
}

However, the issue lies in compiler optimizations. Modern compilers such as gcc or clang analyze code and may detect that the memory cleared by memset is no longer being used. Based on this analysis, the compiler could remove the memset operation entirely to optimize runtime performance.

Attack Vectors

Sensitive data that is not properly erased can be compromised in several ways:

1. Memory Dumps: An attacker could create a core dump or analyze the memory using debugging tools like gdb.
2. Unsafe Memory Deallocation: If memory is freed without being cleared, other programs or threads may access the leftover data.

For example, a password that remains in memory after authentication could be discovered and exploited by an attacker.

The Solution: How to Securely Erase Memory

There are various approaches to securely clear memory. These methods can be general-purpose, platform-specific, or depend on the compiler version. A comprehensive and robust solution is also offered by the external library Libsodium.

1. Using volatile

The volatile keyword prevents the compiler from optimizing out memory-clearing operations. By marking the memory pointer as volatile, the compiler is forced to perform each write operation, even if it considers them redundant. Here’s how it can be used:

void secure_clean(volatile void* ptr, size_t size) {
    volatile unsigned char* p = (volatile unsigned char*)ptr;
    while (size--) {
        *p++ = 0; 
    }
}

2. Using Specialized Platform Functions

Many operating systems or standard libraries provide specialized functions for securely erasing memory. These functions use internal mechanisms to ensure that neither the compiler nor the hardware skips the clearing operation.

Unix

The explicit_bzero function securely erases memory and guarantees that the operation will not be removed by the compiler.

#include <string.h>

explicit_bzero(void *b, size_t len);

Windows

The SecureZeroMemory function ensures that memory is securely cleared.

#include <windows.h>

PVOID SecureZeroMemory(_In_ PVOID  ptr, _In_ SIZE_T cnt);

C23

The new memset_explicit function can also be used to securely overwrite memory.

#include <string.h>

memset_explicit( void *dest, int ch, size_t count );

3. Leveraging External Libraries

Libraries like Libsodium provide robust and platform-independent methods for secure memory erasure. These libraries are designed to securely remove sensitive data from memory while leveraging platform-specific optimizations.

#include <sodium.h>

sodium_memzero(void * const pnt, const size_t len);

4. Additional Security Measures

In addition to securely erasing memory, consider these practices to further protect sensitive data:

• Erase memory immediately: Clear data as soon as it’s no longer needed, rather than keeping it in memory longer than necessary.
• Avoid unnecessary copies: Minimize copies of sensitive data to reduce the number of locations that need to be cleared.
• Prevent memory dumps: Disable core dumps in security-critical applications. For example on Unix:

  ulimit -c 0
  

  ---

Best Practices

1. Prefer platform-specific or library-specific functions like explicit_bzero or sodium_memzero.
2. Use volatile if no specialized function is available.
3. Erase sensitive data immediately once it’s no longer needed.
4. Implement platform-specific mechanisms to protect memory from unauthorized access.

Conclusion

Securely erasing memory is an often-overlooked but critical aspect of software development. Attackers can exploit leftover data in memory if it is not properly erased. Fortunately, there are a variety of proven methods to address this issue. By combining secure memory-clearing functions with best practices, you can ensure that sensitive data is reliably removed from memory.

Further Resources

• Libsodium Documentation
• explicit_bzero(3) - Linux Manual Page
• SecureZeroMemory (Microsoft Docs)
• memset_explicit Documentation