Bug 1021607 - [Doc Change] RBAC: The two kinds of non-addressability
Summary: [Doc Change] RBAC: The two kinds of non-addressability
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: EAP 6.4.0
Assignee: Scott Mumford
QA Contact: Ladislav Thon
URL:
Whiteboard:
Depends On:
Blocks: 1013506
TreeView+ depends on / blocked
 
Reported: 2013-10-21 15:45 UTC by Ladislav Thon
Modified: 2015-07-03 00:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Some resources are non-addressable to server-group and host scoped roles in order to provide a simplified view of the management model to improve usability. This is distinct from resources that are non-addressable to protect sensitive data. For server-group scoped roles this means that resources in the `profile`, `socket binding group`, `deployment`, `deployment override`, `server group`, `server config` and `server` portions of the management model will not be visible if they are not related to the server-groups specified for the role. For host-scoped roles this means that resources in the `/host=*` portion of the management model will not be visible if they are not related to the server groups specified for the role. However in some cases this simplified view can hide information that while it is outside the scope of what the user is managing, it can provide guidance to the user as to a course of action. An example of this is http://bugzilla.redhat.com/show_bug.cgi?id=1015524[BZ# 1015524]. In a future release, some of these non-addressable resources might be changed to be addressable but non-readable. This will not affect the security of the server because they were not non-addressable for security reasons. Red Hat recommends that you do not rely on the non-addressability of resources to hide information unless the non-addressability is defined in a sensitivity constraint.
Clone Of:
Environment:
Last Closed: 2015-07-03 00:50:13 UTC
Type: Bug


Attachments (Terms of Use)

Description Ladislav Thon 2013-10-21 15:45:08 UTC
We need to properly describe in the docs that we actually have TWO kinds of non-addressability: intentional and non-intentional. The reason we need this documented is that in the future, we probably will want to make the non-intentionally non-addressable resources addressable (and non-readable). This might be considered a regression by some customers, which is what the documentation should prevent.

