Java error after enforcing selinux

vinmansbrew · 05-04-2022, 12:14 PM

rhel 7.9

Receiving a battery of errors, possibly java related, after enforcing selinux. I am wondering which boolean might be affecting this. It might help that only the users that do NOT have a home directory, seem to have this issue. The server is using PAM, and so the users are just added to the required groups. Local users, don't have an issue.

Code:

java.io.IOException: Server returned HTTP response code: 403 for URL
at sun.net.(Unknown Source)
                at sun.net.(Unknown Source)
                at java.net.URL.openStream(Unknown Source)
                at com.appworx.client.screen.logon.C.ľ(Logon.java:360)
                at com.appworx.client.screen.logon.C.f(Logon.java:649)
                at com.appworx.client.screen.logon.C.h(Logon.java:500)
                at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
                at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
                at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
                at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
                at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
                at java.awt.Component.processMouseEvent(Unknown Source)
                at javax.swing.JComponent.processMouseEvent(Unknown Source)
                at java.awt.Component.processEvent(Unknown Source)
                at java.awt.Container.processEvent(Unknown Source)
                at java.awt.Component.dispatchEventImpl(Unknown Source)
                at java.awt.Container.dispatchEventImpl(Unknown Source)
                at java.awt.Component.dispatchEvent(Unknown Source)
                at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
                at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
                at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
                at java.awt.Container.dispatchEventImpl(Unknown Source)
                at java.awt.Window.dispatchEventImpl(Unknown Source)
                at java.awt.Component.dispatchEvent(Unknown Source)
                at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
                at java.awt.EventQueue.access$500(Unknown Source)
                at java.awt.EventQueue$3.run(Unknown Source)
                at java.awt.EventQueue$3.run(Unknown Source)
                at java.security.AccessController.doPrivileged(Native Method)
                at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
                at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
                at java.awt.EventQueue$4.run(Unknown Source)
                at java.awt.EventQueue$4.run(Unknown Source)
                at java.security.AccessController.doPrivileged(Native Method)
                at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
                at java.awt.EventQueue.dispatchEvent(Unknown Source)
                at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
                at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
                at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
                at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
                at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
                at java.awt.EventDispatchThread.run(Unknown Source)

boughtonp · 05-04-2022, 12:29 PM

You need to use "[code]..[/code]" to preserve formatting and prevent LQ from thinking the error message contains a URL!

Does "com.appworx.client.screen.logon.C.l(Logon.java:360)" reference your code or some software that is installed?

Given the single-letter stuff I'm assuming the latter (and that its obfuscated), but the problem is that whatever is on line 360 of Login.java is making a HTTP request and receiving a "forbidden" response.

So either the client software is not sending correct authentication information and/or the server is not receiving or understanding the details being sent.

I don't know whether its SELinux related or a coincidental bug. If it's not your software, are there any log files being produced that state where the request is being made to (i.e. is it a local server or a remote one)?

If you can somehow log/intercept the HTTP traffic for a working user and a non-working user, comparing two equivalent requests/responses may reveal more information about what is going on.

vinmansbrew · 05-04-2022, 01:26 PM

This is the error message as it was sent to me, so formatting is what it is. I could ask for it again, but I'd likely just get it the same way. Logins work just fine without selinux enforcing. With it enforcing, that's when logins fail. For the 1 person that can log in, he has a home directory, the rest do not. And the software works fine, for him. So, the issue happens once selinux is enforcing, permissive is fine. I tried to set 1 of the users as an selinux user, but the error remains.
So, it appears to be an interaction between selinux, the login process, and the user not having a home directory. If it helps, it's a program called Automic, from Ellucian. There is a ticket in with them, as well, but responses can be slow sometimes.
Audit logs do not seem to reveal a particular error. I am in process of checking program logs.

boughtonp · 05-04-2022, 01:56 PM

Quote:

Originally Posted by vinmansbrew

This is the error message as it was sent to me, so formatting is what it is.

No.

Go look carefully at your post, then press the edit button and look at it again.

As stated, you need to wrap the error in "[code]..[/code]" to both preserve formatting and to prevent LQ from changing "at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)" into "at sun.net.http://www.protocol.http.HttpURLConn...tream0(Unknown Source)"

(You will also need to remove the automatically-inserted [url] tags.)

Quote:

Logins work just fine without selinux enforcing. With it enforcing, that's when logins fail.

Then as I already suggested, SELinux is either:
1) causing the client to send a different HTTP request than it otherwise would
2) modifying the request after it leaves the client and before it reaches the server
3) triggering a bug/behaviour in the server which prevents it from responding to a legitimate request (or even intercepting the request before it gets there)

A search for "selinux http 403" reveals plenty of requests that suggest it may be the third of those options.

Solutions vary - there appears to be no single fix - so you need to do that search and read through the results to determine which one is appropriate in your case.

Unless someone here happens to have used Automic with SELinux before, it's unlikely anyone here is going to know what specific setting is relevant.

vinmansbrew · 05-04-2022, 02:02 PM

That's why I am just wondering if anyone has run into a boolean that has affected either java, or pam modules. I wouldn't expect there to be many automic users here.

zeebra · 05-16-2022, 07:05 AM

Quote:

Originally Posted by boughtonp

Unless someone here happens to have used Automic with SELinux before, it's unlikely anyone here is going to know what specific setting is relevant.

There are many reasons and ways SELinux could block and cause these things. When writing policy, you probably try to keep it as narrow(but general) as possible. But you can't account for all possible situations.

As far as I understand, RHEL uses targeted policies, and as I understand that means it targets specific things and leaves the rest non-enforced, as oppose to enforcing the whole OS and everything. Which means they must be enforcing whatever scenario TS is experiencing.

In my opinion, it would be best to send this information to RedHat so they can if need be improve their SELinux policy. Even better, you could adjust SELinux policies yourself and send both the problem and solution (and problem background info) to RedHat.