Systemd 2025: Understanding Linux Architecture & Security

Publié par Marc sur 14 Novembre 2025, 02:42am

Complete 2025 guide to Systemd architecture: 6-layer hierarchy, kernel dependencies, security implementation, and D-Bus communication for Linux administrators.

⚙️ Systemd: Complete Architecture

6-Layer Hierarchy, Kernel Dependencies, openSUSE Security

📚 Article for Advanced Multi-System Users

This article covers systemd architecture in depth, kernel-level interactions, and security implications. Ideal for Linux administrators, developers, and system architects.

📑 Interactive Table of Contents

📖 Introduction

🔄 Understanding Communications

🏗️ Chapter 1: Systemd in 6 Layers

🔗 Chapter 2: Kernel Dependencies

🛡️ Chapter 3: openSUSE Security

📡 Chapter 4: D-Bus Communication

⚠️ Chapter 5: Critical Points

✅ Conclusion

📖 Introduction

SystemD is neither a conductor nor a magician. It is a fundamental orchestrator within a layered architecture, ensuring coordinated management of services, system resources and communications distributed across eight architectural levels.

SafeITExperts has performed a complete mapping of this architecture and identified six interconnected functional layers (according to RedHat analysis). We have enriched this study by adding two additional essential layers to precisely define the operational boundaries: what SystemD actually assumes and what escapes its management.

✅Real roles of systemd▼

Service startup/shutdown - nginx, docker, unbound, squid

System resource management - cgroups, memory/CPU limits

Service ordering - at boot

Socket/timer/event activation

🎯 systemd is conductor for:

✅ Service startup/shutdown (nginx, docker, unbound, squid)
✅ System resource management (cgroups, memory/CPU limits)
✅ Service ordering at boot
✅ Socket/timer/event activation

❌systemd is NOT conductor for▼

Direct kernel communication - → hardware (drivers)

Kernel low-level operations - CPU scheduling, memory management

TCP/IP network protocols - managed by kernel

🎯 systemd is NOT conductor for:

❌ Direct kernel → hardware communication (drivers)
❌ Kernel low-level operations (CPU scheduling, memory management)
❌ TCP/IP network protocols (managed by kernel)

🏗️ Systemd Architecture - Corrected Hierarchical Schema (6 Layers)

LAYER 1: PC HARDWARE
CPU, RAM, Storage, GPU, Network, etc.

LAYER 2: LINUX KERNEL
- cgroups, namespaces, seccomp
- D-Bus kernel bus
- autofs, sysfs, procfs, devtmpfs
- Hardware drivers

LAYER 3: SYSTEMD API (Libraries)
- libsystemd-core.so, libsystemd-shared.so
- libsystemd.so (sd-bus, sd-event, etc.)
- System D-Bus interfaces

LAYER 4: SYSTEMD CORE (PID1 - Manager)
- Unit Manager (services, timers)
- Dependency resolution (DAG)
- Transactional job queue
- cgroups hierarchy management
- Main event loop

LAYER 5a: SYSTEMD DAEMONS
journald, logind,
networkd, resolved

LAYER 5b: SYSTEMD TARGETS
multi-user, graphical,
rescue, etc.

LAYER 5c: EXTERNAL SERVICES
nginx, docker,
etc.

LAYER 6: SYSTEMD UTILITIES
- systemctl (start/stop/enable/disable)
- journalctl (log viewing)
- systemd-analyze (boot analysis)
- systemd-run (temporary execution)
- etc.

📋 Hierarchical overview: Hardware (L1) → Kernel (L2) → Libraries (L3) → Core PID1 (L4) → [Daemons (L5a) + Targets (L5b) + External services (L5c)] → Utilities (L6)

Corrected system architecture - 6 layers: from hardware to utilities

🔄 COMMUNICATION UNDERSTANDING - DATA FLOWS

🔄 Systemd communication: Data flows explained with practical examples

Understanding interactions between different layers of systemd architecture

FLOW 1💻 HARDWARE⇄KERNEL▼

BIDIRECTIONAL - Hardware/kernel exchanges

$ sudo dd if=/dev/zero of=/tmp/test.bin bs=1M count=10

