5 ms·

I sympathise with the position Valve are in here, which appears to be a “least bad solution” kind of problem. Even so, I can’t help feeling that the mere viabi

I sympathise with the position Valve are in here, which appears to be a “least bad solution” kind of problem. Even so, I can’t help feeling that the mere viability of userland software like VAC or DRM/copy protection schemes shows that we remain in the Dark Ages in terms of computer security models. For any normal application, it should not even be possible to read system-level information like what is cached within the networking stack, or to hide funny things in your file systems or mess with your boot sector, or to monitor and/or interfere with communications between other applications and the OS. However, on a typical laptop/desktop/server OS today, we still usually determine authorisation at a resolution marginally finer than “Are you root?”. On some mobile platforms, there seems to be a move toward a more controlled and application-specific model. However, in practice, apps frequently ask for everything including the kitchen sink anyway, and the more controlled installation/update/removal processes for apps seem to be more a (possibly unintended) side effect of locking users into app store models than an active decision to firewall each application for security reasons. So, out of genuine curiosity: Is anyone actively researching better ways to model user and application permissions that might find their way into mainstream operating systems any time soon? By now, I really ought to be confident that even if I were silly enough to open a dodgy attachment in my word processor, it couldn’t then scan my e-mail, load a couple of juicy system settings files, and upload it all to a server in Western Hackville without further permission. And if I have a problem with a particular piece of software, I really should be able to summarily destroy every trace of it with a simple and reliable procedure, without having to worry that it’s left anything behind that I didn’t want. We’ve obviously got tools that do parts of this job, such as chroot jails and checkinstall in Linux world, but for the average user this whole area seems absurdly underdeveloped given how many common attack vectors would immediately be closed down entirely or at least much better contained.

mikeash 13y ago
I agree this is highly desirable. However, what if it came to pass? A game can just say, "you must run me with super permissions, or you don't get to play me." How many people are going to decide not to install the latest Battlefield or Call of Duty or whatever the kids are playing these days, just because of that? I think they'll happily click through whatever prompts are necessary, and put in whatever scary administrator passwords are required. An alternative would be to not let any third party have these capabilities at all. But unfortunately that includes you, the user, because the system can't distinguish between things that the user actually wants to do, and things the user doesn't want to do but told the system he really really wants to do because he wants to go shoot some bad guys. Neither outcome seems great, although the first is better than the second to me.
- robryk 13y ago
  Or you can do what CyanogenMod does: allow the user to pretend to give some permission to a program. This will obviously devolve into an arms race between better emulation of these permissions and better detection of the emulation (debugger detectors come to mind), but this seems to be a better outcome than you posit.
- Chris_Newton 13y ago
  I certainly agree that there is a social/education angle to this as well, and in many ways that is the hard part. Just look at the usability problems with Microsoft’s early attempts at UAC on Windows, or how many people give permissions for all kinds of things on auto-pilot when using mobile devices. Still, you can’t start to educate even sensible, cautious users about how to make informed decisions if you don’t first have a robust technical security framework so you know what decisions need to be made. Also, we could tighten restrictions on applications without requiring any extra user understanding or interaction at all in quite a few useful cases. For example, suppose we distinguished between installing general applications and system tools, with the latter meaning third party software that really does need unusual levels of access to system resources, such as security or disk management utilities. Suppose also that we restricted general applications severely in terms of low-level access to system resources. Now all a web browser or e-mail client has to do to benefit from improved security is initially install as a general application, which is presumably the default behaviour and requires no interaction with or notification of the user. Any malware that subsequently finds its way into that application and tries to access restricted system resources or APIs is assumed to be hostile and gets killed immediately, with no need for user interaction then either.
est 13y ago
> it should not even be possible to read system-level information like what is cached within the networking stack This kills lots of innovations. Like what Google did to TCP/IP stack, which is invisible to 99.999% programs.
- Chris_Newton 13y ago
  Please note the words “For any normal application” in my original post. Of course there will always be system software, some of it part of the operating system and other parts coming from other sources. I’m not challenging that, I’m challenging the idea that the default should be for installed applications to have this kind of access. It’s just the principle of least privilege.
  - est 13y ago
    They what happens next? Let the user to choose which app should have what access to which resource? It will be confusing. Your idea is there, but it's not practical. Let's just use the DNS example here. So VAC is md5 all DNS cache entries on Windows. How do cheaters get around this? Any program can use UDP socket, what prevents the cheaters directly craft DNS packets to an external DNS server? This completely avoids `DnsQuery_A` or `gethostbyname()` APi calls. So VAC need to sniff all UDP traffic to port 53?
    - Chris_Newton 13y ago
      They what happens next? Let the user to choose which app should have what access to which resource? Yes, I think a lot more flexibility in the underlying security model could be useful for people like system administrators or “power users”. For “normal” users, it would obviously be important to keep things simple enough to understand or ideally completely transparent where that’s possible. This is why I’m a fan of ideas like the separation between general applications and system tools that I mentioned in another post. The default behaviour is the safest behaviour, which is normally what you want anyway. You can add a suitable level of scary warnings, signature/integrity checking, or whatever other safeguards might be appropriate if the user really does want to install software that will have greater access. Sure, some people will go ahead and say yes, obviously im_not_a_trojan_honest.exe received by e-mail from “Here’s COD4 Free!” looks legit and they should just click through everything and start playing. There is a limited amount you can do to help such people. But a lot of people are smarter than that and will take security at least somewhat seriously if it’s not too intrusive and they understand that “If in doubt, click no” is the basic rule. And of course for the geeks, or for people at work whose security settings are actually going to be configured by professional system administrators, different rules apply anyway.

