Project

General

Profile

Fix #7919

mon: prevent clients with a read cap from reading the full keyring

Added by Greg Farnum over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Immediate
Category:
Monitor
Target version:
-
Start date:
03/31/2014
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

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?

Associated revisions

Revision db266a3f (diff)
Added by Joao Eduardo Luis over 5 years ago

mon: MonCommands.h: have 'auth' read-only operations require 'x' cap

This reintroduces the same semantics that were in place in dumpling prior
to the refactoring of the cap/command matching code.

We haven't added this requirement to auth read-write operations as that
would have the potential to break a lot of well-configured keyrings once
the users upgraded, without any significant gain -- we assume that if
they have set 'rw' caps on a given entity, they are indeed expecting said
entity to be sort-of-privileged entities with regard to monitor access.

Fixes: #7919

Signed-off-by: Joao Eduardo Luis <>
Reviewed-by: Sage Weil <>

Revision 36e9d80b (diff)
Added by Joao Eduardo Luis over 5 years ago

mon: MonCommands.h: have 'auth' read-only operations require 'x' cap

This reintroduces the same semantics that were in place in dumpling prior
to the refactoring of the cap/command matching code.

We haven't added this requirement to auth read-write operations as that
would have the potential to break a lot of well-configured keyrings once
the users upgraded, without any significant gain -- we assume that if
they have set 'rw' caps on a given entity, they are indeed expecting said
entity to be sort-of-privileged entities with regard to monitor access.

Fixes: #7919

Signed-off-by: Joao Eduardo Luis <>
Reviewed-by: Sage Weil <>
(cherry picked from commit db266a3fb2985605738201f59f07fa504c91c770)

Conflicts:

doc/release-notes.rst

History

#1 Updated by Joao Eduardo Luis over 5 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.

#2 Updated by Greg Farnum over 5 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

#3 Updated by Joao Eduardo Luis over 5 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.

#4 Updated by Joao Eduardo Luis over 5 years ago

  • Priority changed from High to Immediate

#5 Updated by Joao Eduardo Luis over 5 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.

#6 Updated by Sage Weil over 5 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?

#7 Updated by Greg Farnum over 5 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.

#8 Updated by Joao Eduardo Luis over 5 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.

#9 Updated by Joao Eduardo Luis over 5 years ago

  • Status changed from In Progress to Need Review

#10 Updated by Sage Weil over 5 years ago

  • Status changed from Need Review to Resolved

#11 Updated by Sage Weil over 5 years ago

merged to master/firefly. backported to emperor too, along with a release note.

Also available in: Atom PDF