openj9
openj9 copied to clipboard
eclipse-openj9
Customers do not like that the Attach API is enabled by default on Windows, AIX, and Linux.
Customers do not like that the Attach API is enabled by default on Windows, AIX, and Linux. (The Attach API is not enabled by default on z/OS.)
The customer doesn't like that /tmp/.com_ibm_tools_attach create files with world writeable files.
The customer provided this feedback: "Our GIS team is asking if there is no legitimate use for this without the AttachAPI usage, then why is it being enabled by default at all? As long as these files are being created by any Java command or process, there will be the perception that they will be vulnerable to attacks such as these without very detailed monitoring in place to look for more than the empty control files. Why put all of these teams through getting some monitoring solution in place when this can just be disabled by default and development teams can enable it easy enough as it is needed?"
This customer is on Linux with 1000's of Java processes spread over 100s of hosts and to completely disable the Attach API, they have to add -Dcom.ibm.tools.attach.enable=no to the two options.default files every time they install Java or upgrade Java.
Why put all of these teams through getting some monitoring solution in place when this can just be disabled by default and development teams can enable it easy enough as it is needed?
There are other application/tools requiring the Attach API enabled by default.
As long as these files are being created by any Java command or process, there will be the perception that they will be vulnerable to attacks such as these without very detailed monitoring in place to look for more than the empty control files.
The files in question are not consider a security risk at Windows/AIX/Linux [1].
[1] https://www.eclipse.org/openj9/docs/attachapi/
@JasonFengJ9 what is the impact of removing the world writable permission from the files?
The request here seems to be for IBM Java 8 (which doesn't provide tools like jcmd), this isn't the right place to raise the concern.
It's also possible to put -Dcom.ibm.tools.attach.enable=no in an environment variable. The machines can be modified to have the environment variable set and it will impact all installations of Java.
See item 4 & 6 under Precedence in https://www.eclipse.org/openj9/docs/cmdline_specifying/
what is the impact of removing the world writable permission from the files?
Attach API requires such permission to lock a file. https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileChannel.html#lock--
public final [FileLock](https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileLock.html) lock()
throws [IOException](https://docs.oracle.com/javase/8/docs/api/java/io/IOException.html)
Acquires an exclusive lock on this channel's file.
Returns:
A lock object representing the newly-acquired lock
Throws:
[NonWritableChannelException](https://docs.oracle.com/javase/8/docs/api/java/nio/channels/NonWritableChannelException.html) - If this channel was not opened for writing
The request here seems to be for IBM Java 8 (which doesn't provide tools like jcmd), this isn't the right place to raise the concern.
Yes, there were some internal slack discussion a while ago. @Tom-Poe internal skill case or RTC workitem are the alternative places.
Attach API requires such permission to lock a file.
It requires user write permission, does it need world (or even group) write permission?
does it need world (or even group) write permission?
Attach API supports Java processes created by other user/group as long as they have write permission on the files in question.
You can only attach to JVMs created by the same user. It seems there are some files used for global locks and notifications. Given the previous restriction, maybe we can get rid of them.
You can only attach to JVMs created by the same user.
Is there a doc/link about this restriction? There was a use case specifically for different users https://github.com/eclipse-openj9/openj9/issues/13571
Is there a doc/link about this restriction?
It's how attach API security works. In https://www.eclipse.org/openj9/docs/attachapi/ you can find "A process using the Java Attach API must be owned by the same UNIX user ID as the target process."
How about root (privilege user) can attach less privilege user, but not vice versa?
How about root (privilege user) can attach less privilege user, but not vice versa?
World permissions aren't needed for that to work since root can write to all files.
When there are java processes from different privilege group involved, they require write permission to lock the global files even though the less privilege processes can't actually attach those privilege ones.
To remove that write permission requirement, global locking mechanism has to be changed.
Using Linux as an example platform, .com_ibm_tools_attach by default is within /tmp which has world permission itself, and apparently might contain other directories w/ similar permissions.
A question for @Tom-Poe , how does the user categorize those files & directories?
To remove that write permission requirement, global locking mechanism has to be changed.
Ya. Even the per JVM notification sync files are world writable, since attaching to a single JVM locks the sync file of every JVM running, in order to throttle notifications and ensure the target JVM is notified. We should re-do the notification mechanism.
The customer doesn't like that /tmp/.com_ibm_tools_attach create files with world writeable files.
The world writable permission can be removed, this implies that only group users along with root/administrator can use AttachAPI, which is close to current doc "A process using the Java Attach API must be owned by the same UNIX user ID as the target process.".
@Tom-Poe can you check with the client if that satisfies them w/o disabling AttachAPI by default?
The world writable permission can be removed
I don't expect that will work. It will break attach API notification if multiple users are running JVMs.
It will break attach API notification if multiple users are running JVMs.
If the users are in same group, they can work as before.
@Tom-Poe
-
On UNIX systems, the Attach API mechanism (by default) uses /tmp folder and creates a common subdirectory under it named “.com_ibm_tools_attach” - file permissions for the folder being “drwxrwxrwx” with sticky bit being set. The sticky bit on a directory prevents files in a world-writable directory from being deleted or renamed by anyone except the owner of the file or root user, however any other user can create files in that directory though. Security in this case is handled by POSIX file permissions.
-
/tmp/.com_ibm_tools_attach directory is made world writeable to enable the use case of Attach API communication for various users in the system (with a common ".com_ibm_tools_attach" root folder). However Users can only initiate Attach API communication to the JVMs they started and not to the JVMs running in the system owned by other users. This security is provided by JVM itself.
-
Confirmed with Security SPOC, there are no known security vulnerabilities as on date w.r.t Attach API mechanism.
My customer has stopped replying to my updates in his case. I've provided 2 work arounds to this issue, but I've not heard from the customer since May 31st 2022 so I'm closing this issue.