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.
If the goal is doing this in a simple fashion, then use Tailscale funnels (https://tailscale.com/docs/features/tailscale-funnel). Funnels automate the process and act as a reverse proxy into specific servers within your tailnet.
The downside is there is no authentication to funnels, so whatever you’re running (Jellyfin in this case so that’s not an issue) needs it’s own authentication setup. You might consider running fail2ban on that machine and have it watch for login attempts, but otherwise that is the simplest setup I think you could do.
I had pfSense running on an old Core 2 Duo machine from around 2010 when I worked in MSP. You can run it on just about anything.
The only trouble I had was when I switched to gigabit+ service and had snort running. Snort is single-threaded and that CPU just could not keep up. Suricata would be a better choice given it’s natively multi-threaded, but the real limitation there was my setup and not pfSense.
Bob Saget would roll in his grave if he heard about your addiction.
Having the game on the horizon is actually a very good position for the employees for two reasons:
Pre-orders. Rockstar already secured $3 billion, so they don’t have the argument that compensation is unfair (why they were wanting to unionize to begin with along with work hours).
(The big one) Pre-Launch Strike. There still is a LOT of damage that could be done to GTA6 especially given the pre-orders. If they strike before November, GTA6 would go without day 1 patches. Whatever state it is in prior to strike is how it will stay during the highest review and revenue period for the game. It would mess with marketing and potentially even push off release by months which would hit their stock price hard.
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.