Re: getting "BindException: permission denied" exception when trying to change port 8080 to 8090

[Coty Sutherland]

On Tue, Dec 26, 2017 at 8:12 AM, Alceu R. de Freitas Jr.
 wrote:
>  Hello Coty,
> For the sake of others readers, I confirm the behavior you identified from 
> SELinux:

Great, thanks.

> [root@localhost audit]# grep -P '^type=AVC' audit.log | grep name_bind
> type=AVC msg=audit(1513876523.918:145): avc:  denied  { name_bind } for  
> pid=10420 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513876981.747:148): avc:  denied  { name_bind } for  
> pid=10726 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513877805.970:135): avc:  denied  { name_bind } for  
> pid=2376 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513877965.612:138): avc:  denied  { name_bind } for  
> pid=2442 comm="java" src=9090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:websm_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513878056.773:141): avc:  denied  { name_bind } for  
> pid=2512 comm="java" src=1 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513878361.650:185): avc:  denied  { name_bind } for  
> pid=2609 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513878699.852:190): avc:  denied  { name_bind } for  
> pid=2714 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513878900.757:193): avc:  denied  { name_bind } for  
> pid=2803 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513879083.533:196): avc:  denied  { name_bind } for  
> pid=2870 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513879865.598:216): avc:  denied  { name_bind } for  
> pid=3480 comm="java" src=8090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513885200.245:233): avc:  denied  { name_bind } for  
> pid=4385 comm="java" src=9090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:websm_port_t:s0 tclass=tcp_socket
> type=AVC msg=audit(1513964943.996:108): avc:  denied  { name_bind } for  
> pid=1808 comm="java" src=9090 scontext=system_u:system_r:tomcat_t:s0 
> tcontext=system_u:object_r:websm_port_t:s0 tclass=tcp_socket
> [root@localhost audit]#
>
> Since I'm not acquainted with SELinux, I read some introductory documentation 
> about, so I'm guessing here that the proper way to allow a different port 
> (8090 in your sample of semanage) to be used by Tomcat would be:
> semanage port --add -t initrc_t -p tcp 8090

If that works, sure :)

>
> Since the running process of Tomcat is not related to http_port_t:

I'm not sure what you mean by 'is not related to', but tomcat is
related to http_port_t because it's allowed name_bind and name_connect
by the default system policy:

~~~
# sesearch -t http_port_t -AC | grep tomcat
   allow tomcat_domain http_port_t : tcp_socket { name_bind name_connect } ;
~~~

> [root@localhost audit]# ps auxZ | grep -v grep | grep -i jenkins
> system_u:system_r:initrc_t:s0   jenkins   1255  3.0 27.0 2417080 274544 ? 
>  Ssl  10:34   0:51 /etc/alternatives/java -Dcom.sun.akuma.Daemon=daemonized 
> -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
> /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log 
> --webroot=/var/cache/jenkins/war --daemon --httpPort=8090 --debug=5 
> --handlerCountMax=100 --handlerCountMaxIdle=20
>
> Is that right?
> On the other hand, semanage port -l | grep init or semanage port -l | grep 
> 8090 gives me nothing.

You don't see the port in the list because 8090 is not a port that's
in any port type definition by default, hence my suggestion to add it
to a type that tomcat can use. From what you've noted above though
you're not trying to bind tomcat to 8090, you're trying to bind
jenkins to 8090. Is that right?

By the way, you can check what labels any port has with seinfo:

~~~
# seinfo --portcon=8090
portcon tcp 1024-32767 system_u:object_r:unreserved_port_t:s0
portcon udp 1024-32767 system_u:object_r:unreserved_port_t:s0
# seinfo --portcon=8080
portcon tcp 8080 system_u:object_r:http_cache_port_t:s0
portcon tcp 1024-32767 system_u:object_r:unreserved_port_t:s0
portcon udp 1024-32767 system_u:object_r:unreserved_port_t:s0
~~~

