Forem: Marco Cadetg

More Security With Landlock

Marco Cadetg — Sat, 06 Dec 2025 17:25:00 +0000

Network monitoring tools like RustNet process untrusted data from the wire. This makes them vulnerable to protocol exploits and crafted payloads. If an attacker finds a bug in packet parsing, they could read sensitive files, steal data, or open reverse shells. This has happened with Wireshark before, and since we use pcap, we could face the same issues. This got me thinking about defense-in-depth: what if the tool could sandbox itself after initialization?

The Problem with Privileged Tools

Network capture tools require elevated privileges. On Linux, CAP_NET_RAW allows creating raw sockets to capture packets. But once you have this capability, you usually keep it for the entire process lifetime—even though you only need it during initialization.

# Traditional approach: run with elevated privileges
sudo ./network-tool --interface eth0
# Tool now has CAP_NET_RAW for its entire lifetime

This creates a larger attack surface than necessary. If a bug in Deep Packet Inspection (DPI) code is exploited, the attacker inherits all the privileges the process has.

Enter Landlock

Landlock is a Linux Security Module (LSM) that allows unprivileged sandboxing. Unlike seccomp (which filters syscalls) or namespaces (which need privileges to set up), Landlock lets a process restrict itself. It's been in the kernel since 5.13 (filesystem), and network restrictions were added in 6.4.

The key insight: sandbox after initialization, not before. We can:

Open packet capture handles (needs CAP_NET_RAW)
Load eBPF programs (needs CAP_BPF)
Create log files (needs filesystem write access)
Then apply Landlock restrictions
Then drop CAP_NET_RAW

The existing pcap handle remains valid—the kernel doesn't revoke it. But new raw sockets? Blocked.

Implementation

The Landlock API involves creating a ruleset, adding rules, and enforcing it:

pub fn apply_sandbox(config: &SandboxConfig) -> Result<SandboxResult> {
    // Check kernel support
    let abi_version = landlock_create_ruleset(
        ptr::null(),
        0,
        LANDLOCK_CREATE_RULESET_VERSION
    );

    if abi_version < 0 {
        return Ok(SandboxResult::not_available("Landlock not supported"));
    }

    // Create ruleset with desired restrictions
    let ruleset_attr = landlock_ruleset_attr {
        handled_access_fs: LANDLOCK_ACCESS_FS_EXECUTE
            | LANDLOCK_ACCESS_FS_READ_FILE
            | LANDLOCK_ACCESS_FS_WRITE_FILE
            | /* ... more flags ... */,
        handled_access_net: LANDLOCK_ACCESS_NET_BIND_TCP
            | LANDLOCK_ACCESS_NET_CONNECT_TCP,
    };

    let ruleset_fd = landlock_create_ruleset(&ruleset_attr, ...);

    // Allow reading /proc (needed for process identification)
    add_path_rule(ruleset_fd, "/proc", LANDLOCK_ACCESS_FS_READ_FILE)?;

    // Allow writing to configured log paths
    for path in &config.allowed_write_paths {
        add_path_rule(ruleset_fd, path, LANDLOCK_ACCESS_FS_WRITE_FILE)?;
    }

    // Enforce the ruleset
    landlock_restrict_self(ruleset_fd, 0)?;

    Ok(SandboxResult::success())
}

We allow /proc reads (needed for process lookup) but block everything else. Network restrictions block TCP bind/connect entirely. RustNet is a passive monitor, so it doesn't need outbound connections.

Dropping Capabilities

After the sandbox is applied, we drop CAP_NET_RAW:

pub fn drop_cap_net_raw() -> Result<bool> {
    let mut caps = CapSet::empty();

    // Read current capabilities
    capget(&mut header, &mut caps)?;

    // Clear CAP_NET_RAW from all sets
    caps.effective &= !(1 << CAP_NET_RAW);
    caps.permitted &= !(1 << CAP_NET_RAW);
    caps.inheritable &= !(1 << CAP_NET_RAW);

    // Apply
    capset(&header, &caps)?;

    Ok(true)
}

Is This Actually Useful?

How much do we gain from this? I'm honestly not sure.