├─ call: kernel asks disk controller to write blocks├─ return: controller signals write completion, command ends└─ NOTE: via drivers and hardware interrupts

$ cat /proc/interrupts | head

├─ call: kernel exposes IRQ counting for consultation├─ return: current IRQ table returned to user└─ NOTE: state reading via procfs interfaces

FLOW 2🐧 KERNEL⇄SYSTEMD API▼

BIDIRECTIONAL - Kernel/library interface

$ systemctl start nginx.service

├─ call: PID1 (systemd) opens/parses files and creates process (open(), fork(), execve)├─ return: kernel returns descriptors/retcodes and new service PID└─ NOTE: exchanges via user↔kernel syscalls

$ systemctl show -p MainPID nginx.service

├─ call: PID1 queries internal state, requiring kernel access (stat, read)├─ return: kernel provides values (PID, states), returned to CLI└─ NOTE: standard system call chains

FLOW 3📚 SYSTEMD API⇄SYSTEMD CORE▼

BIDIRECTIONAL - Internal systemd communication

$ systemctl daemon-reload (then action)

├─ call: PID1 asks libsystemd to reparse units (sd_unit_parse) and rearm loop (sd_event_run)├─ return: libsystemd confirms "units reloaded", loop ready (event completion)└─ NOTE: same process, in-process function calls

$ (timer activity) sleep 65; systemctl list-timers

├─ call: PID1 asks libsystemd "check timers/signals/sockets" (sd_event_run)├─ return: libsystemd responds "n events processed" or "timeout"└─ NOTE: internal event loop

FLOW 4⚙️ SYSTEMD CORE⇄SYSTEMD DAEMONS▼

BIDIRECTIONAL - Specialized daemons management

$ systemctl reload systemd-journald

├─ call: PID1 sends signal/reload to journald daemon├─ return: journald acknowledges and updates its status└─ NOTE: signals + internal channels

$ systemctl restart systemd-resolved

├─ call: PID1 stop/starts daemon and updates its units and cgroup├─ return: daemon reports "active (running)" with new PID└─ NOTE: control/status return via PID1

FLOW 5🎯 SYSTEMD CORE➜SYSTEMD TARGETS▼

unidirectional calls - System state orchestration

$ systemctl start multi-user.target

├─ call: PID1 activates target and orchestrates linked services├─ return: ∅ (target doesn't "respond", it's a logical state)└─ NOTE: 1-way orchestration

$ systemctl isolate rescue.target

├─ call: PID1 switches system state to rescue (stops non-required units)├─ return: ∅ (target doesn't emit own response)└─ NOTE: 1-way isolation

FLOW 6🚀 SYSTEMD CORE➜EXTERNAL SERVICES▼

unidirectional calls - User services management

$ systemctl restart nginx.service

├─ call: PID1 sends SIGTERM then fork/exec of nginx binary, creates cgroup├─ return: ∅ (service doesn't command PID1; only emits logs)└─ NOTE: 1-way management + logs via journald

$ systemctl stop docker.service

├─ call: PID1 sends stop signals and waits for service termination├─ return: ∅ (no reverse command; only "stopped/failed/success" state)└─ NOTE: 1-way control by PID1

FLOW 7🖥️ SYSTEMD CORE⇄SYSTEMD UTILITIES▼

BIDIRECTIONAL - User control interface

$ systemctl status nginx.service

├─ call: systemctl sends "give nginx status" to PID1 via D-Bus├─ return: PID1 returns "Active (running), PID 1234, Memory 45MB"└─ NOTE: communication via D-Bus (request/response)

$ systemd-analyze critical-chain

├─ call: utility requests critical boot graph from PID1├─ return: PID1 returns dependency chain and timings└─ NOTE: D-Bus query, CLI-side rendering

FLOW 8🔧 SYSTEMD DAEMONS⇄SYSTEMD UTILITIES▼

BIDIRECTIONAL - Access to specialized services

$ journalctl -u nginx.service -n 50

├─ call: journalctl requests "50 last nginx logs" to journald via D-Bus├─ return: journald returns filtered log entries└─ NOTE: D-Bus org.freedesktop.journal1

$ loginctl list-sessions

├─ call: loginctl requests session list to systemd-logind├─ return: logind returns sessions (UID, seat, state)└─ NOTE: D-Bus org.freedesktop.login1

🏗️ Chapter 1: Systemd in 6 Layers

📌 Fundamental Architecture: systemd organizes itself in 6 distinct layers, from hardware to user interfaces.

LAYER 1💻 PC HARDWARE▼

CPU - Processor

RAM - Memory

Storage - Disks, SSD

GPU - Graphics card

Network - Network cards

🎯 Hardware Foundation

Lowest layer - the physical hardware everything relies on.

🔧 Interaction

Linux kernel (layer 2) communicates directly with hardware via drivers.

LAYER 2🐧 LINUX KERNEL▼

cgroups - Resource control

namespaces - Process isolation

seccomp - System call filtering

D-Bus kernel - System bus

autofs - Auto filesystems

🎯 System Interface

Linux kernel provides all system interfaces needed by systemd.

🔧 Key Features

cgroups - Resource isolation and limitation
namespaces - Process and network isolation
seccomp - Security via syscall filtering
D-Bus - Inter-process communication
autofs - Automatic filesystem mounting

LAYER 3📚 SYSTEMD API (Libraries)▼

libsystemd-core.so - Functional core

libsystemd-shared.so - Shared code

libsystemd.so - Public API (sd-bus, etc.)

D-Bus Interfaces - System communication

🎯 Software Abstraction

Systemd libraries provide abstraction of kernel interfaces.

🔧 Components

libsystemd-core - Main functionalities
libsystemd-shared - Reusable common code
libsystemd - Public API for developers
sd-bus - Simplified D-Bus interface
sd-journal - Journal access

LAYER 4⚙️ SYSTEMD CORE (PID1 - Manager)▼

systemd (PID1) - Main init process

Unit Manager - Units management

Dependency Resolver - DAG resolution

Transaction Processor - Job validation

cgroups Manager - Resource management

🎯 Orchestration Core

The PID1 process that orchestrates the entire system.

🔧 Key Responsibilities

Complete unit management (service, socket, timer, mount)
Dependency resolution (Requires, Wants, Before, After)
Transaction processing (consistency validation)
cgroups hierarchy creation in /sys/fs/cgroup/
State machine for each unit
Event loop handling signals + timers
Manages systemd daemons, targets and external services

LAYER 5a🔧 SYSTEMD DAEMONS▼

systemd-journald - Log journaling

systemd-logind - Session management

systemd-resolved - DNS resolution

systemd-networkd - Network configuration

systemd-udevd - Device management

🔧 Specialized Daemons

Each daemon has a specific role and is managed by Core (PID1):

journald - Centralized logs (binary, secure)
logind - User sessions + suspend/hibernate
resolved - DNS with cache + DNSSEC
networkd - Declarative network configuration
udevd - Hotplug device events

🏗️ Architecture Relation

Daemons are managed by Core (layer 4) and provide services to utilities (layer 6).

LAYER 5b🎯 SYSTEMD TARGETS (System States)▼

bootmode.target - Boot mode

basic.target - Basic services

multi-user.target - Multi-user mode

graphical.target - Graphical interface

user-session.target - User session

reboot.target - System reboot

🎯 Targets Hierarchy

bootmode.target ↓basic.target ↓multi-user.target ├─ dbus.service ├─ telephony.service (Tizen) ├─ dlog.service (Tizen) └─ logind.service ↓graphical.target ↓user-session.target ├─ display-service └─ tizen.service (Tizen)

🔗 Dependencies Management

multi-user.target - Manages critical system services
graphical.target - Depends on multi-user.target
user-session.target - Individual user sessions
Tizen Targets - Specific extensions (telephony, dlog, tizen)

🏗️ Architecture Relation

Targets are special units managed by Core that define system states and group other units. They provide synchronization points for boot and state transitions.

📌 Important Note

Some targets like telephony, bootmode, dlog, tizen service are specific Tizen extensions and are not part of standard systemd components.

LAYER 5c🚀 EXTERNAL SERVICES▼

nginx - Web server

docker - Containerization

postgresql - Database

Business applications - Custom services

🎯 User Services

External services not provided by systemd but managed by it.

🔧 Characteristics

Managed by systemd but developed independently
Configuration via unit files in /etc/systemd/system/
Isolation via cgroups and namespaces
Monitoring and automatic restart
Complete integration with systemd ecosystem

🏗️ Architecture Relation

External services are managed by Core (PID1) just like systemd daemons. They benefit from the same features: monitoring, isolation, dependencies, etc.

LAYER 6🖥️ SYSTEMD UTILITIES▼

systemctl - Service management

journalctl - Log viewing

systemd-analyze - Startup analysis

systemd-run - Transient units

🎯 User Interface

Command line tools to interact with systemd.

🔧 Essential Utilities

systemctl - Service management (start/stop/enable/disable)
journalctl - Log viewing and filtering
systemd-analyze - Boot analysis and security
systemd-run - Command execution in transient units
systemd-cgtop - Real-time resource monitoring

EX 1⏱️ Timer Example: db-backup-daily▼

Type: Timer (periodic activation)

Trigger: OnCalendar daily 02:00

Dependency: Calls db-backup-daily.service

Managed by: Systemd Core (Layer 4)

📄 File: /etc/systemd/system/db-backup-daily.timer

[Unit]Description=Daily Database Backup (Production)Documentation=https://wiki.company.com/db-backup[Timer]OnCalendar=dailyOnCalendar=*-*-* 02:00:00RandomizedDelaySec=1800Persistent=trueUnit=db-backup-daily.service[Install]WantedBy=timers.target

EX 2🔧 Service Example: db-backup-daily▼

Type: Service Unit (Type=oneshot)

Mode: Type=oneshot (single execution)

Trigger: By timer or manual (systemctl start)

Managed by: Systemd Core (Layer 4)

📄 File: /etc/systemd/system/db-backup-daily.service

[Unit]Description=Daily Database Backup Service (Production)After=network-online.target postgresql.serviceRequires=network-online.targetConflicts=db-maintenance.serviceDocumentation=https://wiki.company.com/db-backup[Service]Type=oneshotUser=backupGroup=backupWorkingDirectory=/var/backups/databaseExecStartPre=/usr/local/bin/db-pre-check.shExecStart=/usr/local/bin/db-backup.sh /var/backups/databaseExecStartPost=/usr/local/bin/db-upload-s3.shPrivateTmp=yesNoNewPrivileges=trueProtectSystem=strictProtectHome=yesReadWritePaths=/var/backups/databaseMemoryMax=512MCPUQuota=50%TasksMax=100TimeoutStartSec=3600TimeoutStopSec=300StandardOutput=journalStandardError=journalSyslogIdentifier=db-backup[Install]WantedBy=timers.target

🔗 Execution Flow

Timer triggers (02:00) ↓Systemd Core (PID1) checks dependencies: ├─ network-online.target up? ✓ ├─ postgresql.service running? ✓ └─ db-maintenance.service NOT running? ✓ ↓Fork process as user: backup ↓ExecStartPre: /db-pre-check.sh (validate DB connectivity) ↓ (If success)ExecStart: /db-backup.sh (backup to /var/backups) ↓ (If success)ExecStartPost: /db-upload-s3.sh (upload to S3) ↓ (After all success)Logs to journald (daemon layer 5a) ↓Service state = inactive (Type=oneshot completed)

🛡️ Security Hardening

User=backup # Non root (least privilege principle)PrivateTmp=yes # Isolated mount namespaceNoNewPrivileges=true # No privilege escalationProtectSystem=strict # Filesystem read-only (except /var/backups)MemoryMax=512M # Resource isolation via cgroupCPUQuota=50% # CPU limit (don't starve other services)

Systemd Architecture - Complete overview. Note: kdbus deprecated

🔗 Chapter 2: Systemd => Linux Kernel Dependencies

📌 Complete Architecture: systemd depends on Linux kernel via 5 main interfaces, plus a transverse security layer.

KERNEL 1📦 cgroups (Control Groups)▼

cgroups v1 - Legacy (still used)

cgroups v2 - Unified (modern)

systemd hierarchy - /sys/fs/cgroup/

🎯 Responsibilities

Resource isolation and limitation (CPU, memory, I/O)
Each daemon/service in its own cgroup
Hierarchy: root → system.slice → services
Resource consumption tracking

KERNEL 2🔄 namespaces▼

PID namespace - PID isolation

Mount namespace - Filesystem isolation

Network namespace - Network isolation

User namespace - UID/GID isolation

🎯 Responsibilities

Complete process/service isolation
PrivateTmp=yes → isolated mount namespace
Each service sees its own PID 1 (if containerized)
Security by default (no privilege escalation)

KERNEL 3🔐 capabilities▼

CAP_NET_BIND_SERVICE - Bind ports <1024

CAP_SYS_ADMIN - Admin privileges

CAP_DAC_READ_SEARCH - Bypass DAC

CapabilityBoundingSet - Limit capabilities

🎯 Responsibilities

Granular privilege dropping
No need to run as root for services
Drastically reduced attack surface
CapabilityBoundingSet=~CAP_SYS_PTRACE (block ptrace)

KERNEL 4🚫 seccomp Filtering▼

SeccompMode - Filter syscalls

SystemCallFilter - Allow/deny syscalls

SystemCallArchitectures - Restrict arch

🎯 Responsibilities

Block dangerous system calls
SystemCallFilter=write read close (whitelist)
SystemCallFilter=~execve socket (blacklist)
Mitigation zero-day kernel exploits

KERNEL 5🔌 autofs + kdbus (historical)▼

autofs - Automatic filesystem mounting

kdbus - In-kernel bus (deprecated)

🎯 Responsibilities

autofs: Lazy mounting /var/autofs (resource saving)
kdbus: Historically considered for performant IPC
kdbus Status: ABANDONED (kernel maintainers disagreements)
Current: D-Bus via sd-bus (userspace native)

TRANSVERSE🛡️ Security (Transverse Layer)▼

SELinux - MAC (Mandatory Access Control)

AppArmor - Profile-based confinement

D-Bus Security - Policy-based IPC

🎯 Responsibilities

SELinux: Fine-grained access control (contexts)
AppArmor: Profile-based (path, permissions)
D-Bus Security: Secure transports (Unix sockets + encryption)
systemd Compatibility: All three supported + active together
DynamicUser=yes: Ephemeral user creation (least privilege)

📊 Consultation

journalctl -p warning -S today # Warning logs todayjournalctl --since "2 days ago" -o json

⚠️ Important Note: DynamicUser=yes

DynamicUser=yes creates ephemeral users (dynamic UIDs) for each service. Least privilege principle: each service has its own unique UID, invalidated after stop. Maximum security + complete isolation.

📌 Useful openSUSE Commands

# Analyze service securitysystemd-analyze security nginx.service# View cgroups hierarchysystemd-cgls# View used resourcessystemd-cgtop# View target dependenciessystemctl list-dependencies multi-user.target

📡 Chapter 4: D-Bus / varlink Communication

📌 Central IPC Mechanism: D-Bus is the communication system allowing all utilities to communicate with systemd PID1. varlink emerges as modern protocol.

D-BUS 1📡 Communication Flow: systemctl start▼

systemctl start - CLI utility

sd-bus library - D-Bus connection

D-Bus socket - IPC transport

systemd PID1 - Manager reception

🔄 Complete Flow

$ systemctl start nginx.service ↓1. systemctl parse arguments ↓2. Connect to D-Bus (sd-bus library) └─ /run/dbus/system_bus_socket ↓3. Authenticate with D-Bus daemon ↓4. Call org.freedesktop.systemd1.Manager.StartUnit() ↓5. D-Bus router delivers message to systemd PID1 ↓6. systemd manager processes job ├─ Creates Job object ├─ Queues in job-queue └─ Sends back job ID ↓7. systemctl waits for result (or returns immediately) ↓8. systemd event loop executes job

D-BUS 2🎯 systemd D-Bus Interfaces▼

org.freedesktop.systemd1.Manager - Global control

org.freedesktop.systemd1.Unit - Per-unit ops

org.freedesktop.systemd1.Service - Service specifics

🔧 Main Methods

Manager: StartUnit(), StopUnit(), RestartUnit(), ReloadUnit()
Unit: Start(), Stop(), Reload(), Restart(), TryRestart()
Service: SetProperties(), ClearProperties()

📊 Properties

Unit: ActiveState, SubState, Description, LoadState
Service: TimeoutStartUSec, TimeoutStopUSec, Restart

D-BUS 3🚀 varlink (Modern JSON Protocol)▼

varlink protocol - JSON-based RPC

Modern replacement - D-Bus + JSON

Future direction - Progressive adoption

📌 Characteristics

Protocol: JSON-based RPC over Unix sockets
Advantages: Simpler than D-Bus, better performance
Status: Progressive adoption (some systemd interfaces)
Future: Will progressively replace D-Bus for systemd
Compatibility: D-Bus remains for backward compatibility

D-BUS 4🔐 D-Bus Security▼

Unix sockets - Secure transports

D-Bus policy - Authorization rules

SELinux integration - MAC enforcement

🛡️ Mechanisms

Socket Security: Unix permissions on /run/dbus/ (mode 0700)
Policy Engine: /etc/dbus-1/system.d/ (allow/deny rules)
SELinux: Full MAC integration for D-Bus transports
Encryption: Unix sockets + credentials passing

Enable SELinux + AppArmor + systemd hardening
Analyze: systemd-analyze security service.service
Configure CapabilityBoundingSet strictly
Use SystemCallFilter to block dangerous calls
Configure DynamicUser=yes (ephemeral users)

✅ Conclusion & Key Points

CONC 1📚 6 Hierarchical Layers▼

Hardware → Kernel → Libraries → Core → Services → Utilities

🎯 Nested Architecture

Each layer depends on the previous one. Crash of one layer = crash of everything that depends on it.

✅ Impact

Understanding this hierarchy = understanding where to debug. systemctl problem? Check D-Bus. D-Bus problem? Check systemd PID1. PID1 problem? Check systemd libraries.

CONC 2🔗 5 Kernel Interfaces + Security▼

cgroups, namespaces, capabilities, seccomp, autofs + SELinux/D-Bus

🎯 Defense-in-Depth

Not a single security layer, but 5+ simultaneously. Each complementary. Attacker must go through ALL to compromise system.

✅ Impact

Systemd security = very robust. Even if one layer bypassed, others stop the attack.

systemd-analyze security - Security score

systemd-cgtop - RT resource monitor

journalctl - Centralized logs

🎯 Production Ops

Best practices: monitor, audit, document. Use systemd-analyze security regularly. Configure journalctl alerts.

✅ Checklist

Analyze security: systemd-analyze security APP.service
Audit dependencies: systemctl list-dependencies --all
Monitor resources: systemd-cgtop continuously
Configure DynamicUser=yes (ephemeral users)
Implement custom CapabilityBoundingSet
Test boot regularly: systemctl reboot
Document systemd security strategy

⬆️

ARTICLES📖 Related Articles▼

Linux 2025 - In-depth analyses

Architectures - Environments and systems

Evolution - Trends and innovations

🎯 Recommended Articles

🔍 Topics Covered

These articles delve into topics related to the modern Linux ecosystem, system architecture, and emerging trends in 2025.

REFERENCES🔗 Official Documentation▼

Systemd - Complete documentation

Linux Kernel - Guides and manuals

openSUSE - Specific documentation

🎯 Official Sources

📚 Technical Resources

Official documentation to deepen the technical concepts covered in this article, including systemd, the Linux kernel, and security mechanisms.

🏆 systemd Documentation - Complete Architecture for Advanced Users

Sources: systemd.io | man pages | Linux kernel docs

For SafeITExperts - In-depth technical article | Final Corrected Version - 6-Layer Architecture Validated

⬆️

Systemd 2025 : Architecture Hiérarchique et Sécurité Linux

Commenter cet article