People complain when applications on Mac request permission to access files, but that makes such a huge difference. It’s time for kernel level permissions to be standard on desktops.
And then the games industry starts deploying vulnerability-as-a-service kernel modules in order to bypass all of those controls.
https://mobile.twitter.com/TheWack0lian/status/7793978407622...
On the other hand: how can you spot a cheater who obviously has the cheat at kernel level - with a anticheat software running above that?
- make it easy to report suspected cheaters
- include footage from the cheater, not prerendered but as client state
- create a way for experienced players to judge, from multiple angles, with proper randomization and incentives
- require an id for creating an account. Ban persons not accounts
Don't you need that deeper system integration to achieve that in a way it can't be negated by the cheat?
I think it is ok to be judicious with timeouts, kicks and even bans, so long as you provide a reasonable, accessible and well-scaled dispute mechanism.
That requires a deterministic simulation, and also trusting the clients inputs. Cheats that just send damage/kill messages are stopped by a server just checking "is it possible for X to do Y". Stuff like this is often explainable by unfortunate lag spikes on the "cheaters" side (and most instances of someone rotating 90 degrees and headshotting you in one shot are really just bad networking combined with an edge case in prediction code).
Meanwhile modern cheats are emulating input devices and living as kernel extensions. A game that looks at client inputs is doomed to fail.
> well-scaled dispute mechanism.
The primary issue with dispute mechanisms is social engineering. If you have a cheat forum of 300 people banned, and one figures out what to say to be unbanned, they share the results with others and everyone gets unbanned. A stream of 300 tickets in a game like Fortnite, particularly if they're done in multiple languages and spread across a few days would be unnoticed.
It's a tough problem. I'm not claiming kernel level anticheat is a _good_ thing but it seems to be better than any of the other options available right now.
If you accept the admin prompt in windows that code can just run anything. In macOS the first time it'll run the code but prompt again if it starts trying to access the core file system.
You may, as a developer, have an expectation some simple app you've downloaded should be able to run in a sandbox quite simply. A random app seemingly unnecessarily trying to access your user/systems files is worth a second thought.
It used to be a little buggy, but I now have it enabled all the time and don't necessarily feel any performance issue - on a powerful laptop with reasonable usage.
If anyone has more technical information about the feature I'd be very interested to see more about it and what it exactly does - is it really effective or just a lure?
Well, for one thing, to maintain the integrity of online games, protect personal data from the game itself and help prevent theft of in game assets... so I think there’s no strong win here.
Yes it would be good if CS:GO exploits couldn’t reach out and hit your Bitcoin wallet or what have you, but you can’t really just give up entirely either. There’s by-design going to be things the game can access or at least indirectly access that can be sensitive. (At least in the context of online games like CS:GO.)
> People complain when applications on Mac request permission to access files, but that makes such a huge difference. It’s time for kernel level permissions to be standard on desktops.
I agree that improving security is good. However, the way macOS has implemented security has a heavy focus on not trusting the apps themselves and in some cases not even the user. While it is a reasonable principle on some levels, I suspect this mentality actually has more to do with greater control over the ecosystem and the security benefits are a nice bonus. Apple isn’t really alone in this either.
For this particular issue, the issue isn’t with trusting CS:GO itself, it’s with isolating the game so that it doesn’t have more privileges than necessary. That’s actually less difficult of a problem to improve on with less annoying implications. A Linux solution might be shipping an SE Linux profile or Firejail configuration with your app to help lock it down. In this case you still trust the app, and good developers can improve their security easily. No annoying prompts, albeit it would not protect against malicious developers at all.
I still have a lot of mixed feelings because I think concepts like secure boot and principle of least privilege are good ideas. However, they have been met with scorn in their introduction to desktop because traditionally, on desktop platforms, you want to trust the software vendor anyways. The trust boundaries are changing and consolidating trust mostly with the OS vendor and device vendor. I realize this long-held tradition of trusting desktop applications has been crumbling under pressure and less people trust software they depend on than ever. But, I still think that macOS is basically neglecting the demographic that absolutely wants granular and intensive security, but wants more control over how it is enforced and against what. In general, that demographic is being forced into the same pigeonhole as everyone else whether they like it or not, much to the detriment of their ability to hack, repair and otherwise use the device, maybe in ways the vendor objects to. Apple famously believes in a world free of porn. Why should the company that makes my phone be hindering the types of content I can consume on it so stringently?
I am also feeling stronger lately that we’re headed towards less and less sustainable conundrums as the grip tightens. One key insight is that back in the day, you generally trusted software vendors because they mostly had incentive to not betray that trust, and you used websites because you wanted to and not because you felt you had no other options. Even if we make security a priority and drop as many privileges as possible, will that solve the problem? We hate the software we use. Everyone wonders why the web is so slow and disliked; it’s because every time you scroll Twitter spends 100ms blocking the main thread on a modern multicore processor doing god knows what while the browser desperately tries to hide this fact. Even when you don’t scroll enough to cause any virtualized viewport changes. Is it ads, telemetry? Who knows. It’s a mess. Nearly every webapp and probably many mobile apps do things we hate. And they all seem to pull this elaborate bait and switch on users where it’s nice and user friendly and developer friendly until they no longer need your help to thrive.
Users should have ways to run apps they don’t trust that will help protect their security and personal information. Security by default is also a laudable goal, too. But if the future is going to be OSes trying to protect us against apps we hate that hate us that we feel compelled to use due to social pressure, legal requirements or business needs, I think we’re really just headed to a generally dark place.
I’m not saying I don’t understand the legitimate motivations here. It just also is convenient that part of this model of security necessarily takes control away from the user, and it seems like the endgame is that we hate everything and everything hates us. It is possible we’ve run into a situation where a technical solution is simply not enough to untangle the mess. I have no idea what is.
For a long time I was on the side of sympathizing with OS vendors. They were just doing what the security paranoids wanted, right? Well, kind of. But the implications of what it really means for computing feel bleaker every time the subject comes up.
And yet are we safe? The threats just keep adapting. I’m sure at one point many thought “as soon as those pesky buffer overflows are gone, computers will be safe.” It’s good that the security baseline on a technical level keeps improving, but I really think we need to find a way to have healthier relationships between end users, device vendors, and software vendors...
It's not like I can make you read my entire post, but I find it irritating that you went our of your way to let me know that you didn't actually read my post, but still felt compelled to respond anyways.
> but I think ancestor was talking about games being permitted to execute arbitrary code, as opposed to privileged users being able to inject code into a game process…
I never said anything about privileged users being able to inject code into a game process.
I am retorting that the idea that RCE exploits would be OK if we just sandboxed everything is not true. It would improve things, but online games like CS:GO necessarily have access to some things that would be considered sensitive, and thus we still have to care about RCEs.
I went on further to suggest that Apple-style ecosystem control is unnecessary to solve this particular problem. App vendors themselves could opt into various sandboxing measures to limit their own privileges to improve their own security posture. Apple's control protects against untrustworthy applications, and in this case, CS:GO is not an untrusted application.
And then, finally, in around 600 words, I began talking about how I have grown to dislike the walled garden approach because we're building a world where we all hate and distrust all of our software vendors and they hate and distrust their users. Building an ecosystem that is "secure," but that nobody actually likes or wants to partake in.
I appreciated your comment. Maybe saying RCE is “ok” was a bit of a hyperbole, it depends on the game. MMOs people could steal credentials, etc.
SELinux, App Armor, and MAC is what I mean. Windows has mandatory integrity control but it’s no where as comprehensive as Linux, MacOS, iOS.
Windows does have some opt in isolation controls as well like you suggested, but their recently released security features like App Guard is based around virtualization which think won’t work for the average program due to performance and overhead.