I have to check whether someone started my Java application over the network or not, so that I can shut down the application if it was started from another machine.
The solution has to work on Windows and Linux.
I guess interpreting the current working directory might be a starting point, but I have no idea with Java-class; provide me the feature I need.
Why? If it's for security reasons then you probably are out-of-luck. If the attacker can create a process on your machine, then (s)he will be able to create a process with whatever environmental properties your program checks to decide whether the "user" is remote or local.
If it's for security reasons, then you should be trying to prevent the attacker from communicating with the machine at all.
If it's for some other purpose, then you haven't really provided enough information. What kind of "application?" How does a local user normally start it? How would a remote user try to start it? etc.
Related
Okay, I realize this might not be possible ...
I have a device that runs linux, and it will likely not have a user interface that is visible. It will have a USB port that is open ... I want to be able to write java to allow the overall system to detect when a device is plugged into the USB port and then mount the device.
I know how to do this from a command line, but it requires "sudo" to fork a new process with elevated privilege to perform the task. I don't know how to write a java program that can get around (yes, I want to get around) the security protection of mount.
runtime.exec() doesn't really do what I am hoping to accomplish. Is this a "can't be done in Java" problem?
I'm hoping to do this without resorting to external executable code.
You can't get around the security protection of mount. The protection is not in mount. The protection is in the kernel.
If by chance you find a way and publish it, it will get removed.
If you have control of the OS you are running on, you can add the option user to the mountpoint in /etc/fstab. After doing so, "mount /path" and "umount /path" work from runtime.exec() without elevation. mount and umount are setuid-root to allow this to work.
File mounts are controlled by the host operating system. So controlling mounts is done through system calls. You seem to be using a Unix operating system, so that means the system call interface is C. So you could use JNI to call a small C function that makes the system call needed.
But all such matters are system dependent, and privileged operations. So that approach creates portability and security problems. So you might do better to reconsider why your program itself must do this, rather than letting a control component (such as systemd) do it for you.
I need to programmatically edit, write or delete protected files. In Windows, if i do it manually, it asks for permission and in Unix systems i need "sudo".
How can I ask in Java for higher privileges during execution?
If your program requires high level access it is best to advise the user that they need to run it as root / a privileged account in order to work.
Otherwise the best option is to start a new 'proxy process' that is initialised using "sudo" and then a program doing what you want, eg "sudo cp File1 File2" that will perform your dirty work for you.
Unfortunately this is not cross platform and requires the users password.
There is simply no way you can just bump the JVM to a higher user during execution as this would pose a huge security risk.
md_5
Because Java works using a virtual machine, you can't just start (for example) another thread in an elevated mode. Instead, you'll need to launch an entirely new VM, which you won't be able to connect to.
I'd look into ways of executing a separate Java process which can run with elevated permissions. You can still use the same code, but have it be a main method.
You won't be able to just raise your privillages.
I might be entirely wrong, and am happy to be shown otherwise.
Someone can tell me the best way, through a web Java application, how to run an application on a remote machine (linux) and how to know if this application has already completed. I know the application terminates automatically, so just wanted to wait for the answer.
any help or advice are very welcome.
I was confused by the wording, so I will assume the following: the web application and the remote application are running on two different machines, with the remote application on Linux.
If that is the case, then you would be better off using a SSH library for Java (there are several - JSch, sshj, Ganymed SSH-2, to connect to the remote machine and run commands on it. This is a better approach than using ProcessBuilder, for it abstracts you from the problem of providing your password to the terminal (which can get quite tricky).
I'm not sure what you meant by this statement: "I know the application terminates automatically, so just wanted to wait for the answer." so I'll make another assumption that you want to know if the remote process terminated successfully or not. I'm unsure if any of the SSH libraries posted above, will allow you to get the remote process status in a non-trivial way, so you are better off writing a shell wrapper to your remote command that will return a parseable message.
If you are running both on the same machine, use ProcessBuilder.
I wanted to get ideas from the SO community about this issue.
Here is the problem:
We have a user on the other side of the world launching our app through WebStart. The user, however, is complaining that her whole application freezes up and becomes unresponsive. Usually, the client is doing a lot of database queries to a distributed database.
Questions:
If we ask her to do a CTRL-Break on her application, where would the JVM write the stack trace to?
Would it be enough just to use JConsole?
Would implementing JMX beans on the client be overkill? Would it actually help in troubleshooting issues in production?
Right now the users are running on JRE 1.5.0-b08, but we do plan on migrating to JRE 6 in a couple of months.
What do you think?
José, you can get a lot of information from the JVM in a number of ways.
The best might be to enable debugging in the remote JVM. You can set them using the j2se element in the descriptor XML, as shown here. Since you can set -Xdebug you have a good start; I've never tried to do remote debugging on a web start app, so it may be a little bit of an issue setting up the remote part.
You could also set some things up yourself by adding a separate thread to talk to you remotely and send debugging messages.
You could use a native java or log4j remote logger.
If it's hanging the way you describe, though, the odds are very high that what's happening is a network hangup of some sort. Can you put some tracing/debugging onto your end of the conversation?
Instead of these debugging suggestions, why don't you install an exception handler for your threads? See java.lang.Thread.
void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Here's the relevant javadoc:
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)
If you install that in your code, and once inside Swing's EDT, then just write some java code to e-mail it to yourself, save it on a server, show it to the user, etc.
You need to have the Java Console displayed (run javaws from the command line, and select this from the Preferences dialog), then hit "v"
We have a Java program run as root on Unix, that therefore can read for example the content of the folders /home/user1 and /home/user2. However, if the Unix user "user1" is logged in in our application, he should not be able to access "/home/user2" data.
We would like to use directly the Unix rights and not recreate all the permissions in our application !
So, could we...
try to change the UID of our
program depending on the user logged
in ? Sounds difficult, and each file
access is in different threads so
the UID would be different on each
thread of our program...
use JNI to read permissions of
"/home/user2"...And then determine
if user1 has sufficient permissions
on "/home/user2" ? (how ?).
Use SecurityManager!
Put current unix user id into ThreadLocal
Create your own SecurityManager that checks unix user permissions on checkRead() and checkWrite()
System.setSecurityManager(new MySecurityManager())
Enjoy
Update
There is no, of course, standard library to read unix file permissions. It's not WORA.
But I have tried briefly to find a ready to use library, and found this one:
http://jan.newmarch.name/java/posix/ It uses JNI, but you don't need to write your own JNI code, which is a big relief. :) I'm sure there must also be others.
Class Stat from there gives you all required access information:
http://jan.newmarch.name/java/posix/posix.Stat.html
Update 2
As folks mentioned, this approach fails to check for "non-standard" unix security features, such as ACL or Posix Capabilities (may be; not sure if they apply to files). But if the goal of being totally in sync with host OS security is set, then we even more need to use SecurityManager, because it's a JVM-wide protection mechanism! Yes, we can start a child SUID-process to verify the permissions (and keep it running, talking to it via pipe running while the user is logged in), but we need to do so from SecurityManager!
The simplest and most portable way would be to spawn a child process, have it exec a wrapper written in C which changes the UID, drops all the privileges (be careful, writting a wrapper to do that is tricky - it is as hard as writing a setuid wrapper), and execs another java instance to which you talk via RMI. That java instance would do all the filesystem manipulation on behalf of the user.
For single-threaded Linux programs, you could instead use setfsuid()/setfsgid(), but that is not an option for portable or multithreaded programs.
if you only want the app to be allowed to read files by user1 i strongly suggest the app runs as user1.
If everything else fails, you can run a shellscript from java and parse the result.
Described for example here
For those who were wondering, it's apparently not possible to do this by calling setuid with JNI for each independent thread. setuid affects the whole process, not just the thread that invoked it.
Should you want to call setuid within a single-threaded Java program there's a good example at http://www2.sys-con.com/itsg/virtualcd/Java/archives/0510/Silverman/index.html.
Another option would be to invert the approach: instead of the code running as root most of the time and either changing the user ID or somehow checking the permissions whenever it has to use some restricted resource, run as the user most of the time and talk to a smaller daemon running as root when it needs to do something only root can do. This also has the added benefit of reducing the attack surface.
Of course, you then have to authenticate the connection from the process running as the user to the process running as root.
I am also having the exact problem as Mikael, and got to this page looking for answers.
None of the answers are 100% satisfactionary for me. So I am thinking of 4 alternatives:
Use a Linux group that has access to all the users. Run a single Java app under that group. This Java app can communicate to the 'root' app using whatever means.
Potentially, it can be "hotel"-ed. e.g. 1 "hotel" (app with group permissions) per 100 users (or as appropriate). So if you have 10,000 users you need 100 hotels, which is quite manageable.
Spawn a JVM for each child app under its own user ID. This is like calling a script, but rather than using stdin/stdio/stderr, use any communication protocol. In my case, I'm using XMPP and IO Data (which, since it's already in use by other components, it doesn't matter "where" aka which JVM it runs).
Create a Super-Server 'root' app. This can be part of the original 'root' app or a separate service dedicated to service management.
The Super-Server is responsible for handling incoming requests (i.e. it practically becomes a reverse proxy) for the user-specific sub-apps, and launching the real child apps (if they're not running already), and passing messages back and forth between the client and the child app(s).
Additionally, the child apps can be pooled (or even "passivated", if there's such thing), much in the way Java EE EJB Container does it. So even if there are 10,000 users and (potentially) 10,000 child apps servicing, the maximum number of child apps running are capped. Idle apps are shut down to make room for others.
Same as #3 but rather than creating a proprietary service management mechanism, integrate with Upstart (or the service management framework in the underlying OS). i.e. there is a 'root' service that can control Upstart. Upstart can start, stop, restart, can query the status of the child services, just like it can control mysqld, Apache, etc.
For me, now, the quickest and simplest to implement would be #1. However, my ideal solution would be #4, but it will take time and testing whether it works well. (the concept itself borrows from inetd/xinetd and EJB, so I think it's pretty sound fundamentally)