mikeash 13y ago

I agree this is highly desirable. However, what if it came to pass? A game can just say, "you must run me with super permissions, or you don't get to play me." How many people are going to decide not to install the latest Battlefield or Call of Duty or whatever the kids are playing these days, just because of that? I think they'll happily click through whatever prompts are necessary, and put in whatever scary administrator passwords are required. An alternative would be to not let any third party have these capabilities at all. But unfortunately that includes you, the user, because the system can't distinguish between things that the user actually wants to do, and things the user doesn't want to do but told the system he really really wants to do because he wants to go shoot some bad guys. Neither outcome seems great, although the first is better than the second to me.

robryk 13y ago
Or you can do what CyanogenMod does: allow the user to pretend to give some permission to a program. This will obviously devolve into an arms race between better emulation of these permissions and better detection of the emulation (debugger detectors come to mind), but this seems to be a better outcome than you posit.
Chris_Newton 13y ago
I certainly agree that there is a social/education angle to this as well, and in many ways that is the hard part. Just look at the usability problems with Microsoft’s early attempts at UAC on Windows, or how many people give permissions for all kinds of things on auto-pilot when using mobile devices. Still, you can’t start to educate even sensible, cautious users about how to make informed decisions if you don’t first have a robust technical security framework so you know what decisions need to be made. Also, we could tighten restrictions on applications without requiring any extra user understanding or interaction at all in quite a few useful cases. For example, suppose we distinguished between installing general applications and system tools, with the latter meaning third party software that really does need unusual levels of access to system resources, such as security or disk management utilities. Suppose also that we restricted general applications severely in terms of low-level access to system resources. Now all a web browser or e-mail client has to do to benefit from improved security is initially install as a general application, which is presumably the default behaviour and requires no interaction with or notification of the user. Any malware that subsequently finds its way into that application and tries to access restricted system resources or APIs is assumed to be hostile and gets killed immediately, with no need for user interaction then either.

est 13y ago

> it should not even be possible to read system-level information like what is cached within the networking stack This kills lots of innovations. Like what Google did to TCP/IP stack, which is invisible to 99.999% programs.

Chris_Newton 13y ago
Please note the words “For any normal application” in my original post. Of course there will always be system software, some of it part of the operating system and other parts coming from other sources. I’m not challenging that, I’m challenging the idea that the default should be for installed applications to have this kind of access. It’s just the principle of least privilege.
- est 13y ago
  They what happens next? Let the user to choose which app should have what access to which resource? It will be confusing. Your idea is there, but it's not practical. Let's just use the DNS example here. So VAC is md5 all DNS cache entries on Windows. How do cheaters get around this? Any program can use UDP socket, what prevents the cheaters directly craft DNS packets to an external DNS server? This completely avoids `DnsQuery_A` or `gethostbyname()` APi calls. So VAC need to sniff all UDP traffic to port 53?
  - Chris_Newton 13y ago
    They what happens next? Let the user to choose which app should have what access to which resource? Yes, I think a lot more flexibility in the underlying security model could be useful for people like system administrators or “power users”. For “normal” users, it would obviously be important to keep things simple enough to understand or ideally completely transparent where that’s possible. This is why I’m a fan of ideas like the separation between general applications and system tools that I mentioned in another post. The default behaviour is the safest behaviour, which is normally what you want anyway. You can add a suitable level of scary warnings, signature/integrity checking, or whatever other safeguards might be appropriate if the user really does want to install software that will have greater access. Sure, some people will go ahead and say yes, obviously im_not_a_trojan_honest.exe received by e-mail from “Here’s COD4 Free!” looks legit and they should just click through everything and start playing. There is a limited amount you can do to help such people. But a lot of people are smarter than that and will take security at least somewhat seriously if it’s not too intrusive and they understand that “If in doubt, click no” is the basic rule. And of course for the geeks, or for people at work whose security settings are actually going to be configured by professional system administrators, different rules apply anyway.