[JBoss JIRA] (WFCORE-1948) Management IN-VM Bypass
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1948?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1948:
-------------------------------------
Description:
Previously we were able to detect in-vm calls as they did not have a Subject established on the AccessControlContext.
Switching to WildFly Elytron we are guaranteed to always have a SecurityIdentity as by default an anonymous one will always be created.
This task is to add an API for in-vm calls backed by security manager based permission checks to allow tasks to be executed "bypassing" access control. Our default implementation is role based so this bypass will work by assuming the SuperUser role.
was:
Previously we were able to detect in-vm calls as they did not have a Subject established on the AccessControlContext.
Switching to WildFly Elytron we are guaranteed to always have a SecurityIdentity as by default an anonymous one will always be created.
This task is to add an API for in-vm calls backed by security manager based permission checks to allow tasks to be executed using a specified role.
> Management IN-VM Bypass
> -----------------------
>
> Key: WFCORE-1948
> URL: https://issues.jboss.org/browse/WFCORE-1948
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha12
>
>
> Previously we were able to detect in-vm calls as they did not have a Subject established on the AccessControlContext.
> Switching to WildFly Elytron we are guaranteed to always have a SecurityIdentity as by default an anonymous one will always be created.
> This task is to add an API for in-vm calls backed by security manager based permission checks to allow tasks to be executed "bypassing" access control. Our default implementation is role based so this bypass will work by assuming the SuperUser role.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1948) Management IN-VM Bypass
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1948?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1948:
-------------------------------------
Summary: Management IN-VM Bypass (was: Management RunAs Role Handling)
> Management IN-VM Bypass
> -----------------------
>
> Key: WFCORE-1948
> URL: https://issues.jboss.org/browse/WFCORE-1948
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha12
>
>
> Previously we were able to detect in-vm calls as they did not have a Subject established on the AccessControlContext.
> Switching to WildFly Elytron we are guaranteed to always have a SecurityIdentity as by default an anonymous one will always be created.
> This task is to add an API for in-vm calls backed by security manager based permission checks to allow tasks to be executed using a specified role.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1948) Management RunAs Role Handling
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1948:
----------------------------------------
Summary: Management RunAs Role Handling
Key: WFCORE-1948
URL: https://issues.jboss.org/browse/WFCORE-1948
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Alpha12
Previously we were able to detect in-vm calls as they did not have a Subject established on the AccessControlContext.
Switching to WildFly Elytron we are guaranteed to always have a SecurityIdentity as by default an anonymous one will always be created.
This task is to add an API for in-vm calls backed by security manager based permission checks to allow tasks to be executed using a specified role.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1598:
------------------------------------------
[~sguilhen] Forgot, one more place here where we need to be able to convert a SecurityIdentity to a Subject.
> Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1598
> URL: https://issues.jboss.org/browse/WFCORE-1598
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha12
>
>
> In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request.
> For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7503) Typo in NamingLogger log message with id WFLYNAM0060
by Dmitrii Tikhomirov (JIRA)
Dmitrii Tikhomirov created WFLY-7503:
----------------------------------------
Summary: Typo in NamingLogger log message with id WFLYNAM0060
Key: WFLY-7503
URL: https://issues.jboss.org/browse/WFLY-7503
Project: WildFly
Issue Type: Bug
Components: Naming
Affects Versions: 10.1.0.Final
Reporter: Dmitrii Tikhomirov
Assignee: Dmitrii Tikhomirov
Priority: Minor
There is a typo "attributed" in the log message:
{code}
@Message(id = 60, value = "Binding type %s requires attributed named %s defined")
OperationFailedException bindingTypeRequiresAttributeDefined(BindingType bindingType, String attributeName);
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7502) Complicated failure-description in Elytron constant-permission-mapper
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7502:
----------------------------------
Summary: Complicated failure-description in Elytron constant-permission-mapper
Key: WFLY-7502
URL: https://issues.jboss.org/browse/WFLY-7502
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
There is complicated failure-description in Elytron constant-permission-mapper. Failure description in CLI should not contain Exception or snippet of stacktrace. Please instead of "Caused by:" parts from example below use some non-java administrator friendly message.
Complicated failure-description:
{code}
/subsystem=elytron/constant-permission-mapper=permission-mapper:add(permissions=[{class-name=WrongClass}])
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.permission-mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.permission-mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [WrongClass].
Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"WrongClass\"
Caused by: java.lang.ClassNotFoundException: WrongClass from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.permission-mapper"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7502) Complicated failure-description in Elytron constant-permission-mapper
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7502?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7502:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Complicated failure-description in Elytron constant-permission-mapper
> ---------------------------------------------------------------------
>
> Key: WFLY-7502
> URL: https://issues.jboss.org/browse/WFLY-7502
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There is complicated failure-description in Elytron constant-permission-mapper. Failure description in CLI should not contain Exception or snippet of stacktrace. Please instead of "Caused by:" parts from example below use some non-java administrator friendly message.
> Complicated failure-description:
> {code}
> /subsystem=elytron/constant-permission-mapper=permission-mapper:add(permissions=[{class-name=WrongClass}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.permission-mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.permission-mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [WrongClass].
> Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"WrongClass\"
> Caused by: java.lang.ClassNotFoundException: WrongClass from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.permission-mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7502) Complicated failure-description in Elytron constant-permission-mapper
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7502?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7502:
-------------------------------
Labels: user_experience (was: )
> Complicated failure-description in Elytron constant-permission-mapper
> ---------------------------------------------------------------------
>
> Key: WFLY-7502
> URL: https://issues.jboss.org/browse/WFLY-7502
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There is complicated failure-description in Elytron constant-permission-mapper. Failure description in CLI should not contain Exception or snippet of stacktrace. Please instead of "Caused by:" parts from example below use some non-java administrator friendly message.
> Complicated failure-description:
> {code}
> /subsystem=elytron/constant-permission-mapper=permission-mapper:add(permissions=[{class-name=WrongClass}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.permission-mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.permission-mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [WrongClass].
> Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"WrongClass\"
> Caused by: java.lang.ClassNotFoundException: WrongClass from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.permission-mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7501) I can define security domain which doesn't exists yet in SecurityDomain "trusted-security-domains" attribute.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-7501:
----------------------------------
Summary: I can define security domain which doesn't exists yet in SecurityDomain "trusted-security-domains" attribute.
Key: WFLY-7501
URL: https://issues.jboss.org/browse/WFLY-7501
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Security-domain trusted-security-domains attribute has confusing behaviour. I can define there security domain which doesn't exist yet (It is being created right now).
*Steps to reproduce*
{code}
/subsystem=elytron/filesystem-realm=realm1:add(relative-to=jboss.server.config.dir, path=tmp.prop)
{code}
{code}
/subsystem=elytron/security-domain=secDomain888:add(realms=[{realm=realm1}], default-realm=realm1, trusted-security-domains=[secDomain888])
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JGRP-2126) Table.removeMany() creates unneeded temporary list
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2126?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2126:
--------------------------------
In NAKACK2 and UNICAST3, we also create a temp list in {{up(MessageBatch batch)}} to add messages to the table. However, perhaps we should simply modify or remove messages in the batch directly and then pass the batch as argument to {{Table.add()}}.
> Table.removeMany() creates unneeded temporary list
> --------------------------------------------------
>
> Key: JGRP-2126
> URL: https://issues.jboss.org/browse/JGRP-2126
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> When a thread acquires the CAS in NAKACK2 or UNICAST3 to deliver messages, it calls Table.removeMany() which removes messages that satisfy a condition and return them as a list. Next, a MessageBatch is created off of that list and passed up.
> The creation of the temp list is unnecessary; instead create a properly sized MessageBatch and make Table.removeMany() add the messages directly into the batch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months