Why could such change be considered a regression? If an address of a resource contains sensitive data (like a name of a security domain), then the resource must be non-addressable [for roles that can't read sensitive data]. Thus, non-addressability is a security measure. If we change non-addressable resource to addressable & non-readable in the future, customers might get a feeling that we are weakening the security of the system.

Why would we want to make some non-addressable resources addressable in the future? Some resources that are now non-addressable are actually NOT meant to be (see e.g. bug 1015524). They are meant to be addressable & non-readable, but the web console doesn't support this combination yet (see https://issues.jboss.org/browse/HAL-283). So they being non-addressable is a workaround and we intend to do a proper solution in the future. It can't happen in EAP 6.2 due to time constraints, though.

Brian explained the situation quite clearly: "One possible way to document this is that users should only consider non-addressability that results from the sensistivity classification configs to be a stable contract. The fact that scoped roles can't address certain otherwise non-sensitive resources may, and likely will, change in a later release."

Incidentally, the documentation states in 10.8.2 that "If you do not have permissions to access a resource or attribute at all (it is "unaddressable" for your role) then it does not appear in the console at all for you. An example of that is when a role is scoped to a server group, other server groups will not be visible." This is a perfect example of non-addressable resource that is NOT meant to be non-addressable and that will likely change to addressable in the future. This example should be changed to something else.

For more background on this issue, see bug 1019784 and/or this thread on wildfly-rbac: http://post-office.corp.redhat.com/archives/wildfly-rbac/2013-October/msg00017.html.

CC'ing Darrin as RBAC documentation author, Brian as dev owner, Pavel as QE manager and John and Mark as PM, so that noone misses this.

Comment 1 John Doyle 2013-10-22 20:02:17 UTC
Do we think we know the full permutations of the non-intentionally non-addressable resources?  Can we list them in a release note to make clear that the interactions around these resources may change?

Comment 2 Brian Stansberry 2013-10-22 20:52:19 UTC
John,

For server group scoped roles this details the addressability behavior in 6.2:

The Server Group Scoped Role will include privileges for the following resource trees logically related to the server group:

Profile
Socket Binding Group
Deployment
Deployment override
Server group
Server config
Server

Resources in the profile, socket binding group, deployment, deployment override, server group, server config and server portions of the tree that are not logically related to a server group associated with the Server Group Scoped Role will not be addressable by a user in that role. So, for example, in a domain with server groups “a” and “b”, a user in a Server Group Scoped Role that grants access to “a” will not be able to address /server-group=b. The system will treat that resource as non-existent for that user. Nor will it be able to address profiles, socket binding groups, deployments, or deployment overrides that are associated with server group "b" unless they are also associated with server group "a".

For host scoped roles this details the addressability behavior in 6.2:

Resources in the /host=* portion of the tree that are unrelated to the hosts specified for the Host Scoped Role will not be visible to users in that Host Scoped Role. So, in a domain with hosts “a” and “b”, a user in a Host Scoped Role that grants access to “a” will not be able to address /host=b. The system will treat that resource as non-existent for that user. 



We expect (but are not 100% certain) that in later releases some or all of these resources will be addressable, but they will not be readable. To clarify that distinction, a resource is addressable if the existence of its address can be confirmed via the management API; e.g. the response to /:read-children-names(child-type=server-group) would include "b" if it is addressable by the caller and would not include it if it isn't. It is readable if its contents can be read.

Please see https://bugzilla.redhat.com/show_bug.cgi?id=1015524 for an example of the kind of usability issues having these resources not be addressable causes. Making them non-addressable was meant to improve usability by presenting the user with a view of the domain as it would appear if nothing existed outside his or her scope. But this view does not truly reflect reality, and unfortunately reality intrudes, a la the #1015524 case. So it is probably better to allow the user to know of the existence of resources (the names of which are not sensitive).

Comment 3 Brian Stansberry 2013-10-22 21:34:10 UTC
A couple further notes to round out the picture of what scope roles can do:

In addition to the privileges described in the previous comment, users in a Host Scoped Role will have non-sensitive read privileges (equivalent to the Monitor role) for domain wide resources (i.e. those not in the /host=* section of the tree.)

In addition to the privileges described in the previous comment, users in a Server Group Scoped Role will have non-sensitive read privileges (equivalent to the Monitor role) for resources other than those listed above.

Comment 7 Ladislav Thon 2014-05-15 08:12:52 UTC
Did anything change in the 6.3 timeframe, or are we still on the same page here? If nothing changed, we will probably want this documented in 6.3 release notes as well.

Comment 8 Ladislav Thon 2014-05-15 09:51:14 UTC
I just realized that I used the "on the same page" idiom wrongly. Not a native speaker, sorry. Let me rephrase:

Did anything change in the 6.3 timeframe, or is it still the case that non-addressable resources exist that in fact should be addressable but non-readable? If nothing changed, we will probably want this documented in 6.3 release notes as well.

Comment 9 Brian Stansberry 2014-05-15 12:41:44 UTC
Nothing has changed, so yes, the existing Known Issue note should be carried forward.

Comment 10 Russell Dickenson 2014-06-17 23:54:25 UTC
I have begun work on this BZ ticket, adding to the following topic to clarify "addressibility".

About Role-Based Access Control (RBAC) [23145]

Comment 11 Ladislav Thon 2014-06-18 07:45:35 UTC
We agreed that a Known Issue entry in Release Notes is enough for this and no additional changes in documentation are needed. Maybe the flags on this bug made the impression that documentation work is required?

Comment 12 Russell Dickenson 2014-06-19 04:04:39 UTC
Attention: Ladislav

Thank you for your message. I had begun work on adding to the documentation, thinking that it needed to be included. I will now stop that work, as you have confirmed that only the Release Notes entry is required.

Comment 13 Russell Dickenson 2014-06-26 22:45:57 UTC
I have now removed the added text from the following topic:

About Role-Based Access Control (RBAC) [23145]

Comment 15 Ladislav Thon 2014-07-07 12:02:28 UTC
The text is of course OK, as it didn't change, but looking at [1], it's marked "private" and maybe it won't be visible? We had this entry in release notes added manually in the past (see e.g. 6.2.0 release notes at [2]) and we should have it added like that for 6.3.0 too.

Moving back to assigned.

[1] https://documentation-devel.engineering.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/6.3.0_Release_Notes/index.html
[2] https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/6.2.0_Release_Notes/index.html

Reviewed in Revision 6.3.0-12.

P.S.: also note that it's likely we will want this entry in release notes in 6.4 too. So I'm not going to mark this "verified" even when it will be correct. Sounds disappointing, but I don't see a better way.

Comment 16 Scott Mumford 2014-07-08 23:21:03 UTC
No problems with that approach Ladislav. I need this bug open as a reminder anyway.

But I'm going to move it to POST, so I (and others) know there's been work done on it.

Comment 17 Scott Mumford 2014-07-15 04:41:32 UTC
A new build of the 6.3.0 Release Notes is available for review at:
https://documentation-devel.engineering.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/6.3.0_Release_Notes/index.html

When verifying bugs, please ensure you're viewing the latest version of the document (6.3.0-14 or later)

Build details:
https://brewweb.devel.redhat.com/taskinfo?taskID=7700244

Comment 18 Ladislav Thon 2014-07-15 06:43:07 UTC
I'm looking at Revision 6.3.0-14 and this is still shown as "private"?

Comment 19 Scott Mumford 2014-07-15 23:08:43 UTC
D'Oh!

Sorry Ladislav. Total brain-hiccup on my part with this! 

I have the text saved locally, but it was initially exported from this bug (which is private). I need to remember to manually remove that XML for the next build.

Comment 20 Ladislav Thon 2014-07-16 06:59:39 UTC
Wow, I didn't think that adding stuff manually is _that_ involved. I mean, we absolutely must get rid of manual additions to release notes, it's crazy and error-prone as hell.

Would it work better for you if I created a public bug that didn't contain any discussion and details? Then, we could get rid of the process around this bug, and we could even have different bugs for 6.3 and 6.4 (if needed), so the proper BZ process can be followed... What do you think?

Comment 21 Scott Mumford 2014-07-16 21:34:33 UTC
I appreciate the offer Ladislav, but to be honest, there's always going to be a few unique cases each release that aren't going to fit neatly into the automated process and need to be dealt with manually. 

This one is resolved now. I've removed the XML markup that highlighted this entry as private. It won't appear that way in any future builds.

Comment 22 Ladislav Thon 2014-07-25 15:11:12 UTC
This is fine in current version of 6.3.0 release notes (Revision 6.3.0-17).

I'm moving this to POST as per comment 16 and consider this bug finished from 6.3 perspective. Please don't move to ON_QA or any other state -- we will need this bug for 6.4 as well.

Comment 23 Ladislav Thon 2014-08-14 13:02:36 UTC
Tom, we agreed that it is enough to document this in release notes and no other documentation is needed. Why the component change?

Comment 24 Ladislav Thon 2014-08-15 07:05:14 UTC
Turns out this is a mass change in documentation-related bugs, this one just was first in my inbox. Clearing the needinfo flag.

Comment 25 Ladislav Thon 2014-12-01 08:56:38 UTC
Scott, how are we going to handle this release notes item in 6.4? I'm not aware of any changes in this area, so I guess that we will still want to have this documented. Shall we open a new BZ for that when the time comes?

Comment 26 Ladislav Thon 2015-01-23 07:42:34 UTC
Brian, it's that time of the year again :-)

Did anything change in the 6.4 timeframe, or is it still the case that non-addressable resources exist that in fact should be addressable but non-readable? If nothing changed, we will want this documented in 6.4 release notes as well.

Comment 27 Brian Stansberry 2015-01-23 16:34:28 UTC
Nothing has changed.

Comment 28 Ladislav Thon 2015-01-26 07:22:25 UTC
Scott, how are we going to handle this in 6.4 release notes? We need to carry the existing Known Issue forward. Do you want me to create a new BZ, given that you closed this one 2 months ago?

Comment 29 Ladislav Thon 2015-01-27 07:57:57 UTC
Reopening so that this isn't forgotten. We still need to add the Known Issue text manually to the Release Notes, this time for 6.4.


Note You need to log in before you can comment on or make changes to this bug.