December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Alpha15 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-311: ------------------------------------ Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Better error message if authentication is required to connect to the master but no realm is associated on the slave > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-311 > URL: https://issues.jboss.org/browse/WFCORE-311 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: RH EL 6.3 - JBoss EAP 6.2 > Reporter: Riccardo Benvenuti > Assignee: Brian Stansberry > Priority: Minor > Fix For: 3.0.0.Alpha15 > > > In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below > <domain-controller> > <remote host="10.123.137.200" port="9999"/> > </domain-controller> > we get the following error: > JBoss Bootstrap Environment > JBOSS_HOME: /opt/jboss7/jboss-eap-6.2 > JAVA: /usr/java/jdk1.7.0_51/bin/java > JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > ========================================================================= > 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2 > 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller' > [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2 > [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1 > [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting > [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1 > [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1 > [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1) > [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1 > [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999 > [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure. > [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report > [Host Controller] JBAS014775: New missing/unsatisfied dependencies: > [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm] > [Host Controller] > [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report > [Host Controller] JBAS014775: New missing/unsatisfied dependencies: > [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management] > [Host Controller] > [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report > [Host Controller] JBAS014776: Newly corrected services: > [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required) > [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required) > [Host Controller] > [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms > 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99 > 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller > 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting > Adding the realm everything works correctly > <domain-controller> > <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/> > </domain-controller> > Maybe a warning message could be useful to find the problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-363: ------------------------------------ Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFCORE-363 > URL: https://issues.jboss.org/browse/WFCORE-363 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha15 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1802: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha15 > > > We need to remove the following block from SecurityRealmResourceDefinition: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > Registration will then be possible within the Elytron subsystem configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1598: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > 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.Alpha15 > > > 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)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1438) Elytron integration with logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1438: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Elytron integration with logging subsystem > ------------------------------------------ > > Key: WFCORE-1438 > URL: https://issues.jboss.org/browse/WFCORE-1438 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha15 > > > This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1533: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Integrate Management Access Control permission assignment with Elytron > ---------------------------------------------------------------------- > > Key: WFCORE-1533 > URL: https://issues.jboss.org/browse/WFCORE-1533 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha15 > > > A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role. > Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection. > This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron. > After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based. > _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha15 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1954) Wrap CLIENT_CERT behaviour of legacy realms with Elytron components.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1954?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1954: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Wrap CLIENT_CERT behaviour of legacy realms with Elytron components. > -------------------------------------------------------------------- > > Key: WFCORE-1954 > URL: https://issues.jboss.org/browse/WFCORE-1954 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha15 > > > An re-enable the following test: - > * org.jboss.as.test.integration.domain.HTTPSManagementInterfaceTestCase -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1944: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha15 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2016