<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>chs.us — Carl Sampson</title><link>https://chs.us/</link><description/><language>en-us</language><managingEditor>carl.sampson@gmail.com (Carl Sampson)</managingEditor><webMaster>carl.sampson@gmail.com (Carl Sampson)</webMaster><lastBuildDate>Wed, 15 Jul 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://chs.us/tags/landlock/index.xml" rel="self" type="application/rss+xml"/><item><title>Six layers to sandbox untrusted Python — and the escape I missed</title><link>https://chs.us/2026/07/sandboxing-untrusted-python/</link><pubDate>Wed, 15 Jul 2026 12:00:00 +0000</pubDate><author>carl.sampson@gmail.com (Carl Sampson)</author><guid>https://chs.us/2026/07/sandboxing-untrusted-python/</guid><description>Letting users run their own Python to shape your server&amp;#39;s responses means executing untrusted code in production. Here are the six independent layers that contain it, why each exists, and the AST-bypass that slipped through all the early ones.</description><category>Security</category><category>Sandbox</category><category>Python</category><category>Seccomp</category><category>Landlock</category><category>Appsec</category><category>Oast</category></item></channel></rss>