^f lightning ;)

Honestly, feels more like a bit. I sometimes say I need to cross my i's and dot my t's to suss out who's still paying attention in a meeting...

As someone who doesn't use shared vaults - would the warning popup, 'to enable the "Installed community plugins" synchronization feature', not be on a per shared vault basis? Is trusting a single shared vault for plugin sync going to mean I sync my plugins for every shared vault?

IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.

Inconceivable!

> unless you are somehow exposing yourself stupidly

Or, y'know, offer some forms of compute as a service.

The attack itself creates the logs, which - reading between the lines - are shipped to a central log server. A compromised server might not send any new indicators to the logs, but existing logs moved off device would still be available.

I'd like to know what those distinctive traces are, which is also missing :(

Have you considered shredding the journal pages after?

I had a boss who took his notes on loose-leaf notebook paper and would weed the notebook frequently. He had been involved in litigation in the past.

I know it's a bit of a joke, but "I Built a Neural Network from Scratch in SCRATCH" gave me, a complete outsider, a lot of insight into how neural networks work.

https://www.youtube.com/watch?v=5COUxxTRcL0

GitHub is one of the most readily accessible sources of parasitic compute resources.

"Parasitic compute" is strange way to describe "a user running dev workflows on their own GitHub Actions allocation"

when you run ghost, it creates a "ghostbox" - an ephemeral machine on your GitHub account, on your GitHub actions minutes, accessible only by your SSH identity. It's orchestration around GitHub's infra.

Proprietary software built on GitHub is not exactly an unusual category.

It's the principle of 'Defence in Depth'. Do both, as one control may fail.

But you wouldn't, or shouldn't, take a patchwork approach to it.

If the software you're trying to secure actually depends on a full, working, intertwined unix system... you leave that as it is. You can certainly try reducing a process's access to the system it's running on (whether that be by containers, jail(8), SELinux, AppArmor, etc.), but you don't go around deleting 7-zip or your scripting languages or compilers, on the off-chance that'll thwart a hacker.

Sure, you can say, "defense in depth", but if you have one layer that's actually holding up the security guarantees, and a second layer that is largely ineffectual (haha! I removed /bin/cat, now they can't read files! oh and base64 too... and yyencode... and... and... and...), I wouldn't waste much time on the second layer.

I think you have the wrong end of the stick. The OP link is a resource for when you do get access to the processes environment which has already been reduced via containers, jails, or what have you.

If the environment is already restricted, but the process has, for example, access to the base64 tool, here's how you can use that to do something you otherwise aren't able to.

I can't read the original article because Github is having a very bad day, but I don't really understand the attack model here.

If a process has access to any tool that isn't statically linked, the process already has access to ld-linux.so and can therefore execute any binary it has read access to. "restricting access" by enumerating the binary paths a program can execute is not a very useful restriction by any means.

The original article is a list of ways to achieve certain features (ie, reading a file) when you don't have it natively (ie, no cat, but for some reason, base64).

> execute any binary it has read access to

Maybe I'm missing something, but in these restricted environments, why would the system have read access to binaries it doesn't need or use?

I believe they meant to get past the 'Sign in to read for free' element.

+ cloudflare captcha, in my case