[JBoss JIRA] (WFCORE-3062) Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
3:38 p.m.
[
https://issues.jboss.org/browse/WFCORE-3062?page=com.atlassian.jira.plugi...
]
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)
3210
days inactive
3210
days old
0 comments
1 participants
participants (1)
-
Brian Stansberry (JIRA)