HN user

neoCrimeLabs

619 karma

Security engineer; Boldly striving toward mediocrity, and beyond.

Posts5
Comments175
View on HN

You reminded me of this story. Windows, not *nix, though.

Years ago my cube-mate was called to support a desktop user who has having problems with their machine that couldn't be fixed remotely. He realized the user's HDD was full, so the first thing he did was clear the user's trash bin. Mysteriously the machine came up with a ton of free space.

The user seemed happy their machine was up. Nor long after, the help-desk called my cube-mate asking what they did to the user's machine; The user couldn't find any of their files that they had organized in the trash bin.

Agreed with your sentiment, and that was a great example.

Just like any security control, if it's your only means of security, it will not offer much risk reduction. Just like all security controls, the if you want risk reduction use more security controls together. Like all security controls, there is no way to eliminate risk, just reduce it as much as possible while still being able to effectively achieve your mission.

Because of this I believe security through obscurity to be important component in a healthy and mature risk posture.

It irks me when it's dismissed because obscurity is not security. No single security control is security on its own.

Great?

I remember that time I reported someone for reposting my images.

Flickr's response was deleting my profile, all of my photos, and not responding to any of my attempts to contact them.

On the upside, it was a good lesson to not trust service providers.

I expected years ago that the government, at some point, would realize if they are interested in the data that they could purchase, other nation states would be as well and could use it against us. Therefore the logical conclusion would be to declare collection and sale of such data to be a matter of national security and strongly restrict it as such.

The detail I failed to understand at the time was just how much money there is in data collection and brokerage.

The datacenter I built in 2007 was DC.

Many datacenters I'd been to at that point were already DC.

Didn't think this was that new of a trend in 2026, but also acknowledge I did not visit more than a handful of datacenters since 2007.

It just seemed like a undenyably logical thing to do.

One of the worst volume controls I have run across is when the UI tries to simulate a physical knob. More often than not I see this on VST Plugins and I have yet to find one that I actually like - they are all equally terrible.

They appear to fall into 3 buckets:

1) Worst: Direction of the cursor has move in a circular pattern as if dragging a physical knob with a cursor.

2) Annoying, but least common: You have to move the cursor horizontally to move the knob

3) Most common, but still annoying: You have to move the cursor vertically to move the knob.

NeXTSTEP was everything from the OS to the user experience and everything inbetween.

I'd say there were 3 distinct abstractions within NextSTEP: - The microkernel / OS (Mach / BSD) (for the hardware) - The Objective C based SDK - The User experience (not just window manager, but largely the window manager)

The SDK is what is still arguably the most highly regarded part of NeXTSTEP even today. That aside, at the time nothing else was so well polished and integrated on almost every level.

Update: Had less time to post than I realized, hence the terse reply.

Meant to say those solutions are in addition to Lets Encrypt. An X509 certificate is an X509 certificate, regardless if its for https, imaps, or smtps. If you're distributing your stuff across multiple hosts or containers, then it makes sense to use some sort of automation, configuration management, or certificate management/distribution system.

They never stopped supporting it, to my knowledge. I first started using their certs for my IMAP and SMTP servers 10ish years ago, at least.

If you use HTTP-01 challenge method you require an HTTP server on the host.

If you don't want an HTTP server on your imap/smtp server you need to use the DNS-01 challenge method.

This makes me wish I took photos of Diversi-Dial (aka D-Dial) setups, which somehow impressed me more due to how much they accomplished with much much less hardware.

They were able to set up a 7 x 300baud modems in real-time chat system on an Apple ][ . The original marketing called it a CB (Citizens Band) Simulator. They were able to run up to 1200baud, but I never saw one of those functioning.

As if 7 people chatting through a single 6502 wasn't impressive enough, many of them dedicated one or two of their lines to interlinking with other D-dials.

Talk about an esoteric memory.

- https://www.ddial.com/ - https://en.wikipedia.org/wiki/Diversi-Dial

There are a lot of great comments here and I want to echo so many of them and not duplicate them.

There is one thing I'd like to add:

Learning to be happy while alone takes practice - lots of it. It's not easy, but it does get easier.

Learning to enjoy being along was one of the most important moments in my life, and it changed a lot of how I see the world now. I feel like this is up there with learning self-care that works for you - equally important and yet different.

Agreed.

That said for some I can foresee Meta being hard or harder to disconnect from because of their percieved level of personal social needs.

I left facebook and many of my friendships faded away.

Awkward bumping into people conversations would happen such as: "We missed you at my birthday party!", "I didn't know about it, else I would have been there!" "We posted it to facebook..." "I deleted my facebook account 2 years ago."

My personal philosophy was maybe they were not real friends to begin with. After all in the now 5 years since deletion, not one has reached out to ask if I'm even still alive. I've reached out to a couple people, with little to no reply. None the less, it was a hard transition.

For others', that might be an impossible task.

To over-simplify, it's about conflicting philosophical alignment:

- systemd: integration and features at the cost of complexity and scope

- traditional: simplicity and composability at the cost of boot speed and convenience

systemd conflicts against the more traditional unix philosophies as well as minimalism.

You start with the assumption of "properly set up container". Also I believe you are oversimplifying the attack surface.

A container escape can be caused by combinations of breakdowns in several layers:

- Kernel implementation - aka, a bug. It's rare, but it happens

- Kernel compile time options selected - This has become more rare, but it can happen

- Host OS misconfiguration - Can be a contributing factor to enabling escapes

- Container runtime vulnerability - A vulnerability in the runtime itself

- Container runtime misconfiguration - Was the runtime configured properly?

- Individual container runtime misconfiguration - Was the individual container configured to run securely?

- Individual Container build - what's in the container, and can be leveraged to attack the host

- Running container attack surface - What's the running container's attack surface

The last two are included to be complete, but in the case of the original article running untrusted python code makes them irrelevant in this circumstance.

My point you must consider the system as a whole to consider its overall attack surface and risk of compromise. There is a lot more that can go wrong to enable a container escape than you implied.

There are some people who are knowledgeable enough to ensure their containers are hardened at every level of the attack surface. Even then, how many are diligent enough to ensure that attention to detail every time? how many automate their configurations?

Most default configurations are not hardened as a compromise to enable usability. Most people who build containers do not consider hardening every possible attack surface. Many don't even know the basics. Most companies don't do a good job hardening their shared container environments - often as a compromise to be "faster".

So yeah, a properly set up container is hard to escape.

Not all containers are set up properly - I'd argue most are not.

This is not a weakness in the design of containers.

Partially correct.

Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented. This creates gaps that allow escapes from the container. There is a much larger potential for mistakes, creating a much larger attack surface. This is in addition to kernel vulnerabilities.

While you can implement effective hardening across all the layers, the potential for misconfiguration is still there, therefore there is still a large attack surface.

While a virtual host can be escaped from, the attack surface is much smaller, leaving less room for potential escapes.

This is why containers are considered riskier for a sandbox than a virtual host. Which one you use, and why, really should depend on your use case and threat model.

Sad to say it, a disappointing amount of people don't put much hardening into their container environments, including production k8s clusters. So it's much easier to say that a virtual host is better for sandboxing than containers, because many people are less likely to get it wrong.