[JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties
by Vsevolod Golovanov (JIRA)
Vsevolod Golovanov created WFLY-3931:
----------------------------------------
Summary: Custom formatter property changes not written to, but overriden by logging.properties
Key: WFLY-3931
URL: https://issues.jboss.org/browse/WFLY-3931
Project: WildFly
Issue Type: Bug
Components: Logging
Affects Versions: 8.1.0.Final
Environment: Wildfly 8.1.0.Final
Reporter: Vsevolod Golovanov
Assignee: James Perkins
When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties.
If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties.
For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value.
But with more dynamic properties, e.g. that rely on system properties, it's not so simple...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (SECURITY-863) LogAuditProvider allocates too much
by Philippe Marschall (JIRA)
Philippe Marschall created SECURITY-863:
-------------------------------------------
Summary: LogAuditProvider allocates too much
Key: SECURITY-863
URL: https://issues.jboss.org/browse/SECURITY-863
Project: PicketBox
Issue Type: Patch
Components: JBossSX
Reporter: Philippe Marschall
Assignee: Stefan Guilhen
{{LogAuditProvider}} always logs the {{AuditEvent}} even if audit logging is disabled. This means the {{AuditEvent}} is always converted to a {{String}} even if the trace log level is disabled. The profiled our application and this causes a lot of allocations outside of TLABs for us even though we have audit logging disabled.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFCORE-94:
-----------------------------------
Additional work needed:
* Include an update to all the main module.xml files to include a dependency on the security manager module (the external project, not the subsystem module) (with imported services)
* Include a patch to the security manager subsystem to disable the security manager install() that it does
* Wildfly security manager dependency version needs to be updated to one which includes the meta-inf machinery that JBoss Modules requires
> Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
> ---------------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFCORE-94:
------------------------------
Assignee: James Perkins (was: Kabir Khan)
> Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
> ---------------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1067:
-----------------------------------
This is a good writeup, thanks Richard.
I have a few additional comments:
* While usage of SASL without integrity/encryption support might be considered to be "not fully utilizing SASL", I'd like to point out that recent SASL mechanisms such as SCRAM no longer recommend or support encryption in any case, and recommend other options (SSL, channel binding) which provide other, more secure, encryption and integrity mechanisms. Instead modern SASL mechanisms focus on securing the authentication process itself, which (it seems to me) is still well-aligned with the point of using SASL in JGroups, which is to simply cover authentication in a secure, standards-adherent manner. So I recommend not worrying too much about QOP when you're considering the usage of SASL for new applications.
* The Elytron SPI is intended to be able to integrate at a lower level with authentication processes like this one. This means two things:
*# If you elect to use SASL, that integration should be particularly seamless and simple.
*# If you continue to support AUTH, you should have a much easier time acquiring and using credentials.
* In the short term, if you want to make this work *now*, I'd say you should do whatever you have to do to make it work sensibly. No hack is too ugly. :)
* In the medium to long term, please do communicate with the Elytron developers to ensure that any special requirements you have will be met.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 10/2/14 11:56 AM:
---------------------------------------------------------------------
What follows is a proposal for integrating JGroups with Wildfly in the short term, and some comments on what to do in the longer term. These comments are based on discussions with Bela and the clustering group (all confessed security non-experts). I'd also appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and the implementations do not make use of "modern" security mechanisms such as callbacks and SSLContexts for obtaining authentication information and setting up encrypted channels
- the SASL protocol is standards-based but does not implement the standard fully; support for Quality of Protection in a multicast environment is not provided, and so is a not a complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come up to standard with "modern" security, might be an desirable improvement on the current situation. The SASL layer could have QoP added in the form of multicast-friendly encryption, based on the modern security mechanisms referred to earlier, in a pared down, clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified in security realms. Achieving this through direct use of security realms is not easy as AUTH and ENCRYPT require access to security information in a form which is hidden by the SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make use of callbacks). SASL in its current form can be configured for authentication using the security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of work; a much simper option is to bypass the security realm interface and read the file information from the security realm model itself (i.e. obtaining the keystore and truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate between the OptionsMap, Callbacks and SSLContext which Remoting expects and the OptionsMap, Callbacks and SSLContext which the security realm provides. This interface will probably not change as it is based on an agreed set of "modern" mechanisms. A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described in a previous post, and get the required security configuration information as described above (from the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a more modern implementation as the JGroups protocols are refactored and as Elytron becomes more widely used.
Feedback appreciated.
was (Author: rachmato):
What follows is a proposal for integrating JGroups with Wildfly in the short term, and some comments on what to do in the longer term. These comments are based on discussions with Bela and the clustering group (all confessed security non-experts). I'd also appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and the implementations do not make use of "modern" security mechanisms such as callbacks and SSLContexts for obtaining authentication information and setting up encrypted channels
- the SASL protocol is standards-based but does not implement the standard fully; support for Quality of Protection in a multicast environment is not provided, and so is a not a complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come up to standard with "modern" security, might be an desirable improvement on the current situation. The SASL layer could have QoP added in the form of multicast-friendly encryption, based on the modern security mechanisms referred to earlier, in a pared down, clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified in security realms. Achieving this through direct use of security realms is not easy as AUTH and ENCRYPT require access to security information in a form which is hidden by the SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make use of callbacks). SASL in its current form can be configured for authentication using the security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of work; a much simper option is to bypass the security realm interface and read the file information from the security realm model itself (i.e. obtaining the keystore and truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate between the OptionsMap, Callbacks and SSLContext which Remoting expects and the OptionsMap, Callbacks and SSLContext which the security realm provides. This interface will probably not change as it is based on an agreed set of "modern" mechanisms. A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described above, and get the required security configuration information as described above (from the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a more modern implementation as the JGroups protocols are refactored and as Elytron becomes more widely used.
Feedback appreciated.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3928) JBossSecuritySubjectFactory throws NullPointerException during JBoss shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3928?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3928:
----------------------------------------
I did some very preliminary poking around that I'll paste here in case it saves someone some time. Plus it has a question that [~raggz] hopefully can answer:
My *guess* is it's missing dependency problem.
If you turn on TRACE logging for category org.jboss.as.security, do you see logging like this:
"Exception getting AuthenticationManager for domain=<thesecuritydomain>" ?
This would be coming from [1].
If I'm right though you'll need input from someone more familiar with wiring up security domain dependencies to get feedback on what to do to fix the problem.
[1] https://github.com/jbossas/jboss-eap/blob/6.x/security/subsystem/src/main...
> JBossSecuritySubjectFactory throws NullPointerException during JBoss shutdown
> -----------------------------------------------------------------------------
>
> Key: WFLY-3928
> URL: https://issues.jboss.org/browse/WFLY-3928
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Environment: JBoss EAP 6.3
> Reporter: Tom Ross
> Assignee: Darran Lofthouse
>
> During JBoss shutdown we can see the following exception:
> {noformat}
> 2014-09-22 16:23:51,193 ERROR [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000903: Error creating Subject for crash recovery: java:/xa-resource-adapter/XAQueueConnectionFactory (null): java.lang.NullPointerException
> at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:83)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl$1.run(XAResourceRecoveryImpl.java:300)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl$1.run(XAResourceRecoveryImpl.java:261)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getSubject(XAResourceRecoveryImpl.java:260)
> at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:165)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------
What follows is a proposal for integrating JGroups with Wildfly in the short term, and some comments on what to do in the longer term. These comments are based on discussions with Bela and the clustering group (all confessed security non-experts). I'd also appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and the implementations do not make use of "modern" security mechanisms such as callbacks and SSLContexts for obtaining authentication information and setting up encrypted channels
- the SASL protocol is standards-based but does not implement the standard fully; support for Quality of Protection in a multicast environment is not provided, and so is a not a complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come up to standard with "modern" security, might be an desirable improvement on the current situation. The SASL layer could have QoP added in the form of multicast-friendly encryption, based on the modern security mechanisms referred to earlier, in a pared down, clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified in security realms. Achieving this through direct use of security realms is not easy as AUTH and ENCRYPT require access to security information in a form which is hidden by the SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make use of callbacks). SASL in its current form can be configured for authentication using the security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of work; a much simper option is to bypass the security realm interface and read the file information from the security realm model itself (i.e. obtaining the keystore and truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate between the OptionsMap, Callbacks and SSLContext which Remoting expects and the OptionsMap, Callbacks and SSLContext which the security realm provides. This interface will probably not change as it is based on an agreed set of "modern" mechanisms. A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described above, and get the required security configuration information as described above (from the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a more modern implementation as the JGroups protocols are refactored and as Elytron becomes more widely used.
Feedback appreciated.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months