[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] Sandboxed SWT. Is this possible?
|
Ok, Ivan, I suggest you enter a
bug report with the contents of this discussion. I'm not sure that
we will be addressing this in the near future, unless there is sufficient
demand from the community, especially due to the binary compatibility issues,
but it doesn't hurt to have the bug report to capture our thoughts.
"Ivan Markov"
<ivan.markov@xxxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx
09/25/2005 11:01 AM
Please respond to
"Eclipse Platform SWT component developers list." |
|
To
| "Eclipse Platform SWT
component developers list." <platform-swt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [platform-swt-dev] Sandboxed
SWT. Is this possible? |
|
Hi Steve,
My comments inline.
The "instance of OS" is a
good idea however, I'd probably rename the OS class to OSCall or something
like that and name the instance OS so that less code would change. Methods
that are static final native are highly optimized by some JIT's, so we'd
be a bit slower.
The OSCall-being-the-class and OS-being-the-instance
idea will generate tons of warnings from ECJ for the static final ints
you have in OS (like, "you are using a constant through nonstatic
instance").
In order to get rid of Control.handle(), we'd instead add a method something
like Widget.getHandleData() (*** insert better name here ***). This
would be a class that was platform specific. On Windows, it could
include a field that was the HWND and on platforms with multiple handles
or wierd clipping (such as the Mac), it would return more internal widget
"handle" information. However, it would make things somewhat
slower.
That sounds like a good plan. Within org.eclipse.swt.widgets.*
the handles can be accessed directly so no performance hit.
In org.eclipse.swt.graphics you have GCData
anyway, so no performance hit there as well. As for org.eclipse.swt.dnd,
I doubt there will be a huge performance hit either.
Some other "unsafe" things:
Drawable.internal_new_GC(GCData data)/internal_dispose_GC(int
handle, GCData data)
I've rewritten these as
Drawable.internal_new_GC(OS os, GCData
data)/internal_dispose_GC(OS os, int handle, GCData data)
.. where the caller is supposed to provide
non-null os object. The "OS os" thing here is a proof that the
caller has enough permissions to call internal stuff: if he can "new"
the OS class, then, presumably, he can call the internal methods outside
OS. This technique can be re-applied to other cases too, like Font.internal_new(OS
os, Device device, long handle) etc.
Although it is technically feasible,
the number of code changes to catch every possible place and the overhead
in doing this would be prohibitive.
I'm not sure whether you are referring
here the "OS os" thing or the resource management.
For the first, I agree that it would break
binary compatibility, but I doubt it will have performance overhead or
it will be too much work.
For example, disposing a font that is
in use would require us to keep a list of every place the font is used
(both widgets and graphics) and set a default system font. However,
setting a font in a widget can cause a redraw, redraws cause paint events
and behavior is changed.
I agree. I've thought a bit for strategies
alternative to selecting the default system font, like:
- GC throws exception immediately when
a font being selected in it is disposed; BUT this will break code in Eclipse;
In my resource tracker I receive tons of warnings coming from Eclipse for
cases where the font is disposed first and afterwards the GC where the
font is selected is disposed as well.
- GC throws exception when text-related
operation is called. BUT this may become even more complex than the selection
of default font, as you need to know what part of GC can be safely called
as it will not need valid font.
What I cannot agree with, is that having
OS type-safe and no resource tracking at all is a good solution. It may
be a good start, but in the end, code based security is all-or-nothing.
It is one thing to miss code protection here and there, and then fix these
as-you-go, and another when you have a whole concept, like resource selection,
which is not type-safe at all.
There is the further problem of Custom
Controls that can have their own concept of default font.
For all-Java custom controls I don't see
the problem at all. Do you?
For native custom controls, user should
do the resource tracking thing as well.
Doing any of this work would break binary compatibility, something that
SWT has not done since version 1.0.
"Ivan Markov"
<ivan.markov@xxxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx
09/19/2005 05:03 AM
Please respond to
"Eclipse Platform SWT component developers list." |
|
To
| <platform-swt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [platform-swt-dev] Sandboxed
SWT. Is this possible? |
|
Hello everybody,
Inspired by some constructive criticism on a well known Java forum, I'm
recently thinking of how much effort it would be to achieve code based
security in SWT. I will use my SWT/Fox port as a playground.
Your thoughts on the following questions are very welcome:
Would it be useful? Perhaps, yes. SWT is probably the single Java API that
currently cannot be sandboxed due to the exposure of various "crash-friendly"
things like OS.java, Control.handle, etcetera.
Would this be easy to achieve, without sacrificing the simplicity of the
code and without the need for total rework of the SWT internals? Perhaps,
yes. Please, read on.
My plan is as follows:
There are several main sources of crashes in SWT:
1. The native layer (OS.java and friends) is exposed for everyone to use.
This is something I'm able to tolerate as otherwise probably we need tons
of abstractions or something related to C++'s "friend" construct
in order to cross package-level boundaries and still preserve private visibility.
Note that there is already a JSR which is supposed to bring a similar facility
to Java. The main problem with the exposed native layer is that everyone
is able to call a static function in OS.java with bogus parameters provided,
thus crashing the JVM process. If this is remedied somehow, the exposure
of "support" structures like LOGFONT, LOGPEN, BITMAP etc. should
not be a problem: the important thing to grok here is that user may create
and change these as he wills, but as long as he is not allowed to directly
call functions of OS.java, he can't crash the JVM, as OS.java represents
the "code" of the operating system, whiule everything else is
the "data".
One way OS.java can be protected is by a) marking all natives as package
protected or private and b) creating non-static public wrapper functions
for all the natives. Note that in some X11 ports this is already done (module
non-static) due to the need to lock the calls going into into XLIB.
What are these non-static wrappers going to buy us? Well, if the primary
interface of OS.java becomes non-static, then the constructor of
OS.java can be protected by doing a permission check with AccessController
and friends and throwing exception if the caller's stack does not have
enough permissions. The usage pattern of OS.java from within SWT would
be like this:
In the base class of every SWT, package needing native access, i.e. in
Widget.java, Resource.java, Printer.java, etc:
<snip>
static OS os;
static {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
os = new OS();
return null;
}
});
}
</snip>
and then all calls to functions in OS in all classes should be prefixed
not with "OS." but with "os."
Note that protecting only the constructor is a) sufficient and b) give
significant performance advantage, as security checks should not be done
on every OS API call; not to mention that having to do the doPrivileged()
thing all the time is inconvenient, at best.
2. public int Control.handle
This is also dangerous, as user is free to change the handle of the control
to bogus value, at will. This can be remedied by instead providing:
public int Control.handle()
3. Resource tracking.
This is nasty. Here's a sample of the problem:
<snip>
GC gc = ...;
Font font = ...;
gc.setFont(font);
font.dispose();
gc.drawString("test"); // <-- Crash on platforms based on
Toolkits like Fox or probably even GTK+, or weird output on Win32
</snip>
The problem here is that after the disposal of the Font instance, there
is no valid Font object selected in the GC. In SWT ports wrapping toolkits
where Font is represented by a C++ object, this means that the C++ GC class
will try to access the C++ Font class, which is already free-d, which leads
to memory corruption and possible GPF.
The best thing for solving this I've come so far is some sort of resource
tracking utility class. The "selection" of every SWT object in
another SWT object is tracked there. When the selected object is disposed,
the "selector" object is signalled so that it has can switch
to using another font handle, usually the default system one which cannot
be freed anyway.
That's it. I know I've missed a tons of stuff. For one thing I haven't
covered how in this framework a costom "native" control is supposed
to receive native callbacks (WM_* on win32).
Regards,
Ivan
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev