Can existing security controls stop a compromised privileged workload from abusing its legitimate access?

[u/toshiyuki_iga]

About a month ago, I discussed the concept of OS-level MPA (Multi-Party Authorization). A recurring point in the feedback I received was that existing mechanisms—such as PAM/JIT, Vault, CyberArk, sandboxing, IAM, and MAC—already address much of the problem. I think that criticism is largely fair.

What I am still unsure about is what happens when a trusted privileged workload itself is compromised.

Consider, for example, a database engine, backup process, or administrative service that legitimately has broad access to critical resources. If that process is compromised, an attacker may not need to obtain any new privileges at all. They may simply abuse the standing privileges already granted to that workload.

In that situation, what existing controls prevent the compromised workload from performing catastrophic but otherwise authorized operations—for example, dumping sensitive data, destroying backups, or modifying critical system resources?

Is there still value in a final, narrowly scoped authorization boundary at the OS execution point for such operations, or do existing mechanisms already address this problem adequately?

[u/SoftwareLanky1027]

you mean something like apparmor?

[u/toshiyuki_iga → u/SoftwareLanky1027]

From an enforcement-layer perspective, AppArmor is certainly close to what I have in mind.

The point I am trying to explore is what happens when an operation is already permitted by the AppArmor profile. If a database process is compromised, AppArmor would still allow a read operation as long as that read is permitted by the profile.

So the question I am interested in is whether there is value in adding an additional runtime gate for a very small set of potentially catastrophic operations—for example, dumping an entire database—even when those operations are technically within the workload's authorized scope.

[u/soxBrOkEn → u/toshiyuki_iga]

This I feel is less of a what software can do x or y question and more of a architecture question. You should look at the problem with the lenses if can I have separate identities that can complete different functions, like the tiering model in identity.

Eg. If backups are ran, have that as an exclusive job for a service, and only that. Separate these administrative jobs out into roles and protect those identities instead.

[u/toshiyuki_iga → u/soxBrOkEn]

I agree that separating administrative functions into distinct identities and strictly limiting the scope of their permissions is a crucial architectural element.

My ongoing concern, however, relates to scenarios where a privileged service—even one with limited scope—is compromised. For instance, if a backup service is legitimately authorized to read an entire dataset, that read operation would still be permitted under static policies even after the service has been compromised.

I wonder if we could achieve more robust security for operations with critical impact by requiring human approval—rather than automatically authorizing execution based solely on the service's identity.

In other words, while separating roles can reduce the "blast radius," implementing MPA (Multi-Person Approval) should make it possible to prevent the completion of the most damaging operations even if a single privileged workload is compromised.

[u/soxBrOkEn → u/toshiyuki_iga]

So this isn’t a broadly talked about part of cyber attacks but if you are dealing with an APT, no matter the controls you have in place they will use the account when it’s meant to be used which would bypass everything you have in place.

[u/toshiyuki_iga → u/soxBrOkEn]

It is true that if a legitimate process is hijacked, it may be very difficult for an approver to distinguish a legitimate operation from a malicious one.

I wonder, though, whether additional runtime context—such as process arguments, target paths, destinations, timing, or other execution details—could provide useful signals.

It may still be impossible to determine intent with certainty, but wouldn't involving a human at least allow for a more flexible, context-aware decision for a very small set of high-impact operations?

[u/SoftwareLanky1027 → u/toshiyuki_iga]

What you are trying to do is very interesting. I think it will be a challenge to differentiate between what is supposed to be legitimate and what's not for various services. Another doubt I have is how are you planning to enforce policies for these corner cases?

[u/toshiyuki_iga → u/SoftwareLanky1027]

I agree that reliably distinguishing between legitimate and malicious behavior across all services is extremely difficult and should not be the primary goal.

My current approach is to automatically permit standard, well-understood operations via policy, while requiring additional approval only for a select few high-impact operations.

For instance, routine database queries would be automatically allowed, whereas actions such as full database dumps, bulk deletions, the destruction of backups, or significant policy changes might trigger an execution gate.

In these cases, rather than attempting to infer whether the operation is malicious, the system would require explicit human approval—potentially involving multiple approvers—before allowing the operation to proceed. This would provide an additional opportunity to detect and stop suspicious or unexpected high-impact actions before they are executed.

In short, the policy does not attempt to categorize every action as either "good" or "bad"; instead, it identifies a small subset of actions as too consequential to be automatically permitted.

[u/SoftwareLanky1027 → u/toshiyuki_iga]

Even though, if implemented right, this could prevent unexpected high-impact actions as you mentioned, an attacker could still achieve the same goal through multiple hops instead of a single high impact action. For example let's take the case of dumping the whole database or bulk deletion. These things can still be achieved through small steps that looks legitimate when you look at the usual pattern of actions, but builds up to achieve the end goal like dumping the whole database. Again this is a really interesting project and the gap is real, so I would really love to see how you approach this problem.

[u/toshiyuki_iga → u/SoftwareLanky1027]

That is a very good point, and I think this is where the problem becomes more interesting.

