Bug 1019784 - RBAC: Trying to remove a server group as a server-group-scoped role leaks information
Summary: RBAC: Trying to remove a server group as a server-group-scoped role leaks inf...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ER7
: EAP 6.2.0
Assignee: Brian Stansberry
QA Contact: Ladislav Thon
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-16 12:03 UTC by Ladislav Thon
Modified: 2014-05-27 01:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-15 16:22:04 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-2317 0 Major Closed Trying to remove a server group as a server-group-scoped role leaks information 2018-10-02 13:35:51 UTC

Description Ladislav Thon 2013-10-16 12:03:19 UTC
This can't yet be reproduced on any EAP 6.2.0.ERx release, as it depends on a relatively new upstream commit. That's also why I'm only including a short description.

If a user in a server-group-scoped role tries to :remove a server-group that she has no permissions to, she gets a bad error message. Instead of "not found", the error message says "permission denied", effectively leaking the information that the server group exists.

Again, this can't be reproduced on any ERx release; in fact, on the last ERx release, which at this time is ER5, this works perfectly fine.

Comment 1 JBoss JIRA Server 2013-10-16 12:09:28 UTC
Ladislav Thon <lthon@redhat.com> made a comment on jira WFLY-2317

I believe that this commit might be the cause: https://github.com/wildfly/wildfly/commit/6e35f084deeeb1df3c555bcdda121b7cd157cea2 At least it is the reason why I wrote that test case.

Comment 2 Brian Stansberry 2013-10-16 20:07:17 UTC
I don't believe this should be "high" severity. See https://bugzilla.redhat.com/show_bug.cgi?id=1015524#c1 for an explanation of why the other server groups are not addressable. It's really not an attempt to hide sensitive data. It's an unsuccessful attempt to provide a coherent view of the resource tree to the user. Ideally these resources would be addressable but not readable, but we can't do that for 6.2 without introducing too much risk for breaking things in the console.

No argument that if the resource is not supposed to be addressable a permission denied response is not correct.

Comment 3 Ladislav Thon 2013-10-17 06:20:59 UTC
If this is not supposed to hide sensitive data (which I believed is the case), then I'm lowering the severity to medium. Still, :read-resource and :remove on a non-addressable resource should give the same answer.

Comment 4 Ladislav Thon 2013-10-17 06:31:42 UTC
One more thing -- if we have these resources non-addressable now and we'll try to make them addressable & non-readable in the future, that might be considered a regression by some customers. I'm not sure what my feelings about that would be.

Comment 5 Ladislav Thon 2013-10-17 08:35:28 UTC
This is reproducible on ER6 using the same instructions as in the upstream issue. Copying those instructions here for reference.

On a freshly unpacked EAP 6.2.0.ER6 with added "admin" user into domain/configuration/mgmt-users.properties, the problem can be reproduced like this:

[1] ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c
    /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
    /core-service=management/access=authorization/role-mapping=NewRole:add
    /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    exit
[1] ^C
    ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
    /server-group=other-server-group:read-resource
    /server-group=other-server-group:remove

What does that mean? The "NewRole" role is scoped to the "main-server-group" server group and can't see the "other-server-group" group. When doing "/server-group=other-server-group:read-resource", this is correctly enforced and the output looks like this:

{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
    "rolled-back" => true
}

However, trying to do "/server-group=other-server-group:remove", which is only a different operation _on the same resource_, I get a different error message:

{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
    "rolled-back" => true
}

I expect the error message to be completely the same as in previous case, not leaking any information that the "other-server-group" group actually exists.

Comment 10 JBoss JIRA Server 2013-10-18 10:56:58 UTC
Ladislav Thon <lthon@redhat.com> made a comment on jira WFLY-2317

I've rebased the branch and submitted a pull request (the branch/PR contains some more tests than this one). In the PR, I changed the test to pass and added a comment to explain that it shouldn't be Outcome.UNAUTHORIZED but Outcome.HIDDEN.

Comment 11 JBoss JIRA Server 2013-10-21 18:50:45 UTC
Brian Stansberry <brian.stansberry@redhat.com> updated the status of jira WFLY-2317 to Coding In Progress

Comment 13 Ladislav Thon 2013-11-04 10:46:22 UTC
Verified with EAP 6.2.0.ER7.


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