The problem is CAP_BPF. We can't drop it because RustNet uses eBPF for process lookup - mapping network connections to processes with low overhead. We could fall back to procfs scanning, but that's slower and we'd lose some functionality.

So even after sandboxing, an attacker who exploits RustNet still has:

CAP_BPF - a powerful capability that allows loading eBPF programs
The open pcap handle - they can still capture packets
Read access to /proc - process information is still available

In the worst case, Landlock is just another layer that doesn't actually stop a determined attacker. If someone finds a way around the filesystem restrictions, they're back to having most of what they need.

That said, defense-in-depth is about raising the bar, not building perfect walls. Landlock blocks the easy paths: no writing to arbitrary files, no opening network connections, no executing binaries. An attacker now needs a Landlock bypass on top of their initial exploit. That's harder than just having full access from the start.

Is it worth the added complexity? I think so, but I'm not completely convinced.

Graceful Degradation

Not all environments support Landlock:

Kernel < 5.13: No Landlock support—continue without sandbox
Kernel 5.13-6.3: Filesystem restrictions only, no network
Kernel 6.4+: Full filesystem + network restrictions
Docker/containers: seccomp may block landlock_* syscalls

The tool checks what's available and applies what it can:

let result = apply_sandbox(&config);

match result.status {
    SandboxStatus::FullyEnforced => info!("Sandbox fully applied"),
    SandboxStatus::PartiallyEnforced => warn!("Partial sandbox: {}", result.details),
    SandboxStatus::NotAvailable => warn!("Sandboxing unavailable: {}", result.reason),
}

// Continue running either way—don't fail on missing sandbox

For high-security environments, a --sandbox-strict flag makes the tool exit if full enforcement isn't possible.

The UI Feedback Loop

I wanted to see the sandbox status clearly. RustNet's TUI now shows:

┌─Security────────────────────────────────────────┐
│ Landlock: Fully enforced [kernel supported]     |
│ CAP_NET_RAW dropped, FS restricted, Net blocked |
└─────────────────────────────────────────────────┘

This makes it clear whether Landlock is active.

Why Catching Short-Lived Processes Requires eBPF on Linux but Just a Header on macOS

Marco Cadetg — Mon, 22 Sep 2025 15:56:13 +0000

TL;DR

macOS's PKTAP provides process info directly in packet headers (10 lines of code), while Linux requires eBPF programs hooking into kernel functions (100+ lines). Both solve the problem of identifying which process owns network packets but with very different complexity levels.

📚 This is Part 1 of my "Building a Network Monitor" series.
Coming next: Implementing Process Detection in RustNet: The Code

The Challenge
macOS: The PKTAP Approach
Linux: The Powerful but Complex eBPF Route
The Trade-offs
Implementation Notes

The Challenge

