gtjay
Totally on me. We fight against it, but it's hard not to have the implicit context of RHEL/Fed be omnipresent on the Red Hat bugzilla. In fact, when I wrote the comment in question I had just finished lighting my incense to the sīla of `systemd`... :)
Did not realize you were in Sydney. AU truly has the best hackers.
It's very important for everyone to understand my advice is RHEL/Fedora specific, which is---I think---the source of the misunderstanding here.
Putting aside `ptrace` being the best way to guarantee a race win, the reason for my focus on `CAP_SYS_PTRACE` is that with SELinux enabled there is no other way to exploit having access to the file descriptors. Even if you explicitly try to pass a containerized process an external file descriptor "legitimately" (e.g. with `sendmsg`) SELinux will still ultimately block the access due to the type restrictions. This means that with `setenforce 1` you need to use something like code injection to get the external process to access the file descriptors on your behalf.
https://medium.com/@gtrevorjay/consider-containers-a-case-st...
Containers are not a security panacea. However, it is equally erroneous to say they don't add layers to defense-in-depth.
Often, I am reluctant to run something not because of a trust issue but a complexity issue. I run a heavily customized environment. I will often be burned by an application---for example---creating a symlink that under "normal" circumstances is perfectly copacetic but all but destroys some carefully crafted aspect of my environment. Similarly, isolation that is not up to the task of stopping evil is often more than adequate for stopping stupid (e.g., the recent "Steam deletes your home directory" issue). How often have you updated your system only to have one or two apps misbehave? With what jessfraz presents here, yum and apt become tools you can apply selectively. There are real non-security benefits to be had.
I realize that part of the oversell is the nature of hype but I can't help but feel that a---perhaps---equal part is that talking about these kinds of benefits is a more subtle and nuanced conversation.
The overgrowth factor shouldn't be ignored though. It's a particularly sad effect of MBA-culture and perverse incentives that so many perfectly viable retail outlets grow themselves to death. Krispy Kreme is the perfect example of a chain that was obviously working and did everything it could to kill itself with growth. I sympathize that everyone involved in those decisions made ones that were rational for them and their personal gains, it's just a sad outcome for the chain.
The difference seems to be two-fold. First, Jaycar didn't go through an insane expansion (there are only 12 or so locations per state). Second, they've grown "out" from their core market of electronics hobbyist instead of betraying it. Just a few examples: custom car stereos, solar panel accessories, camping/RV electronics, boating electronics, and DJ-stuff like laser projectors. This is all in addition to the arduino and 3D printing stuff that you'd expect. There's a huge amount of cross-over between these markets, which works out great for Jaycar.
There is one additional factor keeping Jaycar healthy that probably shouldn't be underplayed. Due to mining and a less crypto-facist view of unions, Australia has not (yet) completely gutted it's blue-collar market and culture. Jaycar advertises almost exclusively to this "tradie" (as the Australians call it) demographic. Jaycar is marketed as a "manly" thing, not a "nerd" or "tech" thing. In fact, it's even drummed up minor controversy from feminist as being exclusionary with ads focusing on "leaving her to go to your man-cave" and whatnot. This part of Jaycar's success probably can't be replicated stateside. The market of people who have the skills to fix a small electric outboard motor and can still afford one died with the rest of blue-collar culture and jobs.
This leads to all kinds of odd pathological situations. As far as I can tell, purely paying agents in commission is much less common here. Combined with the unmovable listing prices this has led to what is basically welfare for real estate agents and the most lackadaisical salesmen I have ever witnessed, even adjusting for the generally easy-going culture. I'm used to having to ignore calls from agents once it's known that I'm looking. Here, it's the opposite you have to keep calling them. I only have my current place because my wife explicitly asked about it, to which the agent responded something along the lines of, "Oh yeah. That's been open for months." Since many of the property owners aren't professional (pooling the risk/cost of owning over many units) and cash-strapped, getting maintenance done is a nightmare. It's either all done by themselves (with the ensuing comedy that entails) or farmed out to agencies that still bill the owner mostly piecemeal (so that every issue is a situation akin to getting your insurance to pay your doctor).
I would like to think that when the boomers prove, despite their thinking to the contrary, quite mortal and start dying collectively in large numbers that this will correct the market. My worry is that instead what boomers die last will use the last of their block voting power to convince the government to ease restrictions on foreign investment and Australia will become much like Hawaii.
Okay, now I see where you're coming from. Theoretically I agree. However, practically there are a number of things that make hardware different:
* Hardware has inherent "buy-in". The software systems you describe as also solving the memory access problem are basically opt-in frameworks. While you can make software frameworks hard to opt-out of (e.g. OS integration etc.) by definition... software runs on hardware...
* hardware solutions are often much more transparent. Again, your software example require a great deal of re-tooling. One of the most elegant aspects of the classic 80's memory access solution was how transparent it was.
* The ratio of software to hardware vendors has far fewer hardware vendors. Combine this with the fact that, as you point out, hardware is so expensive to retool and you create an environment where it is much more likely that a single hardware solution will be "correct enough" to enforce a constraint on software than it is the case that the majority of software will properly opt-in to a framework/code-correctly.
Of course! If my comment could be taken as part of the mass of prose that can be read to imply otherwise, I apologize. I don't want to undermine what Docker has done with providing a packaging format, UX, and history niceness. I also don't want to undermine the years of hard work that's gone into kernel namespacing etc. that makes it all possible.
You can't just argue away the fact that a certain class of error has been all but eliminated by hardware-supported virtual memory. Multi-tasking as we know it today would basically be impossible without it. The reliability of "just get it right" systems like the early Macintosh isn't even comparable to, for example, a modern Linux machine that uses the chip to trap large classes of erroneous memory accesses.
Given that we have the above, a case of a class of error that programmers seemed unable to eliminate (practically) eliminated, I'm not really sure what you're arguing. Are you saying that hardware designers of the 80's were superhuman?
Okay... maybe Jay Miner...
People forget that in-chip memory protection didn't come about for security reasons, memory errors were a particularly dangerous and particularly common kind of bug and the hardware was extended to help with memory isolation. OS session ending memory errors are almost unheard of since operating systems have started fully utilizing the on-chip protection. Programmers didn't become "superhuman" at preventing these errors.
For similar reasons it's much easier for hardware-backed virtualization programmers to protect you from malicious business inside a VM than it is for OS or container programmers.
Basically, docker used to have a "drop" list associated with each execdriver. By default docker kept all kernel bestowed capabilities but would explicitly drop those on the execdriver's drop list. This created issues with compatibility. If an image was prepared on a kernel that didn't have a particular capability at all and was suddenly run on one that was, weird hard to diagnose behavioral differences could emerge. So now docker drops everything by default and the execdrivers have a "keep" list. Also, there's now a check for the kernel defining a capability before trying to mess with it.
There are---of course---still some issues. For example, docker drops everything then tries to add the capability back. That won't work for some capabilities because some can't be added back once they've been renounced. Still, the situation is an interesting example of how a security bug is still a bug and is likely to bite you in some way sooner or later. See also XSS flaws that limit valid inputs.