508 karma · joined August 12, 2015
With the incident now resolved, I have the benefit of hindsight to say it was down for a total of two hours, which is well within error budget to maintain 99.5% monthly uptime, and since this isn't part of a larger pattern (so far), they're within budget for 99.95% yearly.
I think that for most companies that aren't already heavily invested in a highly available container runtime platform, the cost of this kind of downtime will be less than the cost of self-hosting something better. Especially if they're not in a situation where registry downtime implies an equal amount of customer-facing service downtime.
It is, though. Software bugs are almost entirely optional: we could just formally verify every piece of software with a mathematical proof. Computer software would still be in the 70s or 80s because of how long that takes, but if security is the only goal of a system, that's what we need to be doing.
In practice, projects balance a multitude of concerns and, while important, cybersecurity is only one of them.
> It’s also invite to solve a problem so it’s not a lot of work. It should be easy to secure your systems from making outbound connection.
This, I agree with wholeheartedly. The way to improve security is to address the factors that put humans in situations where skipping important security steps makes sense.
This has a few issues, though, such as the fact that it is impossible to allow one site but not another if they are both hosted at the same IP address. After all, DNS names are basically just aliases for IP addresses unless the application layer protocol assigns them some semantic meaning (as is the case with HTTP and TLS).
If that matters, you do have to resort to something protocol-aware like an intercepting HTTP proxy that inspects the Subject Name Indicator for TLS traffic or the Host header for plaintext HTTP traffic. Or a regular HTTP proxy, if your application supports that configuration.
Something I believe we agree on is that it is in the interest of large tech companies to spend time fixing critical security bugs in their own programs, regardless of who originally wrote the malfunctioning code and for whom said code was written.
One way to fix those bugs would be to create a patch for the external OSS library in instances where such a library is the origin of the vulnerability. This is especially practical when that library is used heavily as a basic piece of the company's common software development framework.
GP appears to be arguing that these patches should be upstreamed instead of simply being maintained internally until the bug is patched by someone else in the OSS community.
This definitely can be true, but in practice these techniques shape your understanding of people. Motivational Interviewing and NVC both draw upon an attitude of acceptance—that is, treating the person you are talking to with accurate empathy for their perspective, support for their autonomy, affirmation of their strengths and efforts, and the belief that they have intrinsic worth.
Someone who is comfortable thinking of themselves as a manipulator could pretend to believe such things for the sake of coming up with the right thing to say, and if they're a skilled liar then they would likely get away with using the technique manipulatively at least some of the time, but if you interpret your interactions as if you are accepting of the people in your life then it is far more natural to genuinely think of them with an attitude of acceptance, which is fundamentally at odds with manipulative behavior.
That is, I would argue, the primary benefit of learning these conversational styles for a layperson: the language you use shapes the way that you think, and intentional non-violent communication begets non-violent thought until non-violent communication becomes natural.
Human factors isn't a binary question of whether or not we influence the choices made by individuals. In the real world, individual choices are always influenced by a variety of factors. The question is that, when we are aware that a particular design decision will influence the choices of individuals, is it ethical to make that decision in whatever way maximizes the profitability of the product, without regard for any predictable impact it will have? Simply maintaining willful ignorance of human factors in engineering does not make the world functionally better or worse than if that same decision had been made from a position of understanding of those factors and an attitude of malice/benevolence/apathy.
I don't think it's contradictory to tell consumers to make their own choices while at the same time telling producers not to design products that needlessly influence consumers to make destructive choices.
I completely agree that things which need to be fast should be designed structurally to be fast.
But which RNG function you use in a given function is about as far you can get from an architectural decision. You shouldn't need to refactor large swathes of your codebase to accommodate a substitution of one random number generator for a faster one.
Very few people set out to roll their own crypto. The issue in my experience is less about someone writing their own hand-optimized password hash function and more about people having overly-narrow views of what counts as security critical code.
In the practical sense what matters is whether you can safely assume the hash for a particular user in a particular system will ever be unique.
E.g., if I had a snapshot of a database mapping identities to password hashes and a log of all the hashes that had been computed by the auth server, I could make very reasonable guesses about who logged in at what time.
With that said, I am not a lawyer and I have no idea what the legal significance of all that might be.
I'd suspect it's less a matter of preventing them from developing the capability and more a matter of making them spend their own money to do so, rather than getting it for free and using those resources to develop some other capability.
It kind of does matter, though, because at least for me, I am much more familiar with my home systems than what I use at work.
I started out using Redhat at work, so I migrated my home lab to CentOS to gain more familiarity, which meant that when new projects started, I advocated for Red Hat. But if I'm forced to migrate to a different production grade distro at home and develop expertise with it, the next time there's a question about what OS to use for a new project, I can imagine myself pushing for the one I will have spent the last few years tinkering with at home by that point instead.
That wasn't how I read it. I may be incorrect, but my interpretation was that the 250ms didn't make the software too slow to be effective but rather too slow to be user friendly.
The idea isn't that it directly killed people by being slow, but rather that it was not adopted because people didn't like using it, and on the paper alternative, mistakes were made that would have been impossible to make on the computer.
RHEL 8 uses the nftables back end for firewalld by default.
The main difference that I have noticed is that writing configuration files for nftables is considerably more ergonomic than the iptables files which are essentially just unstructured lists of iptables commands.
Generally things like UFW or firewalld are sufficient for host firewalls, but they fall short for routing applications where it is more appropriate to use nftables (or historically, iptables) directly.
Kubernetes and docker both currently use iptables for their routing and will likely migrate to nftables. If/then those projects migrate to nftables I suspect it would also solve the issue where docker port mappings have the ability to unilaterally punch holes in host firewalls, e.g., UFW, because under nftables, tables are just namespaces for chains (with configurable priority) while on iptables the different tables meant specific things and docker made decisions in a branch off of the PREROUTING chain in the nat table, which was encountered before the FORWARD or INPUT chains on the filter table. In this way nftables makes certain expressions more ergonomic than iptables.
SELinux itself is not aware of pid/user/group.
Any application that doesn't have a specific policy written for it will either inherit the domain that spawned it (in this case, `unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023`) or receive some default domain (e.g., `system_u:system_r:unconfined_service_t` for systemd services, `initrc_t` for init daemons, etc.)
Because of this, most applications will end up inheriting the user's domain, which again is `unconfined_t` by default under the targeted policy.
Lots of common applications have policies so that they transition to their own domain and then execute under customized policy, but it's less common for user applications (and especially user applications that are not system tools) than for daemons so it's not generally safe to assume you're protected by selinux when going about typical user tasks.
However, writing SELinux policy isn't that hard (although it's a bit harder than just `audit2allow` to do it well) and it's a perfectly reasonable project for an afternoon to write a policy for an unconfined application you use, if you're willing to spend some time up front learning about SELinux policy language.
To understand it, though, you need to understand at least a little bit about type enforcement, which is a somewhat steep learning curve to get over.
If you have nftables (replaces iptables, default back-end to firewalld in RHEL 8), you might consult /usr/share/doc/nftables/examples/secmark.nft but again, this requires some background on nftables (or iptables—they're both just front-ends to the kernel netfilter module) and are pretty similar.
However it's also worth noting that most one could also stand to learn a thing or two about netfilter if this is a topic they're interested in. For example, netfilter allows you to filter packets based on the user, group, or pid of the process.
I found this page [2] quite helpful, and especially the packet flow diagram contained within it.
[1]: https://www.linux.com/training-tutorials/using-selinux-and-i...
[2]: https://www.booleanworld.com/depth-guide-iptables-linux-fire...
Last time I played with a Mac they also had the BSD `ipfw` command for kernel packet filtering [1]. Could try something there if it still exists.
Firewalld is implemented differently and will exhibit the expected blocking behavior: traffic targeting docker ports will encounter firewalld before it encounters docker.
Adding a dedicated bastion would double my monthly costs, but SELinux costs me nothing if the targeted policy covers my applications, or like half an hour of my time per service if I have to write my own policy modules.
Although, I should point out I'm playing devil's advocate here because my ssh is still on port 22.
This attack is mitigated quite strongly if you have selinux enforcing and aren't running networked services in unconfined domains.
Even if you have networked services that aren't confined in the default targeted policy, you can probably learn to write policy for them in a day or two, although poor documentation can make for a steep learning curve.