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 1192414 - unprivileged user can see Administer -> Bookmarks
Summary: unprivileged user can see Administer -> Bookmarks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Security
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Ohad Levy
QA Contact: jcallaha
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks: CVE-2016-2100
TreeView+ depends on / blocked
 
Reported: 2015-02-13 10:11 UTC by Jan Hutař
Modified: 2019-09-25 21:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-27 08:48:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
bookmarks visible to unprivileged user (72.74 KB, image/png)
2016-03-24 19:44 UTC, Stephen Benjamin 		no flags Details
non-public bookmark visible to the user (65.27 KB, image/png)
2016-04-04 15:40 UTC, Stephen Benjamin 		no flags Details
privileged (123.63 KB, image/png)
2016-04-28 19:19 UTC, jcallaha 		no flags Details
un-privileged (97.53 KB, image/png)
2016-04-28 19:19 UTC, jcallaha 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 13828 0 None None None 2016-04-22 16:14:02 UTC
Red Hat Product Errata RHBA-2016:1500 0 normal SHIPPED_LIVE Red Hat Satellite 6.2 Base Libraries 2016-07-27 12:24:38 UTC

Description Jan Hutař 2015-02-13 10:11:10 UTC 
Description of problem:
Unprivileged user can see Administer -> Bookmarks


Version-Release number of selected component (if applicable):
Satellite-6.1.0-RHEL-6-20150210.0-Satellite-x86_64


How reproducible:
always


Steps to Reproduce:
1. Login with admin user
2. Switch to "Any context" and create user without any location, org and role
3. Logout with admin user and login with newly created user


Actual results:
The unprivileged user can access Administer -> Bookmarks. He can not get details about these bookmarks, but see them.

Other items user can see - but I do consider them OK:
 * org/loc switcher which is basically empty and without links to manage org/loc
 * Monitor with only sub-item Tasks and that page is empty - this probably
   makes sense as maybe it might happen the unprivileged user have some tasks
   running (?)
 * Red Hat Access menu (upper right corner of the page) with "Search",
   "My Cases" and "Open New Case" which probably makes sense


Expected results:
IMO whole "Administer" menu should be hidden in this case.


Additional info:
Noticed while testing bug 1112182
Comment 1 RHEL Program Management 2015-02-13 10:13:42 UTC 
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Comment 3 Tom Caspy 2015-03-19 14:43:38 UTC 
well, I believe this is by design, bookmarks are a default permission. Only thing I would change is not putting them under the administer tab, as that makes little sense...
PM - what is the expected behaviour?
Comment 4 Bryan Kearney 2015-08-13 16:52:13 UTC 
Changing needinfo to ohad.
Comment 5 Ohad Levy 2016-02-22 09:28:31 UTC 
Created redmine issue http://projects.theforeman.org/issues/13828 from this bug
Comment 6 Bryan Kearney 2016-02-22 11:00:55 UTC 
Upstream bug component is Provisioning
Comment 7 Bryan Kearney 2016-02-22 13:00:55 UTC 
Upstream bug component is Security
Comment 8 Bryan Kearney 2016-02-29 15:01:00 UTC 
Moving to POST since upstream bug http://projects.theforeman.org/issues/13828 has been closed
-------------
Dominic Cleal
CVE-2015-7582 has been assigned.  Please include the number in the commit message.
-------------
Tom Caspy
Applied in changeset commit:a61344da14f73920b4bdc7ad8220e7a0ed998031.
Comment 9 Kurt Seifried 2016-03-01 00:43:11 UTC 
(In reply to Bryan Kearney from comment #8)
> Moving to POST since upstream bug
> http://projects.theforeman.org/issues/13828 has been closed
> -------------
> Dominic Cleal
> CVE-2015-7582 has been assigned.  Please include the number in the commit
> message.
> -------------
> Tom Caspy
> Applied in changeset commit:a61344da14f73920b4bdc7ad8220e7a0ed998031.

Do you have an idea of which erratum you'll include this in (I assume a point release like 6.1.8?). Thanks.
Comment 10 Bryan Kearney 2016-03-01 07:01:49 UTC 
Kurt, this is slated for 6.2
Comment 11 Stephen Benjamin 2016-03-24 19:44:00 UTC 
Failed, unprivileged user can still see bookmarks.  Created a user with no roles, and logged in.  See screenshot.

Tried on: 6.2 Snap 5.1
Comment 12 Stephen Benjamin 2016-03-24 19:44:44 UTC 
Created attachment 1140106 [details]
bookmarks visible to unprivileged user
Comment 14 Ohad Levy 2016-03-31 08:46:56 UTC 
this is by design, the bookmarks in the screenshot are all public! you should not see private bookmarks.
Comment 15 Stephen Benjamin 2016-04-04 15:40:35 UTC 
Created attachment 1143379 [details]
non-public bookmark visible to the user
Comment 16 Stephen Benjamin 2016-04-04 15:40:58 UTC 
What is a "public" bookmark? view_bookmarks is a permission to view bookmarks.  If a user doesn't have it, they shouldn't see bookmarks at all.  It's worth failing QA on this fact alone.

However, even under the idea of "public" vs "private" bookmarks, it still fails. I bookmarked a new search as admin, and my unprivileged user could see it (see new screenshot).
Comment 17 Ohad Levy 2016-04-06 08:40:24 UTC 
public bookmarks, are public - meaning every user (regardless of permission) will see.

private bookmarks are private, and only the current user should see them.
you screenshot only shows public bookmarks, which is as designed.
Comment 19 Roman Plevka 2016-04-20 11:05:18 UTC 
Stephen, Ohad - perhaps we might prevent confusion by renaming the permission to something like 'view_private_bookmarks'.
Otherwise, the current name ('view_bookmarks') really leads to confusion while user without such permission still can see a bookmarks page.
Comment 20 Stephen Benjamin 2016-04-20 13:09:41 UTC 
No, I don't think that is the solution and I'd like to hear an argument why if a user doesn't have view_bookmarks, they should still see the menu.  No other Satellite object works like this.

How do you even create a "private" bookmark? 

There's zero indication to the user when they create a bookmark from the search bar that's visible to every single person who can login to the Satellite.
Comment 21 Stephen Benjamin 2016-04-20 13:16:29 UTC 
I found the answer on my own, there's a public check box that's checked by default.

I still say this fails QA, no other object in Satellite works like this and the bug title is literally "unprivileged user can see Administer -> Bookmarks."

Lack of view_bookmarks should hide the menu. But if we're just going to have some weird one-off object that doesn't work like anything else, someone else can mark this VERIFIED.
Comment 22 Jan Hutař 2016-04-20 18:49:36 UTC 
(In reply to Roman Plevka from comment #19)
> Stephen, Ohad - perhaps we might prevent confusion by renaming the
> permission to something like 'view_private_bookmarks'.
> Otherwise, the current name ('view_bookmarks') really leads to confusion
> while user without such permission still can see a bookmarks page.

This sounds as a good solution to me.

(In reply to Stephen Benjamin from comment #21)
> I found the answer on my own, there's a public check box that's checked by
> default.

Heh, great. I have completely missed that. Thanks for the info!
Comment 23 Stephen Benjamin 2016-04-20 19:34:42 UTC 
> This sounds as a good solution to me.

It doesn't to me.  Every controller in Foreman has a permission that gates access.  Why does view_bookmarks mean "private" bookmarks only?

A user without 'view_bookmarks' should not see them as an option in search bars, should not see them in menu items, etc.  This is how *EVERY* other permission works.

I marked this FailedQA in good faith with a good argument for it, but it keeps getting set back to ON_QA without my concern being addressed.
Comment 25 jcallaha 2016-04-28 19:14:46 UTC 
Verified in Satellite 6.2 Beta RC. See attached screenshots for the difference between the two.
I agree that the current system of having bookmarks be private or public meets the intent of the bug. However, I would recommend a name change for the role.
Comment 26 jcallaha 2016-04-28 19:19:01 UTC 
Created attachment 1152044 [details]
privileged
Comment 27 jcallaha 2016-04-28 19:19:29 UTC 
Created attachment 1152045 [details]
un-privileged
Comment 29 errata-xmlrpc 2016-07-27 08:48:08 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1500
Note You need to log in before you can comment on or make changes to this bug.