[jboss-jira] [JBoss JIRA] (WFCORE-3062) Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-3062:
----------------------------------------

    Assignee: Brian Stansberry


I'm going to take this one. The problem here is the AttributeDefinition classes are doing a kind of quadruple duty, defining attributes, operation parameters, operation results and detail fields within all three of the others. But the only case where an access constraint is meaningful is for the top level attribute itself. The RBAC logic is not checking detail fields within ModelType.OBJECT attributes looking for constraints.

Checking those would only be meaningful if we'd do the following:

1) Allow a read of a detail field without allowing a read of the rest of the attribute. I doubt we'd ever entertain this as the way details fields are implemented internally is by an OSH reading the entire attribute and then another OSH in a step just reports the single attribute. Allowing the full read to happen just on some sort of trust that a later step will exclude inaccessible info would be difficult and a likely security hole. This seems like a bit of an edge case as well.

2) Allow reads of the overall attribute so long as the read doesn't violate any constraint. That is, if 'undefined' is not sensitive for the field and the field isn't defined it's ok.

3) Allow writes of the overall attribute so long as the write didn't modify the protected field in an illegal way. That is, if 'undefined' is not sensitive for the field and the write doesn't define the field it's ok. If the sensitive field was defined and the write didn't change the value, that's ok, although allowing that is problematic is a exploit hole as it allows users to 'fish' for values they couldn't otherwise read by submitting writes and seeing what value allows the write to succeed.

Given where we are in the release cycle it's fairly likely that for core 3.0 / WildFly 11 we'd just move the constraint to the top level attribute, possibly with some change to ObjectTypeAttributeDefinition.Builder to make that automatic. The downside to this is we have some attributes that may not have had constraints before that now do. For example, before the http-interface http-update-enabled attribute had no sensitivity constraint, but now it does as it has become a redirect to the new 'http-upgrade' attribute, which will now have a constraint because of the sasl-authentication-factory field.

> Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3062
>                 URL: https://issues.jboss.org/browse/WFCORE-3062
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 3.0.0.Beta28
>            Reporter: Stefan Guilhen
>            Assignee: Brian Stansberry
>
> When reading the description of attributes of type OBJECT, the access constraints of the value types contained in the object attribute are not displayed.
> Example: In BaseHttpInterfaceResourceDefinition we have an http-upgrade attribute of type OBJECT that contains the sasl-authentication-factory attribute, which is a simple attribute with an access constraint.
> When running /core-service=management/management-interface=http-interface:read-resource-description(recursive=true) in the CLI the constraint is not displayed for the attribute:
> {noformat}
>             "http-upgrade" => {
>                 "type" => OBJECT,
>                 "description" => "HTTP Upgrade specific configuration",
>                 "expressions-allowed" => false,
>                 "required" => false,
>                 "nillable" => true,
>                 "value-type" => {
>                     "enabled" => {
>                         "type" => BOOLEAN,
>                         "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections",
>                         "expressions-allowed" => false,
>                         "required" => false,
>                         "nillable" => true,
>                         "default" => false
>                     },
>                     "sasl-authentication-factory" => {
>                         "type" => STRING,
>                         "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
>                         "expressions-allowed" => false,
>                         "required" => false,
>                         "nillable" => true,
>                         "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
>                         "min-length" => 1L,
>                         "max-length" => 2147483647L,
>                     }
>                 },
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)