I'm writing a Java ME app that will use privileged operations such as messaging. By default the user is prompted to confirm each of these operations, but I would like to run it as a background service.
Documentation says to request permission in the jad file, I have done so and presume it will work on a device. However I would like to test this on the Netbeans mobility emulator first.
I tried signing the app as "trusted" but my emulated execution still prompts the user for permission.
The MIDP security model needs to be explained in 2 parts:
The phone (or the emulator) contains a security policy.
The security policy is made of several domains.
each domain defines function groups and root certificates.
a function group decides which protection options (auto agree always, user agree always, user agree once...) are available in the domain for which protected API (i.e. messaging).
The domain that applies to your MIDlet depends on which of the root certificates trusts the certificate you signed your MIDlet with.
Your problem is that there is a mismatch between what you think the protection options should be for the API you want in the domain you think your MIDlet belongs too and what is actually defined in the emulator security policy.
EDIT:
how-to for WTK-based emulators:
There are 3 _policy.txt* files in the ${netbeans_installation_folder}\mobility8\WTK2.5.2\j2mewtk_template\appdb\ folder.
They each contain a list of "alias" definitions and a list of "domain" definitions.
Make every domain have the same content as the "maximum" domain.
After this, Your emulator will never again ask for any user permission.
If you have already used the emulator contained in Netbeans, you probably want to make the same changes to the ${netbeans_installation_folder}\mobility8\WTK2.5.2\appdb\ folder.
Related
I am using vim25 library to established connection with vCenter and I am able to login with following code,
vimport.login(serviceContent.getSessionManager(), username, password, null);
Now, I want to check whether this user has admin privileges or not, How can we achieve in Java with the help of vSphere client SDK?
vSphere Client SDK is used to build UI plugins so I assume you want to filter out a plugin extension based on the user privilege.
This is done via the <privilege> metadata tag used on the extension definition in the plugin.xml manifest.
SDK documentation with explanation and example: Filtering Extensions, "Filtering Based on User Privilege Level" section.
There are two aspects to the vSphere permission model:
vCenter privileges, which are combined into roles which are then assigned to users or groups as permissions on particular pieces of the vCenter inventory. Normally each vCenter operation is validate against the actual permissions for the operation that the user has on an object. So what you want in principle is to check whether has a specific permission instead of whether he's an administrator. The second is more of a secondary concept coming from the built-in Administrator role that has full set of privileges, but which may not be granted at all to the user on certain parts of the inventory. What I'd suggest is to figure out what is the actual permission you care about and what parts of the inventory you need to check. There are certain APIs (the ones on global singleton Managed Objects such as TaskManager) that simply check what is granted at the rootFolder level.
SSO Groups - some of the services check whether the SSO token contains claims about specific group membership. This is usually done by services related to authentication that cannot piggy-back on vCenter permissions. Given your example I assume you're not getting an SSO token and don't care about this model.
I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions.
I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database.
The applet used to work with the database when I self signed it, but not anymore.
In addition, many unknown users will be using the applet, so I won't have control over their machines.
Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?
Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs
Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.
update: This page (Java Control Panel Documentation) describes what type of signature is required for various client side security level settings:
As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services1 works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.
It is relevant in that:
It uses a self signed certificate
It allows a sand-boxed app. to read/write to the local file system.
An applet launched using JWS has access to the API.
This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate. Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best).
As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.
Currently I take part in developing a system based on Java EE (WebLogic server, to be more precise) and I am wondering how to protect some private data from administrators. For example, some parts of a system stores credentials for legacy systems in a deployment descriptors as plain text and this is bad because a deployer can read application configuration file (ejb-jar.xml, for example) and steal username and password for powerfull account. I want to close this security hole, but don't know how.
Now I am interested in protecting this kind of data:
Login
Password
Private key for symmetric encryption
From here I've discovered that I can use a JCEKS keystore to protect this type of information, but I can not understand how to use it. My application still should contain the kestore password and the key password to access it. So, a depoyer can steal passwords for keystores and keys, find my secure storage and steal credetials. Obviously, I can revoke read privileges from the deployer account, but then he can decompile my appliaction and develop his own similar app (or edit my one), that simply prints secure data to some file or send it by email... And now I am stuck...
Can anybody give me some links that can explain how to protect a system from administrators? Weblogic related links will be preferable. I totally understand that it is not possible to protect from all administrators and there should be some security administrator that will be responsible for keystore management and so forth, but I want to secure all sensitive data from everybody else.
RESULTS
Both jtahlborn's and slim's answers are correct, but slims's answer in more interesting. I think that in my case it will be appropriate to accept only signed applications for installation on the server. This decidion can solve problem with applicatoin modifications done by a administrator. Administrators will have password from keystore and all keys, but they will not have access to keystore file at all. Access to keystore file will have only special security administrators ('rw') and server ('r'). So, everybody will have the key, but nobody (except security administrators) will have access to the box.
There is no solution to this problem unless you enter login credentials at application startup (assuming the admin cannot access the application memory, which may not be a safe assumption). any solution which involves the keys sitting in the same place as the application will result in an administrator (with application filesystem access) being able to access any sensitive data accessible by the application. this is similar to the DRM problem (you can't give someone a locked box and the keys and expect that they can't open the box).
I think the meat of this question is in the definition of "admin".
You've said that you're comfortable with a "security admin" who does have access to key stores.
Traditionally, UNIX types think of "admin" as being the "root" user - someone with access to everything on the machine. Root can do literally anything, right down to peeking and poking at application memory, or reading/writing to raw disk addresses. If the server can get a private key, so can root.
If you want to define an "admin" role with more limited access, then yes, you could set up something where such users existed. They would need to have fewer privileges than the server application itself, since there is at least one thing the app can do (get a private key) that the "admin" cannot.
Such a user probably wouldn't be able to install the app either (since, if they could, they could create and install a version of the app which exposes the private key). Your "admin" couldn't therefore deploy the component that works with the private key. They could, however, potentially deploy a module that runs within that container (as long as the container cannot supply the private key to the module).
However, it's not just the key you want to protect. The real "secret" is the data encrypted using the key. So we still have a problem with the approach above. If the module can read the encrypted data, then so can an "admin" with the same privileges as the module. And that includes anyone who can install the module.
You could investigate ways to sign the module, so that an "admin" could not create their own version.
There comes a point, though, where the measures required to enable untrustworthy admins, become more expensive (in terms of time and effort) than simply using trustworthy admins.
So, you need to make a list of things your so called "admin" can do. Depending on what those things are, it may well be possible to allow a non-root user to do those things. On UNIX, you might use a tool like sudo to allow a non-root user to do things like start/stop the server, read logs, clean logs, etc.
It might be possible to separate the authentication from the rest of the application.
For example, if you communicate with the legacy systems via a TLS-secured socket, you could write a small separate application that accepts unencrypted connections from the application, then makes a secure, authenticated, connection to the legacy system, and pumps data between the application and the legacy system. Essentially, it's an authenticating proxy. Then, the application wouldn't need these keys. You could install and operate the application as a user who didn't have permission to read the files containing the key, but the application could still communicate with the legacy systems.
Of course, now you have the problem of how to authenticate the application to the proxy. You might feel that the machine is secure enough that you don't need to do that at all - as long as the proxy only listens on the loopback interface. If not, if you could use a unix domain socket instead, then you could control access using filesystem permissions: you could run the application as some user in some particular group, then restrict access to the socket to members of that group. Java doesn't have unix domain socket support in the standard library, but you can add it with junixsocket or JUDS.
I recently stumbled across a problem when starting my application via JNLP. I now narrowed it down to a java.security.AccessControlException, which denies me to shut down my ExecuterService.
So, I did some reading and found out that I'll need the permission (modifyThread) to successfully shut down the service. I also found out that I should use the <security>-tag (in the JNLP-file) to request it, but I'm a little confused about how.
The documentation of the tag says:
[...] If the all-permissions element is specified, the application
will have full access to the client machine and local network. If an
application requests full access, then all JAR files must be
signed. The user will be prompted [...]
From reading this it seems to me, that I can choose to either get all or no permissions... which seems like a confusing Implementation. Because I only need the one to shutdown my service.
I also read this article, telling me that I should not request all permissions, because I would then open up the users computer for malicious code.
So, is there a way to specify that I only need the specific permission (modifyThread) and I therefor don't need to sign my jar? Or will I have to go with the "sign my jar and request everything"-approach?
..will I have to go with the "sign my jar and request everything"-approach?
Yes. JWS permissions come in 3 levels1, the only one where modifying threads is permitted, is all-permissions.
1) JWS security levels
Sand-boxed. Provides a very limited environment. Access to things like printers and the local file-system is only permitted using the JNLP API services, which provide more limited forms of File after prompting the user. Come with window banners. Can only communicate with own server.
j2ee-application-client-permissions - provide those JNLP API services unprompted (after the user accepts the digitally signed code) removes the window banners.
all-permissions - pretty much anything, including replacing the existing security manager (yes, even 'all permissions' code gets a security manager in JWS - it is just very lenient).
Also chase the links from the JNLP & JWS pages. I can personally recommend those summaries & links.
I would like to develop an own API for Android that will request "Signature" protection level and will be accessible for 'my" applications.
Idea is following:
"install" my own certificate into system certificates storage
sign "trusted" application with my own certificate
As a result during request from any application to my API system will check if this application is signed with an appropriate certificate. If my sertificate is installed into Android everything should be fine.
I'm going to prototype that approach, but if there is something obvious that can prevent me from doing that - please let me know.
The question:
how to install own certificate into system certificates storage (assuming we will build Android ourselves and can modify system (in a reasonable borders))?
Thank you very much.
P.S. I'm not very familiar with Java/Android development, so please don't mind if you see something strange.
UPDATE:
As I wrote in a comment to zeetoobiker's answer, If I sign my API with my own certificate then it will be accessible for all my applications (signed by my certificate), but it won't have any system permissions. And I don't want all my 'customers' to navigate to the "realmb.com/droidCert/" web site. Instead I want manufacturer to add my certificate into an OS, now I'm working on making a proof of concept.
I don't think you need to install the certificate.
From the permission docs for signature:
A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.
This means that it's the certificate you use to sign the apps that matter (not any installed certificates) - if you sign App 1 and App 2 with the same certificate then it will have permission. If App 3 which is signed with a different certificate attempts to access the API then it will get a no permission exception.
According to the docs (I have to admit I've not done it although I'm looking at for some of my apps) it should work on vanilla Android without any necessary customisations / access to the device / root.
If you really need to install the root certificate, this may help but I don't think you do for your stated aim.