Security Managers: do you use them? For what?

Discussions

News: Security Managers: do you use them? For what?

  1. One of the features of Java from early in its design was its security model. Originally, it applied to applets, by isolating them into a sandbox, one that's generally been successful. However, with J2EE and JINI, the security manager constrains programmers from doing unsafe actions - occasionally, actions one needs. For example, in J2EE, the security manager prevents JSP authors from putting in code such as . (This could be avoided by using a template language instead of JSP, of course, but that doesn't prevent someone from putting the same code in a managed bean or some other class in the application.) It also might potentially enforce other rules in J2EE, by preventing EJBs from spawning threads, or preventing a web application from installing a new SecurityManager. Security managers are sometimes very annoying in development, so annoying that Glassfish - the Java EE reference implementation - actually turned off the security manager by default. While turning off the security manager makes using servers much easier during development, migrating the applications into a production environment - where security is likely to still be enabled - becomes very difficult. For example, using JavaSpaces in a JavaEE application requires installation of an RMISecurityManager, which involves adding ten or more security permissions, each of which has to be determined by examining a failure. JavaSpaces is a rare specific example, but consider that many other libraries require classloader modifications, all of which are illegal under the normal security settings for JavaEE. Some installations get around this by explicitly turning off the security manager in production. Is the security manager a factor in your application development? Which servers have you deployed to that enable the security manager? What issues did you find through this, if any, and how did you work around them? Do you think simple removal of the security manager is an acceptable workaround?
  2. No, I do not use security managers. It's a pain in the ass to use them. I never ever had any need for the use of them either. Security can be implemented on different levels and methods. You can even build them into the work process. I never even build an application that uses a application server (even though I consider myself an enterprise developer). If I would build one I would simply demand full control of the application server and that it is only used by our application. This means that security can be switched off, all beans can do anything. Since my company is the only one that inserts new beans I know I can trust them. Security is ofcourse a important factor of our development process but because of cost and time we often shift the security risc to another party. For instance we create an application and demand a new dedicated computer for it on a firewalled network that is secured by another party. Still I know it is never secure enough: If the client wants more security he can have it: it just means that the application becomes more expensive.
  3. I never even build an application that uses a application server (even though I consider myself an enterprise developer). If I would build one I would simply demand full control of the application server and that it is only used by our application. This means that security can be switched off, all beans can do anything.
    Yeah, and the IT department at your customer company, which just invested $X millions in a state of the art WebSphere cluster with HA can just go screw themselfes? Because you will not sell your software unless you get your own private instance? =) Actually, security managers can be a great way to enforce standards, such as that EJB´s cant access a local file system. If you really, really, want to, and you know what youre doing, you can disable the restriction, but its there to stop those who doesnt know, or even understand, about it from messing up.
  4. Yeah, and the IT department at your customer company, which just invested $X millions in a state of the art WebSphere cluster with HA can just go screw themselfes?
    The clients we have all do not use an application server. They just want a website, that the website is mission critital they do not really see themselfs; since we as IT specialists do see that we build in enterprise features to provide stability, scalability, transactions, logging, etc.
    Because you will not sell your software unless you get your own private instance? =)
    I only do that to enforce security the client himself does not think about, he probably does not even want to think about it.
    Actually, security managers can be a great way to enforce standards, such as that EJB´s cant access a local file system. If you really, really, want to, and you know what youre doing, you can disable the restriction, but its there to stop those who doesnt know, or even understand, about it from messing up.
    I agree: I love standards and I love to use them, but please tell that to my client that does not want to pay for using those standards and who really doesn't care about them as long as the product works correctly as he specified. I can give my client two options: either buy yourself a new server dedicated for my stand alone application (approx. 5000 EUR) for more security or let a few developers make sure that the stand alone application is secure (approx. 10000 EUR). Or even better: build the application from day one completely in EJB for running in an application server that would double the entire price from day one. What do you think he will choose?
  5. security manager[ Go to top ]

    Which servers have you deployed to that enable the security manager? What issues did you find through this, if any, and how did you work around them? Do you think simple removal of the security manager is an acceptable workaround?
    I used SUN Java Aplication Server and it has security manager enabled by default. I had some issues with Hibernate but its not so hard to tweak security policy file. I don't think that removal of security manager is an acceptable option.
  6. ...
    Security managers are sometimes very annoying in development, so annoying that Glassfish - the Java EE reference implementation - actually turned off the security manager by default.

    While turning off the security manager makes using servers much easier during development, migrating the applications into a production environment - where security is likely to still be enabled - becomes very difficult.

    For example, using JavaSpaces in a JavaEE application requires installation of an RMISecurityManager, which involves adding ten or more security permissions, each of which has to be determined by examining a failure. JavaSpaces is a rare specific example, but consider that many other libraries require classloader modifications, all of which are illegal under the normal security settings for JavaEE.
    So, just as a note, Jini 2.1 provides a class which can be used to determine all policy requirements in one run saving all that pain. Of course, your container/server needs to support installation of said class and I'm sure some of them will prevent that.

    Some installations get around this by explicitly turning off the security manager in production.

    Is the security manager a factor in your application development? Which servers have you deployed to that enable the security manager? What issues did you find through this, if any, and how did you work around them? Do you think simple removal of the security manager is an acceptable workaround?
    I've certainly settled for removal in the past but personally, I prefer having control over security manager and policy. That's what I get when I work without a container, why not with? In respect of classloaders, many specs prescribe certain fixed arrangements for classloaders which makes handling downloadable code (as in the case of Jini) difficult. There are workarounds but, really, I'd say specs and containers should also be more flexible in this area. I guess I'm basically saying that, right now most containers/servers seem to enforce fixed policies where I'd prefer a sensible default with options for me to change things around should I require it. As it happens, I have had positive feedback from one Blitz JavaSpaces user recently which suggests GlassFish is pretty flexible in this area.
  7. Forgot to say, I use a security manager with Jini Services all the time simply because it's an essential (but small) part of providing a secure deployment. Those I write/deploy such services for take security quite seriously and do indeed want strict control over permissions granted to code/users of code. Sometimes they want control down to individual methods of a given Jini Service. The real problem with security is that it's aspect like. It touches everything such that if you have one break in the security chain your entire effort is compromised.
  8. I have not heard of a vulnerability that required configuring other than default security policies. Ted Neward in Effective Enterprise Java suggests turning on "platform security" (Item 62) should an attacker be able to edit and run JSPs. I just have not heard of this happening. I suppose the NSA uses it. Crap! this post is going in my file now.
  9. Different requirements => different solutions. If an application server is running only one application (in a wide sense of the word - not necesarry only one ear), then security manager is not so usefull. If an application server is running multiple applications, then it may suddenly be important that one application can not do something bad to the server. The most extreme case is ofcourse web hotels with shared servers. As long as someone uses them, then we need support for them. And BTW Java applet will always need them I guess.
  10. Different requirements => different solutions.

    If an application server is running only one
    application (in a wide sense of the word - not necesarry
    only one ear), then security manager is not so usefull.

    If an application server is running multiple applications,
    then it may suddenly be important that one application
    can not do something bad to the server. The most extreme
    case is ofcourse web hotels with shared servers.

    As long as someone uses them, then we need support
    for them.

    And BTW Java applet will always need them I guess.
    More generally, it's downloadable code (of which Applets are one example) that requires the presence of a security manager. If you can secure all sources of downloaded code and you trust them, you only need the security manager present to enable downloaded code and could set a policy of AllPermission.
  11. When the codes running on your computer is not written by you, a SecurityManager is certainly needed. This includes applets on clients' machines and server apps running on an ASP's server written by its customers. On the other hand, you should never be too confident on your own codes, since they have bugs and will be exploited to do harm on you one day. Therefore, it looks like SecurityManager is always a good thing.
  12. Security Manager : A Bane[ Go to top ]

    While developing a tapestry based application on Sun Platform( We used SUN JES Application server) we had to tweak a lot of code to get around the java security model. Tapestry uses class enhancements a lot and there is no way one can give permissions to a enhanced class. To be very frank java security hampers application development as opposed to tighten application security. One can always provide specific code base specific security permissions to get around it. So whats the use?
  13. Everyone here should know of the long-standing EJB spec restrictions on actions such as writing to the file system or starting a Thread in an EJB. But also know that most app servers never enforced these limitations. I do remember working with ISP hosting companies back when I worked on JRun, before its J2EE server days, and they were wondering how to safely isolate customer apps within the same JVM instance, which wasn't really do-able at the time and still isn't (except maybe the Java Isolates API (http://jcp.org/en/jsr/detail?id=121), which only has an RI for Solaris, AFAIK). And explaining a Java HOW-TO for security policies and such to ASP or PHP hosts at the time was a real challenge. Enabling the Java SecurityManager and enforcing any kind of security policy can incur serious performance overhead as the JVM suddenly has to check all method invocations for permissions. However, enabling the SecurityManager and writing up a security policy is sometimes a good measure to ensure that logically private APIs cannot not used. Other measures along those lines are obfuscating your byte code and removing the debug information from class files. But these measures make your code much more difficult to debug in the field.
  14. Enabling the Java SecurityManager and enforcing any kind of security policy can incur serious performance overhead as the JVM suddenly has to check all method invocations for permissions.

    However, enabling the SecurityManager and writing up a security policy is sometimes a good measure to ensure that logically private APIs cannot not used.
    Well, I believe that WebSphere, for instance, uses this measure by default for a secured server, and it doesnt seem to hurt performance for a *real* system much. On the other hand, asking a customer to disable this, just because your code cant live with it, will damage something - your credibility.
  15. Come on. Besides, even if this is true (prove it), what does enabling the SecurityManager do for you if you don't have any policy defined? It's useless.