This is a valid Atom 1.0 feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Paul Hammond’s Journal</title>
<link href="http://www.paulhammond.org/feeds/journal" rel="self"/>
<link href="http://www.paulhammond.org/journal/" rel="alternate"/>
<id>tag:paulhammond.org,2008:feeds/atom</id>
<updated>2022-05-06T16:18:23-07:00</updated>
<author>
<name>Paul Hammond</name>
</author>
<entry>
<title>CVE-2021-31213</title>
<link href="http://www.paulhammond.org/2021/cve-2021-31213/" rel="alternate"/>
<id>tag:paulhammond.org,2008:post/1621959170</id>
<updated>2021-05-25T09:12:50-07:00</updated>
<content type="html"><p>Sometimes while I’m working on a project I have a sudden realization that two
components aren’t connected the way everyone thinks they are. Often this is just
a bug, usually one the team has been chasing for a while. Occasionally it’s a
security hole. But I rarely get to write about it because the components are
deep inside the infrastructure of a company that pays my wages.</p>
<p>Recently I had this experience while working with <a href="https://code.visualstudio.com/docs/remote/containers">Visual Studio Code Remote
Containers</a> which resulted in my first <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31213">public CVE
number</a>, so I’m going to take a moment to write about it, remind
you that it’s easy to escape a Docker container, and that developer laptops are
probably the weakest link in any company’s security.</p>
<p>VS Code has an action called “Remote-Containers: Clone Repository in Container
Volume” which automates the process of downloading a codebase, installing all of
the dependencies in a Docker container, running that container, and attaching
your editor. I found a small problem: it’s possible for code in the the
repository to escape the sandbox provided by Docker and get root privileges on
the host system.</p>
<p>To do this you need to do two things:</p>
<ul>
<li>You need to run arbitrary code inside the container. Usually VSCode ignores the
Docker <a href="https://docs.docker.com/engine/reference/builder/#entrypoint">entrypoint</a> and always runs its own shell scripts, but there are many
ways to get it to do something else. For example you can replace <code>/bin/sh</code> with a
shell script that runs whatever you want, or just provide a <a href="https://code.visualstudio.com/docs/remote/devcontainerjson-reference"><code>postCreate</code> or
<code>postAttach</code> command</a>.</li>
<li>You need to escape the container. The <a href="https://code.visualstudio.com/docs/remote/devcontainerjson-reference"><code>devcontainer.json</code></a> file inside the
repository can specify arguments to the <code>docker run</code> command, which gives it the
ability to mount almost any directory in the container. Notably you can mount
the Docker socket file, and once you have access to that <a href="https://news.ycombinator.com/item?id=17983623">you can get root
privileges on the host system</a>.</li>
</ul>
<p>Combine these and someone just clicking on UI elements inside VSCode can find
their laptop compromised. After I reported the issue Microsoft added a simple
warning before you perform the action, which is about as good a fix as they can
do given there are so many possible variations on both halves of this attack.</p>
<p>Even though I’m writing about it and I reported it to <a href="https://www.microsoft.com/en-us/msrc">Microsoft
Security</a>, I don’t think this is a serious bug. Programmers have been
downloading untrusted code and running it locally since before I was born and
there are much easier ways to convince them to do this than a little known
feature of a VS Code extension. <code>curl | sudo bash</code> or <code>./configure &amp;&amp; make &amp;&amp; sudo make install</code> are the two obvious variations, but any time you run
something like <code>npm install</code> followed by <code>npm start</code> you’re hoping that none of
the repositories you just downloaded contain anything malicious.</p>
<p>I also think the style of containerized development environment that Microsoft
are building is likely to eventually be more secure than directories on laptops,
even if there are problems along the way. Variations on this attack will have to
be more advanced to work on a hosted product such as <a href="https://github.com/features/codespaces">Github
Codespaces</a>. The costs of a sandbox escape there are a lot higher,
so the development team does more work to avoid them and it’s more likely that
centralized intrusion detection will catch an attack in action. And, even if
someone did manage to escape, the impact is lower; they&#39;ll only have access to a
few other projects that happen to be running on the same server, and not access
to all of your keys, tokens and every photo you’ve taken in the last few years.</p>
<p>My experience is that developers demand the ability to run anything they want on
their computers, even at companies with tightly locked down device management
policies. I’m also only aware of maybe a dozen companies where long-lived
production credentials never ever touch developer laptops. Given the apparent
rise of software supply chain attacks recently, I wonder if both of those should
change. Or maybe we’ll keep stumbling along hoping for the best.</p>
</content>
</entry><entry>
<title>Faster Node.js VS Code containers with RAM disks</title>
<link href="http://www.paulhammond.org/2020/vscode-ramdisks/" rel="alternate"/>
<id>tag:paulhammond.org,2008:post/1603491734</id>
<updated>2020-10-23T15:22:14-07:00</updated>
<content type="html"><p>I’ve switched all of my development over to
<a href="https://code.visualstudio.com/docs/remote/containers">VS Code Remote Containers</a> and it’s working really well.
Having every project isolated with its own runtime means I don’t have to upgrade
every project at the same time, and I no longer find that half my projects have
broken thanks to a macOS or homebrew upgrade.</p>
<p>The one challenge is that Node.js projects can be much slower when running in a
container. This is not surprising, since these projects usually have tens of
thousands of files inside the <code>node_modules</code> directory. That directory is inside
a <a href="https://docs.docker.com/storage/bind-mounts/">Docker bind mount</a> and Hyperkit needs to do a lot of extra
work to keep all those files in sync with the host computer.</p>
<p>The VS Code documentation discusses this problem and suggest
<a href="https://code.visualstudio.com/docs/remote/containers-advanced#_use-a-targeted-named-volume">using a named volume to improve disk performance</a>, but
doing this requires managing Docker volumes outside of VS Code, and in my
subjective experience didn’t seem to result in much improvement in speed.</p>
<p>Instead, I’ve started using RAM disks, which are faster and can be managed
entirely within the <code>devcontainer.json</code> file:</p>
<pre><code>{
&#34;name&#34;: &#34;node&#34;,
&#34;build&#34;: { &#34;dockerfile&#34;: &#34;Dockerfile&#34; },
&#34;runArgs&#34;: [
&#34;--tmpfs&#34;,
&#34;${containerWorkspaceFolder}/node_modules:exec&#34;
],
&#34;postStartCommand&#34;:
&#34;sudo chown node node_modules &amp;&amp; npm i&#34;,
…
}
</code></pre>
<p>The <code>runargs</code> config adds an argument to the <code>docker run</code> command. This
particular argument tells Docker to create a new <code>tmpfs</code> at
<code>/workspaces/project/node_modules</code> . The <code>exec</code> flag is needed by a handful of
packages that install helper scripts, otherwise Linux will ignore the executable
bit on those files.</p>
<p>The <code>postStartCommand</code> then ensures that every time the container is started we
give the <code>node</code> user write access to this directory. We also run <code>npm i</code> for
good measure.</p>
<p>The end result is a container where <code>node_modules</code> is stored in RAM, and Docker
knows that it’s not important data so doesn’t do extra work to sync it to disk.
As a result everything is faster.</p>
</content>
</entry>
</feed>
If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src
attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//www.paulhammond.org/feeds/journal.rss