<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Easyseccomp on *scratch*</title>
    <link>https://www.scrivano.org/tags/easyseccomp/</link>
    <description>Recent content in Easyseccomp on *scratch*</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 06 Jun 2026 10:03:54 +0000</lastBuildDate>
    <atom:link href="https://www.scrivano.org/tags/easyseccomp/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Seccomp made easy</title>
      <link>https://www.scrivano.org/posts/2021-01-30-easyseccomp/</link>
      <pubDate>Sat, 30 Jan 2021 21:10:14 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2021-01-30-easyseccomp/</guid>
      <description>&lt;p&gt;Seccomp is a kernel feature that restricts what syscalls can be used by a process. The allowed syscalls are described as a BPF program that the kernel evaluates on every syscall entry. While effective, writing and maintaining seccomp profiles in the JSON format expected by OCI runtimes is tedious, and the underlying libseccomp API has surprising constraints — particularly around combining per-argument rules for the same syscall — that make complex policies difficult to express correctly.&lt;/p&gt;&#xA;&lt;p&gt;Almost every container runs with seccomp enabled to restrict its&#xA;access to syscalls.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
