Fix #7919
closedmon: prevent clients with a read cap from reading the full keyring
0%
Description
From the mailing list thread "[ceph-users] Security Hole?"
Hi everyone, I'm running 0.72-2-1 on ubuntu. I just created a client with these ACLs: caps: [mon] allow r caps: [osd] allow rwx pool=cloudstack So my cloudstack + KVM hypervisors work fine. However any client I can view full details of all the cluster's auth keys by running: ceph --id cloudstack --keyring=/etc/ceph/ceph.keyring auth list. Is this a security hole in this version?
Updated by Joao Eduardo Luis about 10 years ago
doesn't seem to happen on latest emperor. checking if anything changed in between 0.72.2 and latest emperor, or if I'm missing something on the cap creation process.
So far,
ceph auth add client.foo mon 'allow r' osd 'allow rwx pool=wtv'
followed by a
ceph --id foo auth export
does report the appropriate 'permission denied' error. Maybe I'm missing something else.
Updated by Greg Farnum about 10 years ago
Hum, I didn't validate the issue so maybe it was user error. Should probably poke him on the mailing list to check. shrug
Updated by Joao Eduardo Luis about 10 years ago
- Status changed from New to In Progress
Okay, I was the one at fault here. Was missing to provide a keyring with the client's key thus getting permission denied, but it does work as reported by the user.
Now on to figure whether this is a feature or a bug.
Updated by Joao Eduardo Luis about 10 years ago
- Priority changed from High to Immediate
Updated by Joao Eduardo Luis about 10 years ago
Here's the thing: obviously, allowing anyone with read permission to simply grab the whole keyring is not a good thing. However, as I see it, the semantic of 'read' should indeed to mark those operations which are read-only instead of read/write.
While in the right-now we really need to plug this, and setting 'rw' covers it, the fact remains that we should probably introduce some sort of 'privileged operation' cap -- so to distinguish 'auth list' or 'auth export' from (say) 'pg stat' --, or even a 'privileged entity' property -- such that a user can indeed retrieve its own keyring but not that of others.
Updated by Sage Weil about 10 years ago
My vote is to make 'auth' special and require * to access it (or an explcit grant of auth rw or something). This is how I remember it working, but if that changed inadvertantely when we refactored this stuff last maybe the simplest thing is to switch it back to that behavior?
Updated by Greg Farnum about 10 years ago
That sounds like the best solution to me. Somebody on the mailing list reported that Dumpling is not exposing user data this way, so should probably look at what that's doing differently, too.
Updated by Joao Eduardo Luis about 10 years ago
My guess is that this behavior kicked in when we started matching client caps with the expected caps on a per-command basis. Before then we would check caps "manually" on each service and on a per-command basis.
sage's suggestion should be easily coded into the AuthMonitor. I think however we should revise the approach when we can, to something a bit more sustainable in the long-run.
Updated by Joao Eduardo Luis about 10 years ago
- Status changed from In Progress to Fix Under Review
pull request 1597 https://github.com/ceph/ceph/pull/1597
Updated by Sage Weil about 10 years ago
- Status changed from Fix Under Review to Resolved
Updated by Sage Weil about 10 years ago
merged to master/firefly. backported to emperor too, along with a release note.