Note that a port that works (8080) is labeled http_cache_port_t which
is usable by tomcat_domain 

Re: oauth guidance

[Mark Thomas]

On 02/01/18 00:51, Robert J. Carr wrote:
> I'm looking to use some kind of combined realm where I can authenticate
> (and authorize) users both using the built-in login-config and externally
> using oauth.  Ideally, in both cases, I'd be able to have access to roles,
> but this isn't a necessity.
> 
> You see this sort of thing a lot now, where you have the option to "login
> with google" or "login with facebook" or even login using the site's own
> credentials.
> 
> There seems to be very little information about this out there, though, for
> use in tomcat or java ee.  All queries about oauth and tomcat lead to
> JASPIC.  I found this question, which is nearly my exact situation, and the
> accepted solution there was indeed JASPIC:
> 
> https://stackoverflow.com/questions/39058200/tomcat-realm-for-oauth2
> 
> But I can find almost no examples of how JASPIC works or what it offers
> (beyond the tomcat docs), but only that it is supported in tomcat starting
> with 8.5.  I can use tomcat 8.5, so that isn't a problem, but the only
> example provider seems to be the one for google, and it isn't super clear
> how it all works.

I put that together. It was only ever the bare minimum you needed to to
to integrate with Google OAuth. If you have specific questions this is
the place to ask. If the answers are helpful any suggestions to improve
the docs would be appreciated. Suggestions in the form of patches to the
docs even more so.

The JASPIC spec might be worth a read although it is fairly hard going
in places.

> So I'm just looking for any guidance on what road to start down, given my
> requirements.  It seems I could write my own realm, but then I'm not sure
> how I'd fit in the oauth token flow.  I could use jaspic, but then I'm not
> sure if I'd be able to use the regular security-constraints.  Or I could
> manage all of the auth myself with various filters and sessions, but that
> seems silly given the java ee machinery that's already available.
> 
> Any suggestions?

I'd suggest the JASPIC Realm. You might need to write a custom provider
(or whatever the terminology is) for your local auth. If it is a common
one it could potentially be added to the Tomcat code base.

Feel free to ask questions here as you go.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: internalProxies regex

[Mark Thomas]

On 02/01/18 09:50, Harrie Robins wrote:
> I'm still having problems with matching my pattern.
> 
> Right now I'm feeding the following to internalProxies:
>  
> ^103\\.21\\.(2(4[4-7]))\\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$|^103\\.22\\.(2(0[0-3]))\\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$
> I created a list of all involved IP addresses and matched those IP addresses:
> 
> java.util.regex.Matcher / java.util.regex.Pattern, please see 
> https://pastebin.com/Lija7n9k 
> 
> All addresses from the list I created are matching, just not in tomcat.

What is the value of the remote IP address that is failing to match? You
might want to look at writing a short custom Valve to log that and
insert it into the Pipeline ahead of the RemoteIpValve.

Another option would be to simply remove the RemoteIpValve and write a
simple servlet that logs the remote IP.

Mark

