Project

General

Profile

Bug #19790

rados ls on pool with no access returns no error

Added by Florian Haas about 1 year ago. Updated 10 months 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:
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 about 1 year ago

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

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

#2 Updated by Xiaoxi Chen about 1 year ago

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

#3 Updated by Greg Farnum about 1 year 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 about 1 year 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 about 1 year 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 about 1 year 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 about 1 year ago

  • Assignee set to Brad Hubbard

Looking into this

#8 Updated by Brad Hubbard about 1 year 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 about 1 year ago

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

#10 Updated by Greg Farnum about 1 year ago

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

#11 Updated by Sage Weil about 1 year ago

  • Status changed from In Progress to Resolved

#12 Updated by Florian Haas 12 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 12 months ago

  • Status changed from Resolved to Pending Backport

#14 Updated by Nathan Cutler 12 months ago

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

#15 Updated by Nathan Cutler 12 months ago

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

#16 Updated by Brad Hubbard 12 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 12 months ago

No worries, thanks for the update!

#18 Updated by Nathan Cutler 10 months ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF