Project

General

Profile

Bug #19790

rados ls on pool with no access returns no error

Added by Florian Haas 6 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
Security
Target version:
-
Start date:
04/27/2017
Due date:
% Done:

0%

Source:
Tags:
security
Backport:
kraken,jewel
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Release:
jewel
Needs Doc:
No
Component(RADOS):
OSD

Description

Given the following auth capabilities:

client.jane
        key: AQCGsAFZMzgoFhAAr/qnglmIzxJoDwwSV2e4zg==
        caps: [mon] allow r
        caps: [osd] allow * pool=whirlpool

... the expectation is that "rados ls" would fail on any pool other than "whirlpool". It does not:

$ rados -n client.jane -p test ls; echo $?
testobj0
0

ceph version 10.2.7 (50e863e0f4bc8f4b9e31156de690d765af245185)


Related issues

Copied to RADOS - Backport #20722: kraken: rados ls on pool with no access returns no error Rejected
Copied to RADOS - Backport #20723: jewel: rados ls on pool with no access returns no error Resolved

History

#1 Updated by Florian Haas 5 months ago

  • Category set to Monitor
  • Tags set to security
  • Release jewel added

Just checking: is anyone looking at this? It's arguably a security issue, after all.

#2 Updated by Xiaoxi Chen 5 months ago

  • Status changed from New to Verified
  • Priority changed from Normal to Urgent

#3 Updated by Greg Farnum 5 months ago

I'm not at a computer to check, but I'm pretty sure the "allow *" is short-circuiting other security checks here and letting it do whatever it wants. Try with rwx instead.

#4 Updated by Florian Haas 5 months ago

Same issue even with just rw:

# ceph auth get client.jane
exported keyring for client.jane
[client.jane]
    key = AQB9DhxZWVW1NRAA4ELXsaIK13yFPPnCfEsaaA==
    caps mon = "allow r" 
    caps osd = "allow rw pool=whirlpool" 

# rados -p test -n client.jane ls
testobj

Note: both rados get and rados put do fail in the test pool, it's just listing objects that succeeds.

#5 Updated by Greg Farnum 5 months ago

  • Category changed from Monitor to OSD

Well, it's obvious enough, we go into PrimaryLogPG::do_pg_op() before we check op_has_sufficient_caps().

I think there may be some issues with translating between the usual per-object cap semantics and the pg listing that need to be dealt with though. ie, what happens if they run a listing but can only look at keys with a certain prefix?

I think at that point we probably just deny the listing, but it's not coded up yet. I may get around to this eventually but if somebody else wants to it's a pretty self-contained bit of code.

#6 Updated by Florian Haas 5 months ago

For what it's worth, this is a regression. In Hammer, the appropriate EPERM is raised:

$ rados -n client.libvirt -p .rgw ls
rados returned (1) Operation not permitted

#7 Updated by Brad Hubbard 5 months ago

  • Assignee set to Brad Hubbard

Looking into this

#8 Updated by Brad Hubbard 5 months ago

https://github.com/ceph/ceph/pull/15354

Greg, will talk to you about the per-object cap semantics separately.

#9 Updated by Brad Hubbard 5 months ago

  • Status changed from Verified to In Progress
  • Backport set to kraken,jewel

#10 Updated by Greg Farnum 4 months ago

  • Project changed from Ceph to RADOS
  • Category changed from OSD to Security
  • Component(RADOS) OSD added

#11 Updated by Sage Weil 4 months ago

  • Status changed from In Progress to Resolved

#12 Updated by Florian Haas 3 months ago

Thanks a lot for the fix in master/luminous, taking the liberty to follow up on this one — looks like the backport to Jewel is still pending. Is this still in the cards?

#13 Updated by Nathan Cutler 3 months ago

  • Status changed from Resolved to Pending Backport

#14 Updated by Nathan Cutler 3 months ago

  • Copied to Backport #20722: kraken: rados ls on pool with no access returns no error added

#15 Updated by Nathan Cutler 3 months ago

  • Copied to Backport #20723: jewel: rados ls on pool with no access returns no error added

#16 Updated by Brad Hubbard 3 months ago

Looks like we may have set the wrong state on this tracker and therefore overlooked it for the purposes of backporting. It looks like Nathan has set this straight now, sorry for the delay.

#17 Updated by Florian Haas 3 months ago

No worries, thanks for the update!

#18 Updated by Nathan Cutler about 1 month ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF