Hi everyone,
Just to clarify, our telemetry reports are completely anonymous. The identifier for the reports is a randomly generated UUID for each cluster, which is not related to the cluster's FSID whatsoever on purpose. The FSID is not present in the reports. The publicly accessible data [1] is aggregated and does not expose raw cluster reports.
Thanks,
Yaarit
On Wed, Mar 2, 2022 at 1:33 PM Blaine Gardner <brgardne@xxxxxxxxxx> wrote:
For clarification and the list, this is the reply I mentioned from Anthony. I didn't realize it had just been sent to me:
I’ve always considered it so, albeit without empirical evidence. Eg. in my book I altered all instances of it in examples, including easter eggs that nobody has ever reported :-/ In a previous life every cluster tended to re-use the same fsid, so it could be hardcoded in Ansible. Each was an island without cross-use.
I would think it useless without cephx auth wherewithal, though I’ve read claims that disabling cephx — or signing at least — can lead to significant performance improvements, so I’ve wondered if people are quietly doing so despite the dire warnings._______________________________________________On Wed, 2 Mar 2022 at 11:31, Blaine Gardner <brgardne@xxxxxxxxxx> wrote:Thanks, Greg! I (like Anthony in the other reply) have a vague suspicion that the FSID of a Ceph cluster might be sensitive to display publicly. But I don't have a specific idea for what an attack might look like. I do know that FSID is critical for disaster recovery, which hints to me that it could (maybe, possibly) be sensitive.
The background for the question is this: We have a request in Rook to put the FSID on our CephCluster status. I think most admins won't show that status to all users, but it's not outside the realm of possibility that an admin could give all users read access to the cluster status for some reason. Maybe so they could see if storage was down, or maybe they did it accidentally.It seems like an administrator would have to disable cephx for anyone to do anything malicious with the FSID. Does that sound right? If so (and because most users won't disable cephx), maybe it's okay to put it in the cluster status.
I did consider a potential attack, but it is pretty vaguely shaped in my mind: In a basic kubernetes setup, any pod has access to the pod network and could curl IPs until it finds a Ceph monitor. Then they might be able to impersonate a Ceph daemon. That would hopefully rely on cephx being disabled (not recommended and not likely), and I think it would also rely on them getting the FSID. Does that make any sense?
To your point about the mon advertising its FSID: I just tried curl-ing a mon's port 3300, and the only response I got back was "ceph v2" as far as I could tell. Maybe I didn't poke it right to give me the FSID back.
`curl http://10.130.0.13:3300/api/fsid --output -` returned the same thing.
Thanks again,
BlaineOn Wed, 2 Mar 2022 at 10:42, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:I can't figure out how this would cause issues except via extreme
side-channels for negligible data.
The monitor freely advertises the FSID when you poke at it, so anybody
who has access to a network can find it trivially. So all we're really
looking at is if there's some way to correlate publicly-accessible
data that includes an FSID but is otherwise considered private. And
telemetry would be the way to do that.
What sort of use case are you thinking of? That would let us try and
come up with more informed attacks on it. :)
-Greg
On Wed, Mar 2, 2022 at 9:05 AM Blaine Gardner <brgardne@xxxxxxxxxx> wrote:
>
> Hi all,
>
> Is the FSID of a Ceph cluster considered sensitive information? With the FSID of a cluster, could someone do anything nefarious that they otherwise might not be able to?
>
> For example, someone guessed that one could possibly correlate non-public telemetry data to a specific cluster, but it was confirmed that telemetry cluster id is a randomly generated uuid which is not related to the cluster's FSID.
>
> Thanks,
> Blaine
> _______________________________________________
> Dev mailing list -- dev@xxxxxxx
> To unsubscribe send an email to dev-leave@xxxxxxx
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
