FEED Validator

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

• line 5, column 68: Self reference doesn't match document location [help]

    <link href="http://www.paulhammond.org/feeds/journal" rel="self"/>
                                                                      ^

Source: http://www.paulhammond.org/feeds/journal.rss

1. <?xml version="1.0" encoding="utf-8"?>
2. <feed xmlns="http://www.w3.org/2005/Atom">
3.  
4.  <title>Paul Hammond’s Journal</title>
5.  <link href="http://www.paulhammond.org/feeds/journal" rel="self"/>
6.  <link href="http://www.paulhammond.org/journal/" rel="alternate"/>
7.  <id>tag:paulhammond.org,2008:feeds/atom</id>
8.  <updated>2022-05-06T16:18:23-07:00</updated>
9.  <author>
10.    <name>Paul Hammond</name>
11.  </author>
12.  <entry>
13.      <title>CVE-2021-31213</title>
14.      <link href="http://www.paulhammond.org/2021/cve-2021-31213/" rel="alternate"/>
15.      <id>tag:paulhammond.org,2008:post/1621959170</id>
16.      <updated>2021-05-25T09:12:50-07:00</updated>
17.      <content type="html">&lt;p&gt;Sometimes while I’m working on a project I have a sudden realization that two
18. components aren’t connected the way everyone thinks they are. Often this is just
19. a bug, usually one the team has been chasing for a while. Occasionally it’s a
20. security hole. But I rarely get to write about it because the components are
21. deep inside the infrastructure of a company that pays my wages.</p>
22. <p>Recently I had this experience while working with <a href="https://code.visualstudio.com/docs/remote/containers">Visual Studio Code Remote
23. Containers</a> which resulted in my first <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31213">public CVE
24. number</a>, so I’m going to take a moment to write about it, remind
25. you that it’s easy to escape a Docker container, and that developer laptops are
26. probably the weakest link in any company’s security.</p>
27. <p>VS Code has an action called “Remote-Containers: Clone Repository in Container
28. Volume” which automates the process of downloading a codebase, installing all of
29. the dependencies in a Docker container, running that container, and attaching
30. your editor. I found a small problem: it’s possible for code in the the
31. repository to escape the sandbox provided by Docker and get root privileges on
32. the host system.</p>
33. <p>To do this you need to do two things:</p>
34. <ul>
35. <li>You need to run arbitrary code inside the container. Usually VSCode ignores the
36. Docker <a href="https://docs.docker.com/engine/reference/builder/#entrypoint">entrypoint</a> and always runs its own shell scripts, but there are many
37. ways to get it to do something else. For example you can replace <code>/bin/sh</code> with a
38. 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
39. <code>postAttach</code> command</a>.</li>
40. <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
41. repository can specify arguments to the <code>docker run</code> command, which gives it the
42. ability to mount almost any directory in the container. Notably you can mount
43. the Docker socket file, and once you have access to that <a href="https://news.ycombinator.com/item?id=17983623">you can get root
44. privileges on the host system</a>.</li>
45. </ul>
46. <p>Combine these and someone just clicking on UI elements inside VSCode can find
47. their laptop compromised. After I reported the issue Microsoft added a simple
48. warning before you perform the action, which is about as good a fix as they can
49. do given there are so many possible variations on both halves of this attack.</p>
50. <p>Even though I’m writing about it and I reported it to <a href="https://www.microsoft.com/en-us/msrc">Microsoft
51. Security</a>, I don’t think this is a serious bug. Programmers have been
52. downloading untrusted code and running it locally since before I was born and
53. there are much easier ways to convince them to do this than a little known
54. feature of a VS Code extension. <code>curl | sudo bash</code> or <code>./configure && make && sudo make install</code> are the two obvious variations, but any time you run
55. something like <code>npm install</code> followed by <code>npm start</code> you’re hoping that none of
56. the repositories you just downloaded contain anything malicious.</p>
57. <p>I also think the style of containerized development environment that Microsoft
58. are building is likely to eventually be more secure than directories on laptops,
59. even if there are problems along the way. Variations on this attack will have to
60. be more advanced to work on a hosted product such as <a href="https://github.com/features/codespaces">Github
61. Codespaces</a>. The costs of a sandbox escape there are a lot higher,
62. so the development team does more work to avoid them and it’s more likely that
63. centralized intrusion detection will catch an attack in action. And, even if
64. someone did manage to escape, the impact is lower; they'll only have access to a
65. few other projects that happen to be running on the same server, and not access
66. to all of your keys, tokens and every photo you’ve taken in the last few years.</p>
67. <p>My experience is that developers demand the ability to run anything they want on
68. their computers, even at companies with tightly locked down device management
69. policies. I’m also only aware of maybe a dozen companies where long-lived
70. production credentials never ever touch developer laptops. Given the apparent
71. rise of software supply chain attacks recently, I wonder if both of those should
72. change. Or maybe we’ll keep stumbling along hoping for the best.</p>
73. </content>
74.    </entry><entry>
75.      <title>Faster Node.js VS Code containers with RAM disks</title>
76.      <link href="http://www.paulhammond.org/2020/vscode-ramdisks/" rel="alternate"/>
77.      <id>tag:paulhammond.org,2008:post/1603491734</id>
78.      <updated>2020-10-23T15:22:14-07:00</updated>
79.      <content type="html">&lt;p&gt;I’ve switched all of my development over to
80. <a href="https://code.visualstudio.com/docs/remote/containers">VS Code Remote Containers</a> and it’s working really well.
81. Having every project isolated with its own runtime means I don’t have to upgrade
82. every project at the same time, and I no longer find that half my projects have
83. broken thanks to a macOS or homebrew upgrade.</p>
84. <p>The one challenge is that Node.js projects can be much slower when running in a
85. container. This is not surprising, since these projects usually have tens of
86. thousands of files inside the <code>node_modules</code> directory. That directory is inside
87. a <a href="https://docs.docker.com/storage/bind-mounts/">Docker bind mount</a> and Hyperkit needs to do a lot of extra
88. work to keep all those files in sync with the host computer.</p>
89. <p>The VS Code documentation discusses this problem and suggest
90. <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
91. doing this requires managing Docker volumes outside of VS Code, and in my
92. subjective experience didn’t seem to result in much improvement in speed.</p>
93. <p>Instead, I’ve started using RAM disks, which are faster and can be managed
94. entirely within the <code>devcontainer.json</code> file:</p>
95. <pre><code>{
96.  "name": "node",
97.  "build": { "dockerfile": "Dockerfile" },
98.  "runArgs": [
99.    "--tmpfs",
100.    "${containerWorkspaceFolder}/node_modules:exec"
101.  ],
102.  "postStartCommand":
103.    "sudo chown node node_modules && npm i",
104.  …
105. }
106. </code></pre>
107. <p>The <code>runargs</code> config adds an argument to the <code>docker run</code> command. This
108. particular argument tells Docker to create a new <code>tmpfs</code> at
109. <code>/workspaces/project/node_modules</code> . The <code>exec</code> flag is needed by a handful of
110. packages that install helper scripts, otherwise Linux will ignore the executable
111. bit on those files.</p>
112. <p>The <code>postStartCommand</code> then ensures that every time the container is started we
113. give the <code>node</code> user write access to this directory. We also run <code>npm i</code> for
114. good measure.</p>
115. <p>The end result is a container where <code>node_modules</code> is stored in RAM, and Docker
116. knows that it’s not important data so doesn’t do extra work to sync it to disk.
117. As a result everything is faster.</p>
118. </content>
119.    </entry>
120. </feed>
121.  

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

1. Download the "valid Atom 1.0" banner.

2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

3. Add this HTML to your page (change the image src attribute if necessary):

   <a href="http://www.feedvalidator.org/check.cgi?url=http%3A//www.paulhammond.org/feeds/journal.rss"><img src="valid-atom.png" alt="[Valid Atom 1.0]" title="Validate my Atom 1.0 feed" /></a>

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

Home · About · News · Docs · Terms