Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 781505 - Pulp's api is left open on an installed system with default username and password
Summary: Pulp's api is left open on an installed system with default username and pass...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: API
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Lukas Zapletal
QA Contact: Garik Khachikyan
URL:
Whiteboard:
Depends On:
Blocks: katello-blockers
TreeView+ depends on / blocked
 
Reported: 2012-01-13 15:54 UTC by Justin Sherrill
Modified: 2019-09-25 21:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-22 18:19:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Justin Sherrill 2012-01-13 15:54:13 UTC 
When installing katello, pulp's api handler is left open so that systems can access repositories. (/pulp/repos)

This is the only thing that needs to be accessible externally, but the other apis are left open as well.  During install we don't change the default admin/admin user/password as well.

So anyone from any remote machine can easily access/modify any pulp data with just admin/admin using the pulp-admin cli.


We should at minimum randomize the pulp admin username and password.  Ideally we would also close off the other pulp apis from the outside (but leave /pulp/repos accessible).
Comment 2 Jay Dobies 2012-01-19 14:50:11 UTC 
I'm not sure I follow. We have the following web apps:

/pulp/api - Our REST APIs, used for doing anything to Pulp. That uses the admin username/password.

/pulp/repos - Just the yum repositories exposed by Pulp. Open to the world unless you're using Pulp's repo authentication.

/pulp/gpg - Holds GPG keys for its repositories. 99% sure this is open to the world.

/pulp/ks - Exposes full base channels for those that have a kickstart tree contained within, needed so we can have it over HTTP (not HTTPS) since kickstart has problems with HTTPS. There is no security on these repositories, they are public to anyone (I mention this also as an FYI in case you never knew and thought this was an issue).

We can't shut off /pulp/api because, well, you won't be able to do anything to Pulp if we do.

I'd suggest changing the password as part of the Katello installation process. I have no idea what the Katello installer does, but at some point I'm guessing it does a sanity check to make sure Pulp is running (we have a ping service). I'd add in a call there to generate a random password and use the Pulp APIs to change it.

For what it's worth, here's how RHUI handles it (admittedly, not a perfect comparison):
- We tell users the default user is admin/admin
- When they start the RHUI Manager and are prompted for that, we warn them they will likely want to change that
- RHUI Manager uses the Pulp APIs to change the password to one provided by the user

If I'm totally missing what you're getting at with this bug, ping me and we can chat about it.
Comment 3 Justin Sherrill 2012-01-26 16:07:37 UTC 
So this bug deals more with a katello's installation and configuration of pulp than pulp itself.  We dont' want to 'turn off' /api either since katello needs it. 


Ideally since initially katello and pulp are all on the same box we dissallow access to /api from anything but localhost.  Although since pulp requires SSL that depends on the hostname, i'm guessing that wouldn't work....

My point is that /api isn't needed by anything outside of the box that katello is running in, so in addition to changing the username, we should block that off (since any service that isn't needed remotely should not be accessible remotely).  

For V1, at a minimum we should change the password, ideally it wouldn't be accessible externally.
Comment 4 Lukas Zapletal 2012-02-28 11:21:14 UTC 
Randomizing the password.

4cca4df 781505 - randomize default admin password for Pulp

Also creating low priority bug for Pulp to disable user authentication. Katello does not need it and it could improve security:

https://bugzilla.redhat.com/show_bug.cgi?id=798219
Comment 7 Garik Khachikyan 2012-03-02 13:29:11 UTC 
Lukas, any scenario that could prove the bug-fix please?

is it enough trying access curl -sk -uadmin:admin https://`hostname`/pulp/api/users and get rejected there?
Comment 8 Lukas Zapletal 2012-03-02 14:13:48 UTC 
Yeah you can do that or yum install pulp-admin adn then:

pulp-admin auth login --username .... --pass ...

Should fail now with admin/admin.
Comment 9 Garik Khachikyan 2012-03-02 14:21:57 UTC 
# VERIFIED

great! doing:
> pulp-admin auth login --username admin --password admin
error:  operation failed: Invalid username or password

and all katello actions related with pulp still continue working fine, (promotions, sync, etc).

So seems we are protected now better :)

check against recent provided beta of CFSE.
Note You need to log in before you can comment on or make changes to this bug.