<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Linux Security on Nalar</title>
    <link>https://nalar.dev/tags/linux-security/</link>
    <description>Recent content in Linux Security on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/linux-security/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Landlock Rulesets Restrict Future Path Access, Not Open File Authority</title>
      <link>https://nalar.dev/landlock-rulesets-restrict-future-path-access-not-open-file-authority/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/landlock-rulesets-restrict-future-path-access-not-open-file-authority/</guid>
      <description>&lt;h1 id=&#34;landlock-rulesets-restrict-future-path-access-not-open-file-authority&#34;&gt;Landlock Rulesets Restrict Future Path Access, Not Open File Authority&lt;/h1&gt;&#xA;&lt;p&gt;A process opens a writable configuration file, installs a restrictive Landlock ruleset, and then continues running code that should have access only to a small working directory. The later policy can block a fresh attempt to open that configuration path, yet the descriptor obtained before confinement remains usable. The filesystem view has narrowed, but authority already materialized as an open file has not vanished.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Memfd Seals Turn Shared Memory Into Monotonic File Policy</title>
      <link>https://nalar.dev/memfd-seals-turn-shared-memory-into-monotonic-file-policy/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/memfd-seals-turn-shared-memory-into-monotonic-file-policy/</guid>
      <description>&lt;h1 id=&#34;memfd-seals-turn-shared-memory-into-monotonic-file-policy&#34;&gt;Memfd Seals Turn Shared Memory Into Monotonic File Policy&lt;/h1&gt;&#xA;&lt;p&gt;A process prepares a binary object in memory, passes its file descriptor to another process, and expects the bytes to remain stable after validation. Ordinary shared memory does not provide that property by itself: another holder of writable authority can change the object after a check, resize it, or keep a writable mapping alive. Linux file seals provide a narrower contract. They remove selected mutation operations from a sealable file, and successfully added seals cannot later be removed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Seccomp Filters Reduce Syscall Surface Without Forming a Complete Sandbox</title>
      <link>https://nalar.dev/seccomp-filters-reduce-syscall-surface-without-forming-a-complete-sandbox/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/seccomp-filters-reduce-syscall-surface-without-forming-a-complete-sandbox/</guid>
      <description>&lt;h1 id=&#34;seccomp-filters-reduce-syscall-surface-without-forming-a-complete-sandbox&#34;&gt;Seccomp Filters Reduce Syscall Surface Without Forming a Complete Sandbox&lt;/h1&gt;&#xA;&lt;p&gt;A service can run with a short seccomp allowlist and still retain broad authority through file descriptors, filesystem permissions, network endpoints, and credentials. The filter may sharply reduce the kernel interfaces reachable through system calls, yet the process can remain capable of damaging actions through operations that are explicitly allowed. This is the central boundary of seccomp: it filters syscall attempts; it does not define the full security policy of a process.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