Traditional approaches like polling /proc/net/* on Linux or running lsof in a loop on macOS work well for long-lived connections, but they struggle with short-lived processes. By the time you poll, the process might already be gone, leaving you with orphaned connections whose origins remain a mystery. For example when running curl.

While working on adding process identification to the network monitoring tool RustNet, I discovered interesting differences in how macOS and Linux tackle this challenge.

How The Data Flows

macOS PKTAP:

Packet → Kernel → [+Process Info] → PKTAP Header → Your App
         ↑
         Automatic!

Linux eBPF:

Packet → Kernel Function → eBPF Hook → Map → Userspace
           ↑                    ↑        ↑
      tcp_connect()     You write this   You poll this
      udp_sendmsg()
      (and 10 more...)

macOS: The PKTAP Approach

macOS provides PKTAP (Packet Tap), where the kernel automatically includes process information in packet headers. This makes implementation very simple:

// From Apple's darwin-xnu (bsd/net/pktap.h)
struct pktap_header {
    // ... other fields
    pid_t pth_pid;        // Process ID
    char pth_comm[17];    // Process name (MAXCOMLEN + 1)
    pid_t pth_epid;       // Effective process ID
    char pth_ecomm[17];   // Effective command name
    // ... more fields
};

You simply read packets and the process info is right there in the header. The kernel handles all the heavy lifting of mapping packets to processes. Want to know which process sent a packet? Just parse the header:

pub fn get_process_info(&self) -> (Option<String>, Option<u32>) {
    let process_name = extract_process_name_from_bytes(&self.pth_comm);
    let pid = if self.pth_epid != 0 {
        Some(self.pth_epid as u32)
    } else {
        None
    };
    (process_name, pid)
}

That's it. Clean, simple, and it works for most packets. Interestingly, some packet types (like ICMP and ARP) don't always include process information—likely because they're handled differently by the kernel or lack a clear originating process context.

Linux: The Powerful but Complex eBPF Route

Linux doesn't have an equivalent to PKTAP, so one solution involves using eBPF programs that hook into kernel networking functions:

SEC("kprobe/tcp_connect")
int trace_tcp_connect(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1_CORE(ctx);

    // Extract network info from socket
    key.saddr[0] = BPF_CORE_READ(sk, __sk_common.skc_rcv_saddr);
    key.daddr[0] = BPF_CORE_READ(sk, __sk_common.skc_daddr);

    // Get process info
    info.pid = bpf_get_current_pid_tgid() >> 32;
    bpf_get_current_comm(&info.comm, sizeof(info.comm));

    // Store in map for userspace retrieval
    bpf_map_update_elem(&socket_map, &key, &info, BPF_ANY);
    return 0;
}

But here is where it gets interesting (and complicated):

You need separate kprobes for tcp_connect, inet_csk_accept, udp_sendmsg, tcp_v6_connect, etc.
The comm field is limited to 16 characters—so "Firefox" becomes "Socket Thread"
You must understand kernel internals—socket structures, CO-RE relocations, BTF
Build complexity: Requires libelf, clang, LLVM, and kernel headers

The Trade-offs

macOS PKTAP Pros:

Dead simple API
Works out of the box
Full process names (when available)
Zero kernel programming required
Automatic process-packet association for most traffic

macOS PKTAP Cons:

macOS only (possibly other BSDs)
Requires special interface setup
Limited to what Apple exposes
Some packet types (ICMP, ARP) may lack process info

Linux eBPF Pros:

Incredibly powerful and flexible
Can hook into virtually any kernel function
Lower overhead than polling
Works on most modern kernels

Linux eBPF Cons:

Steep learning curve
Complex build requirements
16-char process name limit (comm field)
Must handle kernel version differences
More moving parts

Quick Comparison

Aspect	macOS PKTAP	Linux eBPF
Lines of Code	~10	~100+
Setup Complexity	None	Requires kernel headers, LLVM, libelf
Process Name Limit	17 chars	16 chars
Kernel Programming	No	Yes
Learning Curve	Minutes	Days/Weeks
Availability	macOS only	Linux 4.x+

Implementation Notes

For RustNet, I ended up using libbpf instead of Rust's aya framework specifically to avoid the rust nightly toolchain dependency. While aya offers more idiomatic Rust, libbpf's stability and broader compatibility made it the better choice for this project.

The contrast really highlights different OS design philosophies: macOS provides high-level, purpose-built APIs versus Linux offering low-level primitives that can be composed into powerful solutions, albeit with significantly more complexity.

Both approaches solve the same problem effectively, but the developer experience is very different. I wonder if Linux could benefit from higher-level networking APIs like PKTAP, though perhaps that's antithetical to the Unix philosophy of composable tools.

Note on the comm field: The 16-character limitation is a kernel constraint where thread names get truncated. Firefox appears as "Socket Thread", Chrome as "ThreadPoolForeg", etc. You can work around it by combining eBPF with selective procfs lookups, but that defeats some of the performance benefits.

💭 Discussion Points

Have you worked with PKTAP or eBPF? What was your experience?
Is Linux's complexity justified by the flexibility it provides?
Should Linux add a simpler API like PKTAP for common use cases?
Any Windows developers here? How does Windows handle this problem?
What other OS-specific networking APIs have you discovered?

🔗 See It In Action

This implementation is part of RustNet, a cross-platform network monitoring TUI where you can see both approaches in action. The eBPF implementation is available in v0.9.0 as an experimental feature (--features=ebpf).

If you're interested in network monitoring, packet inspection, or just want to see how different operating systems handle the same problem, check out the project. I'm always looking for feedback and contributions!

Originally published on my blog. Follow me for more posts about systems programming, Rust, and the interesting quirks of different operating systems.