Forums
New posts
Search forums
Members
Current visitors
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
Archive
Archive
Java
Secure Java packages: a proposal
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
[QUOTE="Twisted, post: 653129"] Trusted and untrusted code interoperating creates this concern, since it may be possible for hostile code to corrupt an instance of a trusted class if it has access to its less-public members... After hearing that many compile-time-private members are run-time-package-private (inner classes and anything they access, for example) this seems even more potentially useful. At the same time, AOP may mean all security models centred around object encapsulation models go out the window. Anything AOP by definition addresses "crosscutting concerns" and to do so must be able to reach into and add new side effects to existing method calls and such events. In so doing, it provides a potential route for an attacker to inject hostile code (e.g. a backdoor), via a "backdoor aspect" say, into a trusted class, no matter what its usual privileges. Aspect-granularity security rather than class-granularity may be needed (and nevermind the ancient, naive user-granularity, let alone hunk-of-hardware granularity of grandpap's days!) ... One thing often suggested as an application of AOP is actually to handle security as a crosscutting concern, inserting security audits into running code at certain sensitive points (say, whenever a "bankBalance" value gets modified), and make a "security module" anyone can bolt onto production code by putting a new class, dll, or whatever into a system. Of course, this means Joe Attacker can put an "insecurity module" into production code in the exact same way, providing a backdoor. Such an employee is especially likely to become a disgruntled one in the near future, given their attitude; and when they do ... :) Of course, the solution to AOP-introduced security headaches is probably to be found in AOP; it does seem generally to be the rule that each new generation of <insert technology here> both causes new problems and provides the tools to fix them. Industry makes carbon emissions on, well, an industrial scale, but allows for sequestering it on the same scale, for example. And of course, in the computer/data security area, quantum computing threatens to blow the foundation (NP != P) out from under standard PKE and other cryptosystems, but then there's this new thing called quantum encryption... (Soon, I suppose, the physicists will discover evidence that all that quantum weirdness and nonlocal, acausal stuff is just the result of the universe being a) massively parallel and b) coded by someone who never heard of "synchronized (this) {}". Then someone will find a way to hack the virtual machine, someone else will use this to break quantum encryption and create fearsome new weapons that act remotely without an interceptable signal, and someone else still will realize that the same ability enables them to communicate uninterceptibly and securely ... hey, someone jog my memory, didn't greg bear write a story about something like that once?) [/QUOTE]
Verification
Post reply
Forums
Archive
Archive
Java
Secure Java packages: a proposal
Top