L
Lizzie Dixon
blog.lizzie.io · Personal blog · on HN since 2016
Lizzie Dixon writes on Linux security and systems, including container internals, CVE analyses, and Chrome extension attacks.
What HN saysHN commenters recommend her 'Linux containers in 500 lines of code' as a great way to understand containers, and like its org-mode literate source.
15HN people shared it
8linked it in comments
14stories submitted
980story points
2 years agolast shared
2016people per year2026
Most-shared posts
- 1Linux containers in 500 lines of code8 people · 969 points · first shared 2016 · 49 comments on HN
- 2Notes about CVE-2016-71173 people · 5 points · first shared 2016 · discussion on HN
- 3Exploiting CVE-2016-862 people · 3 points · first shared 2016 · discussion on HN
- 4Clickjacking Chrome Extensions2 people · 2 points · first shared 2018 · discussion on HN
- 5Linux containers in 500 loc.org2 people · first shared 2017
- 6Preventing USB Attacks with Grsecurity1 people · 1 points · first shared 2016 · discussion on HN
- 7Contained.c1 people · first shared 2017
- 8Homepage1 people · first shared 2022
What HN people wrote when they linked it
matthberg · 2022-03-10
Might benefit from a (2016) tag. Date gotten from the homepage: https://blog.lizzie.io/
tyingq · 2017-06-05
A great resource to understand how Linux containers work is "Linux containers in 500 lines of code": https://blog.lizzie.io/linux-containers-in-500-loc.html
Or, if you just want to skip to the code: https://blog.lizzie.io/linux-containers-in-500-loc/contained.c
hippospark · 2023-08-07
There is a similar project _Linux containers in 500 lines of code_ [1], the code is a bit old, but the procedure is quite simple.
[1]: https://blog.lizzie.io/linux-containers-in-500-loc.html
zeveb · 2017-11-02
Kinda cool how it's all generated from an org-mode file: https://blog.lizzie.io/linux-containers-in-500-loc.org
Really nice example of the power of literate programming in general and of org-mode's support for it in particular.
mcny · 2017-11-02
Somewhat tangentially related, I would like to know how the parent poster or for that matter printed the document.
somewhat unrelated, I don't use emacs but is there a way to break lines such as
#+caption: [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/k…
in the org mode source? https://blog.lizzie.io/linux-containers-in-500-loc.org
startling · 2016-10-06
I couldn't find anything, so I wrote some https://blog.lizzie.io/notes-about-cve-2016-7117.html
Jach · 2024-10-26
It is the better road, and the road chosen by most other things that aren't SaaS, including Google's other most popular thing, Android. Keep the default to auto-update, fine, but let me disable that, as the Android app store does. Attacks from previously trusted extensions (and apps) being updated and then doing malicious things (requesting new permissions to do them is not significant friction) are worse and more frequent than old unpatched extensions being vulnerable to something. (That "something" likely being in the realm of XSS or click-jacking from a malicious page, much harder to widely exploit.)
I'm sure it's happened, but I haven't heard of an extension suffering from a significant "unpatched vulnerability" and being exploited in the wild -- I have heard of things like this click-jacking issue in Privacy Badger: https://blog.lizzie.io/clickjacking-privacy-badger.html No wild exploits afaik, just the PoC, and the ultimate worst-case impact was just (reversibly) disabling the extension for the page or a site, which isn't very severe. Perhaps a more advanced extension like Ruffle that uses Rust and WASM has a more severe attack surface than the majority of extensions written in JavaScript, but even if it does, it must be exploited by a malicious page targeting it, vs. the alternative of auto-updating to a malicious version and doing whatever it can get away with immediately.
Extensions getting taken over or just transferred to new owners and updating to do something…