Discovering a Java Application's Security Requirements (O'ReillyNet)
Discovering a Java Application's Security Requirements (O'ReillyNet)
Posted Jan 4, 2007 22:46 UTC (Thu) by bluefoxicy (guest, #25366)Parent article: Discovering a Java Application's Security Requirements (O'ReillyNet)
"Novel approach"? Since the dawn of time (ok, some time in 2001 or so) grsecurity has implemented access control policies at the operating system level with a learning module that works about the same way. This works about the same way, but at the application level.
Posted Jan 4, 2007 22:57 UTC (Thu)
by nix (subscriber, #2304)
[Link]
This is definitely not new stuff. (Important, just not new.)
Posted Jan 5, 2007 3:52 UTC (Fri)
by dwheeler (guest, #1216)
[Link]
Posted Jan 5, 2007 5:58 UTC (Fri)
by dang (guest, #310)
[Link] (3 responses)
First, this is not about how your OS protects itself from code run in userpace, but it is about how your application can lock itself down. This matters more when your app needs to load third party modules or if you are dealing with something where the sandbox matters ( e.g, an applet in a browser ). But regardless, you are missing an unsubtle distinction here.
Second, while the example code deals largely with file access permissions, the security manager also deals with things like x509 certs, access to the Clipboard for cut/paste, whether you can serialize objects, tons and tons of things beyond file access call checkPermission(), many of which neither grsecurity or selinux know anything about.
So this is actually worth a read and it might well make it easier for a Java developer to write a better, safer app.
Posted Jan 5, 2007 7:12 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (2 responses)
Your "unsubtle distinction" is, I think, exceedingly subtle. What's the theoretical difference between discovering the surface of an application's security requirements by running it instrumented under grsecurity versus running it instrumented under a JVM? I think you'll find that there's hardly any conceptual difference at all.
Posted Jan 5, 2007 10:25 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Jan 9, 2007 2:05 UTC (Tue)
by sholden (guest, #7881)
[Link]
Likewise AppArmor (and, these days, SELinux).Discovering a Java Application's Security Requirements (O'ReillyNet)
There's an SELinux module that does the same. This is a really old idea. Nevertheless, it may still be a good thing.Discovering a Java Application's Security Requirements (O'ReillyNet)
You are missing two thiings. Discovering a Java Application's Security Requirements (O'ReillyNet)
The point is, it's not a "novel approach." It's an ages-old approach, just applied to the Java environment. Everything you said about clipboard, etc, are just different attributes discovered using the exact same technique.Discovering a Java Application's Security Requirements (O'ReillyNet)
The 'novel approach', according to the blurb, is replacing the default SecurityManager with a stub that logs the calls being made. Using that you can profile your application to see the access it needs.Discovering a Java Application's Security Requirements (O'ReillyNet)
So it's the patent application definition of "novel" rather than the english definition.Discovering a Java Application's Security Requirements (O'ReillyNet)