3 ms·
More generally, it ought to be easier to constrain apps running on the JVM to declared sandboxes. I once looked at the Java security model and found it to be t
by ShabbyDoo 14y ago
More generally, it ought to be easier to constrain apps running on the JVM to declared sandboxes. I once looked at the Java security model and found it to be totally inadequate for such purposes as it seemed to have been designed for ensuring that desktops could not be compromised by rogue applets running in browsers. Specifically, I was surprised by the coarse-grainedness of the security settings. Want to limit access to the network by disallowing use of the Socket class? Done. Want to only allow access to a whitelist of hosts? No dice. No filesystem access at all? Easy. Limit the app to only reading and/or writing to certain directories? Not a chance.
I want to define whitelists for each environment in which my app will run -- development, QA, production, etc. To which hosts may it connect? Where may it access files? What else might I wish to constrain as way of avoiding inadvertent dependencies? Particular queues/topics on messaging buses? Database schemas within a particular server (network restrictions are too coarse for this)? When asking this question, I'm not trying to protect myself from rogue developers with malevolent intentions -- I just want to avoid a scenario like the one described by the OP.
Recently, I started-up the Java app upon which I am currently working and watched its network behavior via Microsoft's Wireshark-esque network monitoring tool. It turns out that EHCache now asks one of Terracotta's servers for the most recent EHCache version number so that it can spit an out-of-date warning in the logs. Benign and useful, but I still had to spend a few minutes in the EHCache source to make sure that, if Terracotta's servers were down, our app would still start-up.
Should one do this at the OS level (jails, perhaps)? I'm not limiting this idea to just Java apps, but I'm really only an expert in the Java space.
I also argue that the whitelist would help codify inter-app dependencies in large IT environments. A few years ago, the large IT shop for which I worked did a disaster recovery drill where they literally deployed 10's of apps in an IBM-provided datacenter as a dry run. One thing they learned was that a particular production app was erroneously configured to log certain audit events to a server in a QA environment (which was not part of the disaster recovery plan for obvious reasons). Whitelists would have prevented this issue.
- tomjen3 14y agoCoun't you do this by writting your own security manager?
- zorlem 14y agoOn several occasions I've used the Tomcat Security Manager and it have not given me any problems. I find it fine-grained enough for my purposes, although not as fine-grained as you wish. I've used it to limit JVM's access to a specific set of hosts and TCP ports, restrict (RW and RO) access to files with and without wildcards, restrict access to specific methods, properties, classes and what-not. One can't use it to restrict the access to specific databases, or topics in the message queues as you suggest, but I don't think it's necessary. I think it's out of scope for the VM to restrict access to a specific DB and this should be the responsibility of the specific DBMS. Otherwise I'd imagine the overhead would be quite serious. I haven't heard of any VM manager that would provide such a thorough and deep access control, do you know of any? If you still need this functionality in a Java security manager I believe you could build it using the existing hooks, they look quite powerful and flexible. Now, the real pain I've had with the Security Manager in Tomcat 5.5 was writing the rules for a pre-canned application, not written with SM in mind. It was quite a tedious process, but all MAC systems are tedious to set-up initially. That's life.
- ShabbyDoo 14y agoI hadn't known about Tomcat's security manager stuff. Interesting, and proof that Java's security manager stuff can be extended for practical purposes. I had thought about using AspectJ to wrap interesting points in various APIs and then do "stuff". The obvious behavior is to restrict usage based on whitelists. However, it might also be interesting to run one's app in an access logging mode, especially when trying to wrap some controls around a previously unrestricted production application.
- rwmj 14y agoFrom your description, it sounds like you want SELinux.
- ShabbyDoo 14y agoSo, I can understand how the OS could limit access to the network or filesystem, but it can't know that I'm accessing db schema ABC. However, network and filesystem restrictions are probably good enough for most people.
- rwmj 14y agoActually several userspace tools have had SELinux extensions added (with not very much adoption, it has to be said). Here's an article about PostgreSQL + SELinux: https://lwn.net/Articles/365224/ https://lwn.net/Articles/365224/
- bdunbar 14y agoLimit the app to only reading and/or writing to certain directories? Not a chance. Create a non-privleged user. Restrict the account r/w to certain directories. Run the app as that user. Want to only allow access to a whitelist of hosts? No dice. I have not done this, but I think you can do that with iptables.