Opened at 2021-09-02T14:30:54Z
Closed at 2021-09-07T12:41:38Z
#3785 closed defect (fixed)
GBS does not preserve the capability-based access control mechanism to the storage service
| Reported by: | exarkun | Owned by: | exarkun |
|---|---|---|---|
| Priority: | normal | Milestone: | HTTP Storage Protocol |
| Component: | unknown | Version: | n/a |
| Keywords: | Cc: | ||
| Launchpad Bug: |
Description
In the Foolscap-based protocol, a fURL is used to authenticate a storage server (using the tub-derived hash) *and* find the storage service (using the swissnum).
It is relatively easy to connect to a Foolscap tub hosting a storage service. All you need to do is scan an address range until you find one. To prevent arbitrary clients from allocating arbitrary storage, the swissnum makes it *hard* to get the storage service after connecting to the Foolscap tub. If you know the swissnum - a moderately long random secret - you can find the storage service; if you don't, you can't.
GBS uses NURLs which each include a swissnum. However, the GBS specification does not incorporate the swissnum into the protocol at all. It places storage service endpoints at predictable, fixed locations (eg /v1/version). This means anyone who scans a network and discovers a GBS server can use the storage service.
This eliminates the access control mechanism that was previously in place for the Foolscap-based protocol.
Change History (2)
comment:1 Changed at 2021-09-03T20:33:54Z by exarkun
comment:2 Changed at 2021-09-07T12:41:38Z by GitHub <noreply@…>
- Resolution set to fixed
- Status changed from new to closed
In a5d764d/trunk:
https://github.com/tahoe-lafs/tahoe-lafs/pull/1120