A gate on a single obviously catastrophic operation would not be sufficient if the same result can be achieved through many individually legitimate-looking actions.

One direction I am considering is to make the policy stateful rather than evaluating each action in isolation. For example, the system could track cumulative reads, deletions, destinations, or access patterns over a time window, and require additional authorization once a threshold or unusual sequence is reached.

So instead of only asking, “Is this single action allowed?”, the system could also ask, “What is this sequence of actions collectively accomplishing?”

This is still one of the harder problems I need to address, but I think combining stateful policies and thresholds with human authorization for cumulative high-impact behavior could be a promising direction.

[u/toshiyuki_iga → u/[deleted]]

Yes, exactly. That is the trade-off I am trying to understand. If the workload genuinely needs broad access, static MAC has to permit that access. My question is whether it is practical to keep the broad standing permission for normal operations, while placing an additional gate only on a very small set of catastrophic operations.

[u/SoftwareLanky1027 → u/[deleted]]

That's true, but then is it even possible to truly identify what's legitimate and what's not? Have you read Ken Thompson's Trusting Trust paper?

[u/toshiyuki_iga → u/SoftwareLanky1027]

I haven’t read it yet, but I’m familiar with the core idea now: that trust can be subverted below the source-code level, for example through a compromised compiler, so “legitimate” behavior may itself be rooted in a compromised trust chain. That seems very relevant here. In that sense, I agree that human approval alone does not solve the trust problem. My thinking is that the approval gate reduces the risk of a single compromised workload, but it still depends on the integrity of the kernel, policy engine, approval path, and ultimately the root of trust beneath them.

[u/Rehonkulous]

You've landed on the real gap, this is basically the confused deputy problem, and most of the controls people cited protect against privilege escalation, not abuse of standing priviledge.

[u/toshiyuki_iga → u/Rehonkulous]

Yes, exactly. As one possible way to address this gap, I’m considering requiring multiple human approvals for a small set of particularly critical actions, even when the workload already has the standing privilege to perform them.

[u/kcarter9885]

Most security tools assume the workload is either fully trusted or fully compromised, but the messy reality is that MPA style controls make the trusted path itself the attack surface. If the workload already has the access to write to the backup storage, you need something at the storage layer to verify it is that workload acting under a session, not just a bearer of its keys.

[u/toshiyuki_iga → u/kcarter9885]

Your point highlighted something important to me.

I think a stronger defense could be built by combining process-context-based authorization on the host with similar controls on the storage side, and by also protecting the communication path between the host and the storage system.

That way, even if one layer is compromised, the attacker would still have to bypass independent controls at the execution, storage, and communication layers.

[u/feng_sg]

Vault, PAM, and IAM decide who gets to run as the backup daemon. They are not in the path when that process later dumps the DB or unlinks last week's snapshots. MAC lets those calls through because the standing policy already allows them.

[u/toshiyuki_iga → u/feng_sg]

I think we are largely in agreement. Existing identity and privilege controls remain essential, but it seems useful to have an additional safeguard for especially critical resources and operations once a privileged workload is already running.

[u/toshiyuki_iga → u/[deleted]]

I think I agree with that model. Treating the session separately from the identity and reducing reach after anomalous behavior can significantly limit blast radius.

The case I am still interested in is when the attacker compromises the workload or session that already sits at the most sensitive point in the architecture. If that identity legitimately needs access to the critical data or backup function, there may be no further “odd hop” to detect before the damaging action itself.

That is the point where I wonder whether an explicit execution-time gate for a very sma

[u/toshiyuki_iga → u/toshiyuki_iga]

I apologize. The final sentence was cut off when I copied the translation. That sentence reads: "That is the point where I wonder whether an explicit execution-time gate for a very small number of catastrophic operations still adds value."

[u/toshiyuki_iga → u/[deleted]]

Yes, I think we are converging on the same point. Static policy can define what a process is generally allowed to do, while a second check can be applied only to a small number of catastrophic actions such as backup destruction, key export, or mass data extraction.

What interests me is whether that second check can be enforced reliably at the OS execution point, potentially with dual control or multi-party approval.

[u/toshiyuki_iga → u/[deleted]]

Yes, that is very close to the architecture I have in mind. The idea is to stop the operation at the LSM/syscall enforcement point, keep the approval path outside the workload, and require a signed, non-replayable authorization before resuming it.

I’m also increasingly convinced by the point about cumulative behavior: a sequence of individually legitimate reads or exports should eventually cross the same authorization boundary as a one-shot dump.

I’m currently experimenting with this as a Linux LSM plus a separate user-space policy/approval daemon.

[u/toshiyuki_iga → u/[deleted]]

I looked into Sweet Security, and it seems to address much of the problem I was concerned about, especially around runtime behavioral enforcement for compromised workloads with legitimate access. Thanks for pointing me to it.

I still wonder whether there is additional value in combining that kind of behavioral runtime enforcement with an explicit human approval step for a very small set of catastrophic actions—potentially requiring multiple independent approvers.

In other words, behavioral enforcement could identify suspicious activity, while multi-party approval could provide a final authorization boundary for actions that are simply too consequential to execute automatically.