3 ms·

so this is essentially a syscall permissions system, right? i don't understand the point of having the application itself define its own permissions, as opposed

so this is essentially a syscall permissions system, right? i don't understand the point of having the application itself define its own permissions, as opposed to the user imposing permission restrictions upon an application. could somebody enlighten me?

clarry 7y ago
The application knows what permissions it needs, and it can drop permissions once it has done early initialization that requires more permissions than normal operation. You, as a user, have a much harder time knowing. The point of this mechanism is to ensure that the application does only what the application's author intended it to do (so exploiting a bug does not lead to it doing things it was never intended to do). It's not a mechanism for users to sandbox malicious applications.
- CobrastanJorji 7y ago
  Exactly. It's the same reason using Linux as the root user is a bad idea. Yes, you have full permission to do whatever you want to your own system, but you want to be very explicit when you do so to avoid doing really bad stuff by mistake or trickery.
- jerf 7y ago
  In particular, this stems from the observation that many, many programs have an initialization phase where they may read config, open logs, hit the network for config and peers, etc., and do all sorts of things that they do not do during their steady state operation. However, when programs are "hacked", particularly remotely over the network, they are in their steady-state phase. So while there is in some sense not much theoretical gain to pledge(), in practice it is applicable to a wide variety of software where the program itself can say "Alright, I'm out of my init phase, now crank the screws down on me and make sure I don't do these other things because it's guaranteed they're bad."
  - woodrowbarlow 7y ago
    aha, this makes sense. thank you!
JdeBP 7y ago
See https://news.ycombinator.com/item?id=17277067 https://news.ycombinator.com/item?id=17277067 .
rst 7y ago
The most obvious rationale for this sort of thing is limiting what an attacker can do after injecting and running their own code in the process. (Straight Morris-worm style buffer overflow attacks are hard to execute these days, but there are more sophisticated variations on the theme which still often work.) There are other attacks which can also be mitigated by this sort of thing. A common attacker trick is supplying paths with a lot of '../../../..' embedded, to trick the program into accessing (and potentially leaking the contents of) parts of the filesystem that a remote attacker isn't supposed to have access to. (Citrix web appliances were recently subject to a particularly nasty version of this attack, cataloged as CVE-2019-19781, leading to full compromise.) Using 'unveil()' to limit the scope of filesystem access is a viable mitigation strategy...

clarry 7y ago

The application knows what permissions it needs, and it can drop permissions once it has done early initialization that requires more permissions than normal operation. You, as a user, have a much harder time knowing. The point of this mechanism is to ensure that the application does only what the application's author intended it to do (so exploiting a bug does not lead to it doing things it was never intended to do). It's not a mechanism for users to sandbox malicious applications.

CobrastanJorji 7y ago
Exactly. It's the same reason using Linux as the root user is a bad idea. Yes, you have full permission to do whatever you want to your own system, but you want to be very explicit when you do so to avoid doing really bad stuff by mistake or trickery.
jerf 7y ago
In particular, this stems from the observation that many, many programs have an initialization phase where they may read config, open logs, hit the network for config and peers, etc., and do all sorts of things that they do not do during their steady state operation. However, when programs are "hacked", particularly remotely over the network, they are in their steady-state phase. So while there is in some sense not much theoretical gain to pledge(), in practice it is applicable to a wide variety of software where the program itself can say "Alright, I'm out of my init phase, now crank the screws down on me and make sure I don't do these other things because it's guaranteed they're bad."
- woodrowbarlow 7y ago
  aha, this makes sense. thank you!

JdeBP 7y ago

See https://news.ycombinator.com/item?id=17277067 https://news.ycombinator.com/item?id=17277067 .

rst 7y ago

The most obvious rationale for this sort of thing is limiting what an attacker can do after injecting and running their own code in the process. (Straight Morris-worm style buffer overflow attacks are hard to execute these days, but there are more sophisticated variations on the theme which still often work.) There are other attacks which can also be mitigated by this sort of thing. A common attacker trick is supplying paths with a lot of '../../../..' embedded, to trick the program into accessing (and potentially leaking the contents of) parts of the filesystem that a remote attacker isn't supposed to have access to. (Citrix web appliances were recently subject to a particularly nasty version of this attack, cataloged as CVE-2019-19781, leading to full compromise.) Using 'unveil()' to limit the scope of filesystem access is a viable mitigation strategy...