> 
> Regards,
> 
> Harrie
> 
> -Oorspronkelijk bericht-
> Van: Harrie Robins [mailto:har...@eyequestion.nl] 
> Verzonden: 21 December 2017 09:55
> Aan: 'Tomcat Users List' 
> Onderwerp: RE: internalProxies regex
> 
> This makes perfect sense.
> I tested my regex, just against wrong engine.
> 
> Thanks for pointing me in the right direction
> 
> -Oorspronkelijk bericht-
> Van: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> Verzonden: 20 December 2017 15:19
> Aan: Tomcat Users List 
> Onderwerp: Re: internalProxies regex
> 
> 2017-12-20 11:37 GMT+03:00 Harrie Robins :
>> Hello everyone,
>>
>>
>>
>> I have a question about the remoteipvalve in tomcat 8.5:
>> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valve
>> s/Remo
>> teIpValve.html
>>
>>
>>
>>
>> internalProxies
>>
>> Regular expression that matches the IP addresses of internal proxies. 
>> If they appear in the remoteIpHeader value, they will be trusted and 
>> will not appear in the proxiesHeader value
>>
>> RemoteIPInternalProxy
>>
>> Regular expression (in the syntax supported by java.util.regex)
>>
>> 10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|
>> 169\.254\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|
>> 172\.1[6-9]{1}\.\d{1,3}\.\d{1,3}|172\.2[0-9]{1}\.\d{1,3}\.\d{1,3}|
>> 172\.3[0-1]{1}\.\d{1,3}\.\d{1,3}
>> By default, 10/8, 192.168/16, 169.254/16, 127/8 and 172.16/12 are allowed.
>>
>>
>>
>> I need to convert some CIDR ranges to regex:
>>
>>
>> my concern is that /d{1,3} wil match too many (non exist) addresses
>>
>> 103\.21\.24\d[4-7]\.\d[0-9]\d{1,3}|103\.22\.20\d[0-3]\.\d[0-9]\d{1,3}|
>> 103\.3
>> 1\.\d[4-7]\.\d[0-9]\d{1,3}
>>
>>
>>
>> So I re-wrote using capture groups, below does not function however, 
>> and I assume it is due to OR (|) which tomcat will affectively see as a new 
>> entry?
>> So I tried escaping, but I cannot get it to work:
>>
>> 103\.21\.(2(4[4-7]))\.([0-9]\|[1-9][0-9]\|1([0-9][0-9])\|2([0-4][0-9]\
>> |5[0-5
>> ]))|103\.22\.(2(0[0-3]))\.([0-9]\|[1-9][0-9]\|1([0-9][0-9])\|2([0-4][0
>> -9]\|5
>> [0-5]))
> 
> Your assumption that "tomcat will affectively see as a new entry" is wrong.
> The string is used as whole to initialize a java.util.regex.Pattern().
> Tomcat does not split it.
> 
> You may write a simple program / junit test to test how
> java.util.regex.Pattern() processes your value.  Or you may run Tomcat with 
> debugger,
> 
> https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
> https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario
> 
> AFAIK, '\|' in a regular expression will be interpreted as expecting literal 
> '|' character in the matched string.  No IP address has this character so 
> none will match.
> 
> 
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is it Normal for Tomcat 8 to Use 20-80% More Memory Than Tomcat 6?

[Mark Thomas]

