kafrofrite

17 days agodiscuss

IIRC, around 2016 or so, Slack invited us in their office to pitch us the enterprise version and ask whether we would be interested in becoming one of their first enterprise customers. Among other requests, one colleague asked me to ask them to not kill their IRC gateway. One of their PMs looked at me and told me “No, we are not doing this”.

kafrofrite

2 months agodiscuss

I guess there's merit for that, especially if you are in a cloud environment. In a previous company, I decided to set up dnf/kpatch for VMs that we considered critical. At the time I had a healthy disregard for reliability, mostly because we had enough trust in our terraform process so I decided to automate the whole thing through AWS System Manager across the fleet and guard the feature to work only for security patches targeting the kernel. Briefly, every VM that came up would have the necessary packages installed and from there live patching would execute periodically (I believe once a week) or manually. At some point after a quarter or something we had to devise a way to tag VMs to be excluded from this but this was relatively easy to do and most of the exclusions were testing infra anyway.

kafrofrite

2 months agodiscuss

Please do share

kafrofrite

10 months agodiscuss

It's probably not trivial to implement and there's already a bunch of problems that need solving (e.g., trusting keys etc.) but... I think that if we had some sort of lightweight code provenance (on top of my head commits are signed from known/trusted keys, releases are signed by known keys, installing signed packages requires verification), we could probably make it somewhat harder to introduce malicious changes.

Edit: It looks like there's already something similar using sigstore in npm https://docs.npmjs.com/generating-provenance-statements#abou.... My understanding is that its use is not widespread though and it's mostly used to verify the publisher.

kafrofrite

3 years agodiscuss

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

is not a good enough argument.

For the story, SIP is Apple's "rootless". Effectively the OS runs with less privileges than root. Disabling SIP significantly increases the attack surface.

That being said, I'm grateful that someone decided to do something more native for containers in macOS.

comments