Poorly designed, high functioning automations.
Not a big fan of this. This sounds like they want to integrate themselves deeper into the modding setup with the likely end-goal of being a requirement to that setup. The problem there is they have a history of de-platforming mods (regardless how you feel about those mods personally) and declaring themselves the owner of mods (by refusing the removal of mods they wanted in Collections).
Allowing them more control over what mods users can access seems like a step backwards.
This is akin to the “boycotts” people have done against gas stations for high fuel costs. It doesn’t work. It’s always like “on a Tuesday, don’t buy gas”… but you weren’t going to until Friday anyway. And then you buy it on Friday, the books balance exactly the same, and there is zero actual impact.
You want to impact Sony? Stop buying games on PS5. Not for a week. For this entire console generation.
The way I view Steam Machines is just as a delivery system for SteamOS. I don’t know if Valve even thinks Steam Machines will themselves be successful. I’m thinking they are betting on enough users adopting Steam Machines that they will get a foothold with their OS and start pushing Microsoft out.
And that kinda makes sense as Microsoft is going the “AI first” route and focusing on productivity. That leaves an opening (if albeit a small one currently) for companies like Valve to pull users into their “Gamers first” SteamOS.
It would depend on having access to misconfigured permissions or docker.sock like when you chain containers to manage other containers. Because you have access to docker.sock and that socket can send API calls to the docker daemon (which is run from root) those commands would inherit the same level of access. An attacker could make the API call to mount /:/root and then access the host filesystem.
It’s just an example of how even though the container might not have anything worthwhile, it can be used to laterally move and open another door.
My biggest concern is pivoting. Specific to Jellyfin, many users are using docker, but do not isolate the user so the daemon is operating as root. With that setup, an attacker could mount the host filesystem to the container and would own the host from that container.
Again, for the linux mention, the answer is pivoting. Many machines use Tailscale. If one of those machines were to be compromised using Tailscale’s default ACL, they would be able to move laterally through the network without issue. At that point, it would be possible to modify existing nodes (ex. subnet routers, exit nodes, etc) or even add additional rogue nodes.
The question of why people care is tricky. Why should you care if your networked printer is using out of date firmware? It likely isn’t storing personal information, right? It’s a prime target because it’s easy, poorly monitored, and opens another door. A lot of infosec is just keeping doors shut so other doors don’t get opened.
Bob Saget would roll in his grave if he heard about your addiction.
That’s not quite the same thing.
Yes, someone can fork your project, but you maintain control over your own repository. Nobody gets to say “I need this, so you can’t remove it or previous commits related to it from your repo”. You can totally filter and scrub your own repos.