3 ms·

Unfortunate, but I guess it's a bit like how safety regulations make building slower but we accept it for the far, far fewer workers dying or being maimed in ac

Unfortunate, but I guess it's a bit like how safety regulations make building slower but we accept it for the far, far fewer workers dying or being maimed in accidents... Is this Inception issue the kind of thing that can be solved more efficiently in silicon with future generations, or is the mitigation something we have to accept and just go for faster processors to make up for it in the future?

ars 3y ago
I'm not familiar with this specific mitigation, but aren't they often only need in multi user environments? Meaning if you have a dedicated machine for your database, you probably don't want to turn these on. i.e. it's good to know that this is something you probably don't want.
- deleted 3y ago
  [deleted]
- hulitu 3y ago
  Your web browser is a multiuser environment with no access control.
  - oliwarner 3y ago
    Yes, but the scenario was >> if you have a dedicated machine for your database That's not a machine with a browser. The game then becomes: can somebody "inject" this sort of attack through a database connection. Good practice should insulate you but who knows.
- danpalmer 3y ago
  Even in that scenario it’s normal to run the database as a non-root user. This is important so that if there’s a database escape vulnerability, some sort of RCE, then the attacker doesn’t have full control over the machine and would still need another privilege escalation path to do the most damage. You could skip this and run the DB as root, but that’s a big security trade off that most users shouldn’t be taking.
  - viraptor 3y ago
    That's not really a practical issue in most cases. In almost every situation if you attack the database host, there's nothing apart from the database running there. Once you control the database you have full data access already. You'll potentially need to escalate to enable outbound network access if it's restricted on the host rather than network layer, but even that's not common. For large databases you're more likely to get more access by changing trusted serialised data, or inject some commands where possible.
    - danpalmer 3y ago
      Having access to a restricted database user may well not grant access to all data, but being able to escape to the root system user could mean free access to the data reading it directly off disk. Root access also provides many more opportunities for persistence. Most attackers don't want to be discovered, they want to remain and continue to exfiltrate. Exfiltration out-of-band will also be easier as root as you would be able to modify the firewall. Root may be a little less useful on a cloud VM where there is cloud level network isolation etc, but it's still a Bad Idea.

ars 3y ago

I'm not familiar with this specific mitigation, but aren't they often only need in multi user environments? Meaning if you have a dedicated machine for your database, you probably don't want to turn these on. i.e. it's good to know that this is something you probably don't want.

deleted 3y ago
[deleted]
hulitu 3y ago
Your web browser is a multiuser environment with no access control.
- oliwarner 3y ago
  Yes, but the scenario was >> if you have a dedicated machine for your database That's not a machine with a browser. The game then becomes: can somebody "inject" this sort of attack through a database connection. Good practice should insulate you but who knows.
danpalmer 3y ago
Even in that scenario it’s normal to run the database as a non-root user. This is important so that if there’s a database escape vulnerability, some sort of RCE, then the attacker doesn’t have full control over the machine and would still need another privilege escalation path to do the most damage. You could skip this and run the DB as root, but that’s a big security trade off that most users shouldn’t be taking.
- viraptor 3y ago
  That's not really a practical issue in most cases. In almost every situation if you attack the database host, there's nothing apart from the database running there. Once you control the database you have full data access already. You'll potentially need to escalate to enable outbound network access if it's restricted on the host rather than network layer, but even that's not common. For large databases you're more likely to get more access by changing trusted serialised data, or inject some commands where possible.
  - danpalmer 3y ago
    Having access to a restricted database user may well not grant access to all data, but being able to escape to the root system user could mean free access to the data reading it directly off disk. Root access also provides many more opportunities for persistence. Most attackers don't want to be discovered, they want to remain and continue to exfiltrate. Exfiltration out-of-band will also be easier as root as you would be able to modify the firewall. Root may be a little less useful on a cloud VM where there is cloud level network isolation etc, but it's still a Bad Idea.