Fix #7919
closed
mon: prevent clients with a read cap from reading the full keyring
Added by Greg Farnum about 10 years ago.
Updated about 10 years ago.
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?
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.
Hum, I didn't validate the issue so maybe it was user error. Should probably poke him on the mailing list to check. shrug
- 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.
- Priority changed from High to Immediate
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.
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?
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.
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.
- Status changed from In Progress to Fix Under Review
- Status changed from Fix Under Review to Resolved
merged to master/firefly. backported to emperor too, along with a release note.
Also available in: Atom
PDF