[JBoss JIRA] (WFLY-7991) Legacy Kerberos in management, regression in choosing keytab strategy
by Martin Choma (JIRA)
Martin Choma created WFLY-7991:
----------------------------------
Summary: Legacy Kerberos in management, regression in choosing keytab strategy
Key: WFLY-7991
URL: https://issues.jboss.org/browse/WFLY-7991
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
There is regresion in strategy of choosing keytab described by xsd
{code:xml|title=wildfly-config_5_0.xsd}
<xs:element name="keytab">
<xs:complexType>
<xs:annotation>
<xs:documentation>
Reference to an individual keytab.
On handling the authentication for an incoming request two pieces of information are known, the protocol and the name of the host
this server is acting as. For HTTP requests the protocol will always be HTTP, for requests over Remoting by default the protocol will
be 'remote' although this can be overridden.
At the time authentication is going to be handled the keytab will be selected as follows: -
1 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching protocol/hostname.
2 - Iterate the list of keytabs and identify one where the name of the principal matches matches protocol/hostname.
3 - Iterate the list of keytabs and identity one where the for-hosts attribute contains an entry matching hostname.
4 - Iterate the list of keytabs and identify one where the hostname portion of the principal matches the hostname of the request.
5 - Use the keytab where for-hosts is set to '*'.
If no match is found no keytab will be selected and Kerberos will not be available for communication as that host.
</xs:documentation>
</xs:annotation>
{code}
In this example
{code:xml|title=standalone.xlm}
<security-realm name="PriorityForHostsProtocolBeforePrincipal">
<server-identities>
<kerberos>
<keytab principal="HTTP/localhost.localdomain(a)JBOSS.ORG" path="krb.keytab" for-hosts="wrongprotocol/localhost.localdomain"/>
<keytab principal="HTTP/wronghost(a)JBOSS.ORG" path="krb.keytab" for-hosts="HTTP/localhost.localdomain"/>
</kerberos>
{code}
Rule 1 should be applied, but {{<keytab principal="HTTP/localhost.localdomain(a)JBOSS.ORG" path="krb.keytab" for-hosts="wrongprotocol/localhost.localdomain"/>}} is chosen,
{code:title=server.log}
10:28:40,743 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match.
10:28:40,744 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/localhost.localdomain(a)JBOSS.ORG' for host 'localhost.localdomain'
10:28:40,744 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,745 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,847 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match.
10:28:40,848 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain(a)JBOSS.ORG' for host 'localhost.localdomain'
10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,848 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
10:28:40,849 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
{code}
In this example
{code:xml|title=standalone.xlm}
<security-realm name="PriorityProtocolPrincipalBeforeForHosts">
<server-identities>
<kerberos>
<keytab principal="HTTP/localhost.localdomain(a)JBOSS.ORG" path="krb.keytab" for-hosts="wronghost"/>
<keytab principal="HTTP/wronghost(a)JBOSS.ORG" path="krb.keytab" for-hosts="localhost.localdomain"/>
</kerberos>
{code}
Rule 2 should be applied, but {{<keytab principal="HTTP/wronghost(a)JBOSS.ORG" path="krb.keytab" for-hosts="localhost.localdomain"/>}} is chosen
{code:title=server.log}
10:29:21,889 TRACE [org.jboss.as.domain.management.security] (management task-8) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match.
10:29:21,890 TRACE [org.jboss.as.domain.management.security] (management task-8) Selected KeytabService with principal 'HTTP/wronghost(a)JBOSS.ORG' for host 'localhost.localdomain'
10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,890 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,891 INFO [stdout] (management task-8) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match.
10:29:21,955 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/wronghost(a)JBOSS.ORG' for host 'localhost.localdomain'
10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,957 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,958 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.4426394941284285487.keytab for HTTP/wronghost(a)JBOSS.ORG
10:29:21,959 INFO [stdout] (management task-9) Entered Krb5Context.acceptSecContext with state=STATE_NEW
10:29:21,960 INFO [stdout] (management task-9) Looking for keys for: HTTP/wronghost(a)JBOSS.ORG
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFCORE-2241) Mem Leak in CLI class
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-2241:
--------------------------------------------
Summary: Mem Leak in CLI class
Key: WFCORE-2241
URL: https://issues.jboss.org/browse/WFCORE-2241
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
The CLI class offline CommandContext is never terminated. This makes the CommandContext to be referenced from Shutdown Hook and never cleaned.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JGRP-2155) Weight loss program
by Yves Cuillerdier (JIRA)
[ https://issues.jboss.org/browse/JGRP-2155?page=com.atlassian.jira.plugin.... ]
Yves Cuillerdier commented on JGRP-2155:
----------------------------------------
Hi,
even if it is 2.5mb, i face the problem because Android limits the APK size.
Removing class if not so easy. It is a try & fail tedious process because of the two main configuration files, the class instantiation by reflexion and all the dependencies.
It is not at all a performance concern as i beleave that this point is governed by the protocol exchange.
Another point is related to the security:
I have not look this point deep, but i realized that knowing the connect name is enought to communicate with a JGroups instance. As all protocols are present, it may be easy for anyone to send commands. So i think it is important to limits the class to the minimum needed by the project configuration.
As you still widely use the Annotations i think this may be the easiest way but you can do it as you will.
Anyway, i think that you should move the demo and test packages to comply with maven recommendations.
While i am here, can i ask you to use the sl4j framework and leave the logging choice to the user? This will also save the logging package.
Thanks a lot for your work. It saved me a lot of sweat.
Yves
> Weight loss program
> -------------------
>
> Key: JGRP-2155
> URL: https://issues.jboss.org/browse/JGRP-2155
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Yves Cuillerdier
> Assignee: Bela Ban
>
> JGroups jar is quite large and it is sometime desirable to shrink it some way.
> Currently the jar contains unnecessary class (demo, test and perf) and it is not possible to keep the only needed protocols using tools like Proguard (it's like having a server with all ports open).
> My suggestions are:
> h2. Move JGroups' side class
> Demo: Move the {{demo}} package to a maven module.
> Test and perf: Move the test package to the maven test source and generate test-source jars.
> Note that the {{MPerf$MPerfHeader}} must be removed from the {{jg-magic-map.xml}} file.
> h2.
> h2. Make JGroups Proguard compatible
> A classical way to shrink and optimize project is to use the *{{Proguard }}*tools.
> This tool cannot be used for JGroups mainly because of the two configuration files {{jg-magic-map.xml}} and {{jg-protocol-ids.xml}}.
> These two files contain all class files for all possible protocols, even those that are not required by the selected configuration for the project (for example, using {{fast.xml}} does not require {{ENCRYPT}}, {{TUNNEL}} and many more.)
> The problem is that Proguard could not understand these two files and removes all class because there is no entry points.
> One way to solve this may be to create Annotation (for example {{@MagicMap}} and {{@ProtocolIds}}) and remove the two files. These annotations could be searched by the initialization process in the class maintained by the Proguard tools. This should not affect the loading time as all relevant class are in the same package {{org.jgroups.protocols}}.
> This is not enough because some fields are initialized by reflection using hard coded name (for example "{{bind_add}}"). For such fields we need an Annotation like {{@KeepField}} to tell Proguard not to optimize, remove or rename the fields. For example:
> -keepclassmembers class * { @jgroups.annotations.KeepField <fields>; }
> This Annotation may also be used for class where instance are created by reflection (like {{GMS.GmsHeader}}).
> Last we need to specify the entry points for the project configuration else Proguard will still remove all. The xml configuration files (like {{fast.xml}}) should be kept to provide the protocols configuration.
> This is a matter of the Proguard configuration file. For example in a project using{{ fast.xml}}, we should have:
> -keep public class org.jgroups.protocols.UDP.** { *; }
> -keep public class org.jgroups.protocols.PING.** { *; }
> -keep public class org.jgroups.protocols.MERGE3.** { *; }
> -keep public class org.jgroups.protocols.FD_SOCK.** { *; }
> -keep public class org.jgroups.protocols.FD_ALL.** { *; }
> -keep public class org.jgroups.protocols.VERIFY_SUSPECT.** { *; }
> -keep public class org.jgroups.protocols.BARRIER.** { *; }
> -keep public class org.jgroups.protocols.pbcast.NAKACK2.** { *; }
> ... etc
> My 2 cents.
> Yves
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JGRP-1973) FRAG2: message corruption when thread pools are disabled
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1973?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1973 at 1/30/17 4:19 AM:
---------------------------------------------------------
* Created a reproducer {{FragTest2}}. {{FRAG}} is *not* affected.
* Removing the {{pool instanceof DirectExecutor}} fixes the issue as the packet is copied. IMO it's better to copy here than in {{FRAG2}}.
was (Author: belaban):
* Created a reproducer {{FragTest2}}. {{FRAG}} is *not* affected.
* Removing the {{pool instanceof DirectExecutor}} fixes the issue as the packet is copied. IMO it's better to copy here that in {{FRAG2}}.
> FRAG2: message corruption when thread pools are disabled
> --------------------------------------------------------
>
> Key: JGRP-1973
> URL: https://issues.jboss.org/browse/JGRP-1973
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> When disabling the thread pools (regular, OOB) and using {{UDP}}, fragments of a message get corrupted as a single buffer ({{UDP.receive_buf}}) is reused.
> * If we send a message of 1000 bytes, and {{FRAG2.frag_size}} is set to 600, then {{FRAG2}} sends 2 fragments: f1 (offset=0, length=600) and f2 (offset=600, length=400).
> * f1 is received and placed into {{receive_buf}}, then sent up the stack *without copying* as the {{DirectExecutor}} thread pool doesn't copy the data
> * f1 is received by {{FRAG2}} and added to the fragments list at index 0. The buffer of the message points to {{receive_buf}}
> * f2 is received and *overwrites* f1 in {{receive_buf}} !
> * f2 is received by {{FRAG2}} and added to the fragments list at index 1. The buffer of the message points to {{receive_buf}}
> * {{FRAG2}} now creates a new message whose buffer is {{receive_buf}}[0-600] and {{receive_buf}}[600-1000].
> * The problem here is that {{receive_buf}} contains only f2, which overwrote f1, so the resulting message will be incorrect !
> This probably affects {{FRAG}}, too.
> Not too critical, as thread pools are enabled by default, and disabling them might even be removed in the future.
> SOLUTION: remove the check for DirectExecutor and copy the data if {{copy_buffer}} is true
> {code:title=Bar.java|borderStyle=solid}
> if(!copy_buffer || pool instanceof DirectExecutor)
> pool.execute(new MyHandler(sender, data, offset, length)); // we don't make a copy if we execute on this thread
> else {
> byte[] tmp=new byte[length];
> System.arraycopy(data, offset, tmp, 0, length);
> pool.execute(new MyHandler(sender, tmp, 0, tmp.length));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7989) Legacy Kerberos for management interface returns 500 instead of 401
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7989?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7989:
----------------------------------------
Please keep the affects version blank where the issue is now present in any release but feel free to set the fix version to the next release.
> Legacy Kerberos for management interface returns 500 instead of 401
> -------------------------------------------------------------------
>
> Key: WFLY-7989
> URL: https://issues.jboss.org/browse/WFLY-7989
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case.
> Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages
> {code:title=server.log}
> 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match.
> 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default.
> 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-7989) Legacy Kerberos for management interface returns 500 instead of 401
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7989?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7989:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Legacy Kerberos for management interface returns 500 instead of 401
> -------------------------------------------------------------------
>
> Key: WFLY-7989
> URL: https://issues.jboss.org/browse/WFLY-7989
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case.
> Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages
> {code:title=server.log}
> 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match.
> 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default.
> 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months