TrueCloudLab/policy-engine

Fork 12

generated from TrueCloudLab/basic

Ignore local overrides with `Allow` status in chain router #97

Open

aarifullin wants to merge 1 commit from aarifullin/policy-engine:fix/83_ignore_override_allow into master

aarifullin commented

2025-02-21 13:52:11 +00:00

Member

If a target owner sets some private rules into morph, then the access may be intentionally/unintentionally violated by setting a local override that allows any operation;
The same happens if no morph rule is found;
Fix unit-test TestInmemory_MultipleTargets;
Add unit-test TestLocalOverrideAllowRule.

Close #83

* If a target owner sets some private rules into morph, then the access may be intentionally/unintentionally violated by setting a local override that allows any operation; * The same happens if no morph rule is found; * Fix unit-test `TestInmemory_MultipleTargets`; * Add unit-test `TestLocalOverrideAllowRule`. Close #83

aarifullin added the

bug

label 2025-02-21 13:52:11 +00:00

aarifullin added 1 commit 2025-02-21 13:52:12 +00:00

[#83 ] router: Ignore local overrides with Allow status

DCO action / DCO (pull_request) Successful in 27s

Details

Tests and linters / Tests (pull_request) Successful in 39s

Details

Tests and linters / Staticcheck (pull_request) Successful in 56s

Details

Tests and linters / Tests with -race (pull_request) Successful in 57s

Details

Tests and linters / Lint (pull_request) Successful in 1m38s

Details

d1db407c72

* If a target owner sets some private rules into morph, then the
  access may be intentionally/unintentionally violated by setting
  a local override that allows any operation;
* The same happens if no morph rule is found;
* Fix unit-test `TestInmemory_MultipleTargets`;
* Add unit-test `TestLocalOverrideAllowRule`.

Signed-off-by: Airat Arifullin <aarifullin@yadro.com>

requested reviews from storage-services-developers, storage-core-committers, storage-core-developers, storage-services-committers

2025-02-21 13:52:12 +00:00

dstepanov-yadro approved these changes 2025-02-24 06:44:33 +00:00

elebedeva approved these changes 2025-02-24 07:42:38 +00:00

fyrchik commented

2025-02-24 10:25:09 +00:00

Owner

If a target owner sets some private rules into morph, then the access may be intentionally/unintentionally violated by setting a local override that allows any operation;

The whole point of local overrides is to allow doing anything intentionally.
Why is this a problem?

>If a target owner sets some private rules into morph, then the access may be intentionally/unintentionally violated by setting a local override that allows any operation; The whole point of local overrides is to allow doing anything intentionally. Why is this a problem?

aarifullin was assigned by dkirillov

2025-02-24 11:48:46 +00:00

aarifullin commented

2025-02-24 12:10:50 +00:00

Author

Member

@fyrchik wrote in #97 (comment):

If a target owner sets some private rules into morph, then the access may be intentionally/unintentionally violated by setting a local override that allows any operation;

The whole point of local overrides is to allow doing anything intentionally. Why is this a problem?

The dilemma is quite sensitive for public networks:

A frostfs-storage instance is hijacked and overrides define allow object.* * for root namespace !
A frostfs-storage's owner sets incorrect overrides which define allow object.* * for root namespace !

At the same time:
A container owner conceived to permit the access to sensitive data only for couple of public key.
If some objects are reported for some kind of abuse, nodes are able to easily set denying overrides for object or whole container.

Perhaps, a frostfs-storage's owner should be able to allow the access for a particular user (e.g. investigation), but I am concerned about 1), 2). That might be a disaster.

Everything else can be solved by a node owner as he's got a wallet that identified as the role container.

@fyrchik wrote in https://git.frostfs.info/TrueCloudLab/policy-engine/pulls/97#issuecomment-68300: > > If a target owner sets some private rules into morph, then the access may be intentionally/unintentionally violated by setting a local override that allows any operation; > > The whole point of local overrides is to allow doing anything intentionally. Why is this a problem? The dilemma is quite sensitive for public networks: 1. A frostfs-storage instance is hijacked and overrides define `allow object.* *` for root namespace **!** 2. A frostfs-storage's owner sets incorrect overrides which define `allow object.* *` for root namespace **!** At the same time: A container owner conceived to permit the access to sensitive data only for couple of public key. If some objects are reported for some kind of abuse, nodes are able to easily set denying overrides for object or whole container. Perhaps, a frostfs-storage's owner should be able to allow the access for a particular user (e.g. investigation), but I am concerned about 1), 2). That might be a **disaster**. Everything else can be solved by a node owner as he's got a wallet that identified as the role `container`.