Haas: Surviving Without A Superuser - Part One

Posted Dec 12, 2021 13:01 UTC (Sun) by kleptog (subscriber, #1183)
In reply to: Haas: Surviving Without A Superuser - Part One by martin.langhoff
Parent article: Haas: Surviving Without A Superuser - Part One

Depends on your threat model. If we're talking about a server which is shared between different departments/apps in the same company then any "vulnerabilities" are completely irrelevant. The other department/app isn't a threat, you just want to prevent undesired interaction under normal situations.

Containerising databases isn't really ideal, because there is so much benefit to large buffer caches and actual hardware. Containers are ideally stateless, and databases are basically only state.

Here we've dealt with the problem by creating a trusted service which the components connect to to create/manage databases and users. Standard roles/rights in Postgres prevent the applications accidentally stomping on each other. The idea of tenants is interesting, but eventually only a small part of the puzzle.

Haas: Surviving Without A Superuser - Part One

Posted Dec 12, 2021 14:38 UTC (Sun) by Wol (subscriber, #4433) [Link]

> The other department/app isn't a threat, you just want to prevent undesired interaction under normal situations.

Until the regulators get involved ...

Cheers,
Wol

Haas: Surviving Without A Superuser - Part One

Posted Dec 12, 2021 16:55 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

> The other department/app isn't a threat, you just want to prevent undesired interaction under normal situations.

Well, you say that...

The reality is that it depends. In some cases, perhaps even most cases, this simplification is perfectly sensible. But if you're going to worry about nation-state adversaries, then you have to make some far more pessimistic assumptions. For example:

* Our adversaries will attempt to install persistent threats and move laterally through our network and other systems.
* Our adversaries will try to get us to hire sleeper agents. They may already have succeeded at this.
* Our adversaries might serve a secret warrant/NSL on one of our employees, demanding their cooperation with some purported investigation, without our knowledge.
* Our adversaries could potentially know almost all security-relevant properties of our systems, either through regulation or espionage.
* Our adversaries can pass laws, which (within their jurisdiction) we have to obey. Such laws are subject to geopolitical considerations, which is why this is not an instant win condition for our adversaries.

As a result, a model in which some subsystems are treated as untrusted may be a necessary component of defense-in-depth, if your adversaries really do have nation-state capabilities.

Haas: Surviving Without A Superuser - Part One

Posted Dec 12, 2021 22:09 UTC (Sun) by kleptog (subscriber, #1183) [Link]

> But if you're going to worry about nation-state adversaries, then you have to make some far more pessimistic assumptions

That is why I said it depended on your threat model. If you care about nation state adversaries then anything cloud related is off the table. If it's not in a private bunker with an armed guard out the front then you may as well give up.

There is always a trade-off between the costs of implementing security and the benefits. In the large number of cases the costs of protecting against a nation state actor are far more than the value of the data. At that point you just have to accept the risk and get on with doing actual work and protecting against the threats you can afford to.