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

(edit)
Clone Of:
(edit)
Last Closed: 2016-07-27 08:48:08 UTC


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1500 normal SHIPPED_LIVE Red Hat Satellite 6.2 Base Libraries 2016-07-27 12:24:38 UTC
Foreman Issue Tracker 13828 None None None 2016-04-22 16:14 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 Product and 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 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 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 UTC
Created attachment 1152044 [details]
privileged

Comment 27 jcallaha 2016-04-28 19:19 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.