From: John Fricker <jfricker@vertexgroup.com>
To: ichudov@algebra.com
Message Hash: 1fe74963662d1d350b2439d53455541a6014524a5b17ddf27458d95c324237ca
Message ID: <19961217052343287.AAA173@dev.vertexgroup.com>
Reply To: N/A
UTC Datetime: 1996-12-17 05:24:35 UTC
Raw Date: Mon, 16 Dec 1996 21:24:35 -0800 (PST)
From: John Fricker <jfricker@vertexgroup.com>
Date: Mon, 16 Dec 1996 21:24:35 -0800 (PST)
To: ichudov@algebra.com
Subject: RE: Securing ActiveX.
Message-ID: <19961217052343287.AAA173@dev.vertexgroup.com>
MIME-Version: 1.0
Content-Type: text/plain
>Ray Arachelian (sunder@brainlink.com) said something about Securing ActiveX.
on or about 12/16/96 11:08 AM
>On Sat, 14 Dec 1996 ichudov@algebra.com wrote:
>
>> Ray Arachelian wrote:
>> >
>> > Until Microsoft secures ActiveX in it's own sandbox and doesn't allow it
>> > to access things it shouldn't, it's not cool.
>> >
>>
>> I do not understand how one can secure ActiveX.
>
>Simple. Check out Windows NT, under NT you can write/run programs as
>services which log in as an account. When you do this, that service
>program is limited to the security restrictions of that account.
Not exactly. Win32 API's include the ability for a program to impersonate any
known user. Besides ActiveX (OLE really) has nothing to do with services.
In order to make ActiveX secure there would need to be a virtual machine with
access to a limitted API only. Sound familiar?
>
>If you're using the NTFS file system and give that account access only to
>one directory, it can't access anything but that directory. (If you're
>using FAT, this isn't true and the program can read/write/delete anything
>it wants.) Works quite well.
>
>It can be done under 95 but Microsoft will have to write a Sandbox
>Virtual Machine (a Virtual x86 session whose API's are filtered to
>prevent access to certain things like the file system, and disables
>direct I/O.) Not that easy under '95, but it already exists for NT.
There is no such thing on WinNT.
>
>The problem is how to deal with DLL's. You don't know all
>features/functions of all DLL's. It may be possible to write a DLL that
>runs outside the sandbox and can act as a proxy to the file system, so
>it's iffy unless you limit the DLL's and services that ActiveX apps talk
>to, and make them all live inside the sandbox.
>
Why is that a problem? ActiveX components are shipped as discrete objects with
a known DLL like interface. DLL's are unloaded when the load counter is zero so
they don't hang around in memory after the ActiveX job is done. You also cannot
write a "proxy to the file system" in a DLL. That's a special device driver
called a filter. Of course there is this Mark Russinovich fellow that is
showing how this is not exactly true. It is possible to identify all entry
points in a DLL.
--j
--------------------------------------------------------------------
| John Fricker (jfricker@vertexgroup.com)
| -random notes-
| My PGP public key is available by sending
| me email with subject "send pgp key".
| www.Program.com is a good programmer web site.
--------------------------------------------------------------------
Return to December 1996
Return to “Ray Arachelian <sunder@brainlink.com>”