On 28/12/17 10:06, Olaf Kock wrote:
> 
> On 27.12.2017 23:16, Eric Robinson wrote:
>>> I mean A is java8 and tomcat8.. so make a C that is tomcat6 and java8
>> I don't think so. This is a requirement of the software company whose
>> application solution we use. They are requiring us to move to tomcat 8
>> with jdk 1.8. If we try to mix tomcat8 with jdk 1.6, supposedly we
>> would have problems. I guess all this is being driven by the need to
>> switch to TLS 1.2. I'm not sure if that would be a function of tomcat
>> or java.
> As you were looking for the reason of the increased footprint, this
> would help you tremendously to get to the root cause, even if you don't
> intend to use it in production. Assume that a similar behavior already
> appears when you run tomcat6 with Java8 - in this case there might be
> little reason to continue to dig in tomcat, and assume that it's the
> Java implementation that caused your increased footprint.
> 
> Tomcat 8 with Java 6 won't work (apart from the outdated implementation)
> as it requires at least Java7 (which is also outdated).
> 
> And then there's yet another aspect: The memory footprint increased way
> below the price decrease for memory, so just adding this much memory
> could be filed away as a reasonable assumption within 7.5 years (JDK
> 1.6.21 was released July 2010, I'm assuming that this is the age of the
> hardware as well (because why would you have installed this version on
> newer hardware, when newer releases existed)
> 
> I'm assuming that you have enough aspects to inspect - if you're really
> interested in finding the root cause, you'll need to come up with more
> specific measurements, e.g. profiler data, compare thread dumps and set
> up Tomcat 6 with Java 8 to have a third reference point.

I don't have Tomcat 6 to hand but I do have Tomcat 7. A quick test with
Tomcat 7 + Java 6 vs Tomcat 7 + Java 8 I saw a 20% increase in memory usage.

This looks very much like changes in the JVM rather than changes in Tomcat.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: internalProxies regex

[Harrie Robins]

I'm still having problems with matching my pattern.

Right now I'm feeding the following to internalProxies:
 
^103\\.21\\.(2(4[4-7]))\\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$|^103\\.22\\.(2(0[0-3]))\\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$
I created a list of all involved IP addresses and matched those IP addresses:

java.util.regex.Matcher / java.util.regex.Pattern, please see 
https://pastebin.com/Lija7n9k 

All addresses from the list I created are matching, just not in tomcat.

Regards,

Harrie

-Oorspronkelijk bericht-
Van: Harrie Robins [mailto:har...@eyequestion.nl] 
Verzonden: 21 December 2017 09:55
Aan: 'Tomcat Users List' 
Onderwerp: RE: internalProxies regex

This makes perfect sense.
I tested my regex, just against wrong engine.

Thanks for pointing me in the right direction

-Oorspronkelijk bericht-
Van: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Verzonden: 20 December 2017 15:19
Aan: Tomcat Users List 
Onderwerp: Re: internalProxies regex

2017-12-20 11:37 GMT+03:00 Harrie Robins :
> Hello everyone,
>
>
>
> I have a question about the remoteipvalve in tomcat 8.5:
> https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valve
> s/Remo
> teIpValve.html
>
>
>
>
> internalProxies
>
> Regular expression that matches the IP addresses of internal proxies. 
> If they appear in the remoteIpHeader value, they will be trusted and 
> will not appear in the proxiesHeader value
>
> RemoteIPInternalProxy
>
> Regular expression (in the syntax supported by java.util.regex)
>
> 10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|
> 169\.254\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|
> 172\.1[6-9]{1}\.\d{1,3}\.\d{1,3}|172\.2[0-9]{1}\.\d{1,3}\.\d{1,3}|
> 172\.3[0-1]{1}\.\d{1,3}\.\d{1,3}
> By default, 10/8, 192.168/16, 169.254/16, 127/8 and 172.16/12 are allowed.
>
>
>
> I need to convert some CIDR ranges to regex:
>
>
> my concern is that /d{1,3} wil match too many (non exist) addresses
>
> 103\.21\.24\d[4-7]\.\d[0-9]\d{1,3}|103\.22\.20\d[0-3]\.\d[0-9]\d{1,3}|
> 103\.3
> 1\.\d[4-7]\.\d[0-9]\d{1,3}
>
>
>
> So I re-wrote using capture groups, below does not function however, 
> and I assume it is due to OR (|) which tomcat will affectively see as a new 
> entry?
> So I tried escaping, but I cannot get it to work:
>
> 103\.21\.(2(4[4-7]))\.([0-9]\|[1-9][0-9]\|1([0-9][0-9])\|2([0-4][0-9]\
> |5[0-5
> ]))|103\.22\.(2(0[0-3]))\.([0-9]\|[1-9][0-9]\|1([0-9][0-9])\|2([0-4][0
> -9]\|5
> [0-5]))

Your assumption that "tomcat will affectively see as a new entry" is wrong.
The string is used as whole to initialize a java.util.regex.Pattern().
Tomcat does not split it.

You may write a simple program / junit test to test how
java.util.regex.Pattern() processes your value.  Or you may run Tomcat with 
debugger,

https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

AFAIK, '\|' in a regular expression will be interpreted as expecting literal 
'|' character in the matched string.  No IP address has this character so none 
will match.



Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org