In comp.os.linux.advocacy, thufir
<hawat.thufir@xxxxxxxxx>
wrote
on Wed, 23 Jul 2008 19:48:18 GMT
<6WLhk.128607$gc5.50566@pd7urf2no>:
> On Wed, 23 Jul 2008 07:47:44 -0700, The Ghost In The Machine wrote:
>
>
>> One might quibble here on "installed", but the Web browser nowadays
>> could be construed as a bit of a mole. Javascript, after all, can do
>> quite a bit, or one can look into things such as Java's JNLP, or the
>> horrors of ActiveX.
>
> what's wrong with jnlp? are there security holes?
>
Nothing I'm aware of, actually, but a signed set of
.JAR files can do quite a bit, permissions in the main
filesystem permitting. Also, signed .JAR files do not
have the indicator "Signed Java Applet Window" in the main
JNLP frame -- a form of impersonation, or a welcome
removal.
But one can execute arbitrary Java bytecode in JNLP; it
won't do arbitrary damage, though (thank goodness [*]).
However, JNLP does start to blur the line between something
running on a local user's system, and something running
remotely -- though in all fairness the JNLP process is
local, even if the code files are fetched from afar.
(Unsigned .JAR files are far more tightly controlled,
thanks to Java's SecurityManager interface. IIRC, an
unsigned .JAR file cannot save to one's local disk, and
is rather restricted in its socket connections. One also
gets a message in any java.awt.Frame, hopefully alerting
the casual user.)
ssh proxying (or xhost +remotehost, which is now
rarely used) have the process remote, with the display
instructions carted over rather than the Java bytecode.
If one uses ssh the display instructions and events
are encrypted.
Mixtures are possible; JNLP processes in particular
can launch their own browsers, either by using
javax.swing.JEditorPane (which can display HTML and CSS,
though not as well as Firefox), by subinvoking firefox
(which is a bit clumsy), or by using SWT's Browser class
(which encapsulates a browser window; on Windows it's IE
or Firefox, and in Linux it's Firefox). Note that SWT
requires DLLs which are OS-specific and host-specific.
For its part ssh can subinvoke its own browser, with
the results as one might expect: encrypted graphical
instructions from that browser are sent over the wire.
Javascript can do a fair number of things, but AFAIK
direct I/O to the user's disk is not among them, though
it might manipulate things such as cookies. I could see
Javascript in theory implementing TCP NFS, but such an
implementation would be rather unwieldly, nor do all Linux
systems support NFS.
All this is largely invisible to the casual user (though
a remotely-invoked browser might be a little slow); at
most he can see things happening on the screen. If he's
curious he can poke around using commands such as tcpdump
to see what's going over the wire.
Font issues may also crop up, especially with ssh proxying.
If an application references a font that doesn't exist on
the X server, or the application has font metrics for a
font that the X server doesn't have, then things can get
mildly interesting.
>
> -Thufir
[*] unless there is a security issue in the JVM.
--
#191, ewill3@xxxxxxxxxxxxx
Linux. An OS which actually, unlike certain other offerings, works.
** Posted from http://www.teranews.com **
|
|
