Perceive PUT of TOMBSTONE as DELETE
#2261
Assignees
Labels
discussion
Open discussion of some problem
I2
Regular impact
neofs-storage
Storage node application issues
S1
Highly significant
security
Affects security
U2
Seriously planned
Milestone
Comments
cthulhu-rider
added
discussion
|
The "DELETE" we have now is somewhat of a fake, there is no |
|
This can also add some real meaning to DELETE permission. Currently DELETE can't work without PUT, but if you've got a PUT then you effectively can delete anyway and you don't need a DELETE permission. Which is a security issue as well. Giving someone write-only permissions is a valid use case when we're trying to store some audit logs, for example. So this entity MUST NOT have any way to delete anything, it should just PUT, PUT and PUT. And yet it'll be able to put a tombstone right now. |
|
similar problem is collapse of different PUT and CREATE operations into single PUT. As user, i'd like to grant rights to PUT my objects (e.g. to gateway), but not CREATE them. Currently there is no clear difference between these actions P.S. maybe we already have related issue, but i didn't find it fast |
cthulhu-rider
added a commit
that referenced
this issue
Feb 21, 2024
Previously, storage nodes handled `ObjectService.Put` requests regardless of object types. Since writing tombstones is essentially an operation of removing objects from their context, this opened up a security issue: granting the right to write objects into the container automatically granted the right to delete any objects from it. This, on the one hand, implicit, on the other hand, strange behavior would raise obvious questions about practical access control in the system. From now, `PUT` ops of `TOMBSTONE` objects are treated as `DELETE`. The only exclusion is intra-container replication that still should be performed in `PUT` manner (container nodes have no removal rights). Closes #2261. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider
added a commit
to nspcc-dev/neofs-spec
that referenced
this issue
Feb 21, 2024
Changed within nspcc-dev/neofs-node#2261 security issue. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider
added a commit
that referenced
this issue
Feb 21, 2024
Previously, storage nodes handled `ObjectService.Put` requests regardless of object types. Since writing tombstones is essentially an operation of removing objects from their context, this opened up a security issue: granting the right to write objects into the container automatically granted the right to delete any objects from it. This, on the one hand, implicit, on the other hand, strange behavior would raise obvious questions about practical access control in the system. From now, `PUT` ops of `TOMBSTONE` objects are treated as `DELETE`. The only exclusion is intra-container replication that still should be performed in `PUT` manner (container nodes have no removal rights). Closes #2261. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider
added a commit
that referenced
this issue
Feb 26, 2024
Previously, storage nodes handled `ObjectService.Put` requests regardless of object types. Since writing tombstones is essentially an operation of removing objects from their context, this opened up a security issue: granting the right to write objects into the container automatically granted the right to delete any objects from it. This, on the one hand, implicit, on the other hand, strange behavior would raise obvious questions about practical access control in the system. From now, `PUT` ops of `TOMBSTONE` objects are treated as `DELETE`. The only exclusion is intra-container replication that still should be performed in `PUT` manner (container nodes have no removal rights). Closes #2261. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider
added a commit
that referenced
this issue
Feb 26, 2024
Previously, storage nodes handled `ObjectService.Put` requests regardless of object types. Since writing tombstones is essentially an operation of removing objects from their context, this opened up a security issue: granting the right to write objects into the container automatically granted the right to delete any objects from it. This, on the one hand, implicit, on the other hand, strange behavior would raise obvious questions about practical access control in the system. From now, `PUT` ops of `TOMBSTONE` objects are treated as `DELETE`. The only exclusion is intra-container replication that still should be performed in `PUT` manner (container nodes have no removal rights). Closes #2261. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider
added a commit
that referenced
this issue
Feb 27, 2024
Previously, storage nodes handled `ObjectService.Put` requests regardless of object types. Since writing tombstones is essentially an operation of removing objects from their context, this opened up a security issue: granting the right to write objects into the container automatically granted the right to delete any objects from it. This, on the one hand, implicit, on the other hand, strange behavior would raise obvious questions about practical access control in the system. From now, `PUT` ops of `TOMBSTONE` objects are treated as `DELETE`. The only exclusion is intra-container replication that still should be performed in `PUT` manner (container nodes have no removal rights). Closes #2261. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
This was referenced Mar 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Nothing seems to prevent the system from interpreting saving tombstones as a deletion operation (*). This approach will greatly facilitate the control over operations (sessions, ACL), and it's completely backward compatible.
(*) the only case is a tombstone replication by container nodes which can be treated especially.
Are there any potential problems with that?
The text was updated successfully, but these errors were encountered: