Project

Profile

Help

Issue #8000

closed

user improperly authenticated via valid cert

Added by gw0101 almost 2 years ago. Updated 11 months ago.

Status:
CLOSED - DUPLICATE
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
2.21.0
Platform Release:
OS:
RHEL 7
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

Ticket moved to GitHub: "pulp/pulpcore/1953":https://github.com/pulp/pulpcore/issues/1953


I am using pulp 2.21.2. I wrote some scripts recently to create "service accounts" that are meant for CI pipeline interactions with building pkgs and publishing to pulp. As part of this design, we are generating long lasting user certs such that there isn't a need to authenticate interactively as that service account user within the CI pipeline. This works, however, there are some security concerns that have come out of this based on the behavior of "pulp/server/webservices/views/decorators.py", specifically, the _verify_auth function design under the following conditions:

  • user cert still valid (within time range and signed by pulp CA)
  • user administratively removed along with permissions

here is the concern:

when assigning CRUDE ops to these service accounts, I am only assigning full CRUDE to a single repository for various reasons. so a pulp-admin rpm repo list using this service account will fail with permissions issue (which is desired and working). the _verify_auth function correctly authenticates using the user_cert_authentication method.

However, if I delete this service account user and the permissions assigned in pulp, I can still use the long lasting cert to gain privilege in that a pulp-admin rpm repo list will succeed for all repos (including ones that the service account originally did not have access to). it appears like _verify_auth function would "authenticate" this non-valid pulp user via the consumer_cert_authentication method (which imho is incorrectly authenticated) and based on the reference in that same module:

DEFAULT_CONSUMER_PERMISSIONS = {'/v2/repositories/': [READ]}

suggests that a consumer authenticated id would have full read access to all repos via this rest endpoint. This access violates the original permissions tied to a single repo for this service account and in effect elevates the privilege in the event of the service account being deleted, while still holding a valid cert (time range and CA) used to authenticate.

an example of some data that we don't not want the service account to see would be metadata for another repo outside of the service account's original repo access.

I thought of a strawman suggestion; leverage the consumer* models and verify that the id out of the cert is in the consumer* collections prior to authorization (perhaps prior to setting is_consumer). it looks like there is precedent for using models here because the function does this if is_consumer is not set by checking to verify that the user is valid from the database. e.g. user = model.User.objects.get(login=login) given that when I remove a user from pulp, I am effectively removing the user and its permissions from the database, if it checked to see that there isn't a consumer for this user / id, it shouldn't assume that the cert is held by a consumer...just a quick thought.

Actions #1

Updated by dkliban@redhat.com almost 2 years ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 88
Actions #3

Updated by rchan almost 2 years ago

  • Sprint changed from Sprint 88 to Sprint 89
Actions #4

Updated by ggainey almost 2 years ago

  • Sprint deleted (Sprint 89)

We haven't forgotten about this issue, but we're a bit resource-constrained for the next month. Moving this off of the sprint, to be reconsidered once that clears up.

Actions #5

Updated by pulpbot 11 months ago

  • Description updated (diff)
  • Status changed from NEW to CLOSED - DUPLICATE

Also available in: Atom PDF