Great post man! You summed it up quite well. I also like how you stressed that COM interop is suggested to be only used with well-known COM registered components.
Hate to be a broken horse, can you please not call it FullTrust since its not. I personally want to keep the idea that MS decided not to do FullTrust as a feature, but Elevated Trust instead.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: Wednesday, January 20, 2010 12:45 AM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Silverlight 4 COM+ Features
Hi folks,
Just blogged about some full trust features enabled using Silverlight 4 COM+ support.
shawn.li...@agilitrain.com> wrote: > Hate to be a broken horse, can you please not call it FullTrust since its > not. I personally want to keep the idea that MS decided not to do FullTrust > as a feature, but Elevated Trust instead.
I have not referred to these features as full trust in the blog post.
And in the blog post, I did stress that it's elevated privileges.
However, this is an expert environment, so we can talk about things as they are.
Using COM+ you do get de-facto full trust access on Windows.
Which includes: File execution, file storage access, O/S access, networking, etc.
If you feel that's not an accurate depiction of the situation, feel free to call out which full trust features of are missing.
From my point of view COM+ enables full-trust scenarios, while is not in fact full-trust.
-- Justin
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Shawn Wildermuth Sent: January-19-10 3:59 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Silverlight 4 COM+ Features
Hate to be a broken horse, can you please not call it FullTrust since its not. I personally want to keep the idea that MS decided not to do FullTrust as a feature, but Elevated Trust instead.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: Wednesday, January 20, 2010 12:45 AM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Silverlight 4 COM+ Features
Hi folks,
Just blogged about some full trust features enabled using Silverlight 4 COM+ support.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: Wednesday, January 20, 2010 1:17 AM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Silverlight 4 COM+ Features
I have not referred to these features as full trust in the blog post.
And in the blog post, I did stress that it's elevated privileges.
However, this is an expert environment, so we can talk about things as they are.
Using COM+ you do get de-facto full trust access on Windows.
Which includes: File execution, file storage access, O/S access, networking, etc.
If you feel that's not an accurate depiction of the situation, feel free to call out which full trust features of are missing.
From my point of view COM+ enables full-trust scenarios, while is not in fact full-trust.
-- Justin
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Shawn Wildermuth Sent: January-19-10 3:59 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Silverlight 4 COM+ Features
Hate to be a broken horse, can you please not call it FullTrust since its not. I personally want to keep the idea that MS decided not to do FullTrust as a feature, but Elevated Trust instead.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: Wednesday, January 20, 2010 12:45 AM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Silverlight 4 COM+ Features
Hi folks,
Just blogged about some full trust features enabled using Silverlight 4 COM+ support.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: Wednesday, January 20, 2010 1:17 AM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Silverlight 4 COM+ Features
I have not referred to these features as full trust in the blog post.
And in the blog post, I did stress that it's elevated privileges.
However, this is an expert environment, so we can talk about things as they are.
Using COM+ you do get de-facto full trust access on Windows.
Which includes: File execution, file storage access, O/S access, networking, etc.
If you feel that's not an accurate depiction of the situation, feel free to call out which full trust features of are missing.
From my point of view COM+ enables full-trust scenarios, while is not in fact full-trust.
-- Justin
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Shawn Wildermuth Sent: January-19-10 3:59 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Silverlight 4 COM+ Features
Hate to be a broken horse, can you please not call it FullTrust since its not. I personally want to keep the idea that MS decided not to do FullTrust as a feature, but Elevated Trust instead.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: Wednesday, January 20, 2010 12:45 AM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Silverlight 4 COM+ Features
Hi folks,
Just blogged about some full trust features enabled using Silverlight 4 COM+ support.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Justin Angel Sent: mercoledì 20 gennaio 2010 00:45 To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Silverlight 4 COM+ Features
Hi folks,
Just blogged about some full trust features enabled using Silverlight 4 COM+ support.
Although I do agree with Shawn that adding COM+ to SL was a slap in the face to the cross-platform, write once run everywhere proposition. Even if they do add support for AppleScript, you’ll still have a spaghetti code nightmare. On the other hand… guns aren’t bad, it’s the people who use them. Right? ;-)
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Marlon Grech Sent: Wednesday, January 20, 2010 9:22 AM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Silverlight 4 COM+ Features
On Wed, Jan 20, 2010 at 9:53 AM, Dr. WPF <a...@drwpf.com> wrote: > +1 Fantastic article!
> Although I do agree with Shawn that adding COM+ to SL was a slap in the > face to the cross-platform, write once run everywhere proposition. Even if > they do add support for AppleScript, you’ll still have a spaghetti code > nightmare. On the other hand… guns aren’t bad, it’s the people who use > them. Right? ;-)
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > *Sent:* Wednesday, January 20, 2010 9:22 AM > *To:* wpf-disciples@googlegroups.com > *Subject:* Re: [WPF Disciples] Silverlight 4 COM+ Features
Well at least with this gun, people can only shoot themselves in the foot ;)
I've been trying to soak in all the controversy surrounding the COM interop and so far, I see it as a *good *thing. I will go as far to say that maybe they should of went even further...of course, depending on perspective.
If you consider SL as a AIR competitor, Microsoft has a leg up on Adobe with COM support. In AIR, if folks want to do p/invoke, they'd create some sort of local tcp service and send messages for communication for their service to execute.
If you were a hardware OEM running SL running inside a toaster oven, you'd be glad Microsoft added some sort of p/invoke so you could talk to your toaster oven's hardware. I suppose this would be the same idea behind Silverlight on a mobile phone.
If you just spent a zillion hours/dollars on a SL project, then after release you get a requirement that would be satisfied by something that COM interop gives you...well you just saved yourself having to rewrite your app in desktop .NET.
Write-once-run-everywhere is good in theory..and was great marketing material for Java, but a more honest phrase would be "Write once, run everywhere. You are free to do anything you want...just as long as you do it in your 8x10 [web] cell." We might like to think SL gives us a 100% consistent cross-platform runtime, but hw acceleration on the Mac is an example of this being untrue. In my eyes, write-once-cross-platform means, "I don't do much particularly well...but at least you only wrote it once!" Microsoft can't possibly give us everything under the sun in a trusted environment, so I'm glad they have an escape hatch.
The bottom line to me is COM is only supported in OOB + Elevated Permissions. If a dev has gone that far, they should know what the limitations of their application are.
On Wed, Jan 20, 2010 at 9:53 AM, Dr. WPF <a...@drwpf.com> wrote: > +1 Fantastic article!
> Although I do agree with Shawn that adding COM+ to SL was a slap in the > face to the cross-platform, write once run everywhere proposition. Even if > they do add support for AppleScript, you’ll still have a spaghetti code > nightmare. On the other hand… guns aren’t bad, it’s the people who use > them. Right? ;-)
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > *Sent:* Wednesday, January 20, 2010 9:22 AM
Well it's not called "Write once, run *well* everywhere" ;)
You make plenty of good points, Jer. I'm just not a fan of "Write once, test and rewrite everywhere"
Btw, if Windows is your target platform, there's a better option than both SL and AIR (but I'm not going to give you any hints on what it is).
And if you do need cross platform support, then I guess it's nice that you have a gun. (You don't really need two feet if you have good hopping skills! :-D)
-----Original Message----- From: "Jeremiah Morrill" <jeremiah.morr...@gmail.com> Sent: Wednesday, January 20, 2010 2:31pm To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Silverlight 4 COM+ Features
Doc,
Well at least with this gun, people can only shoot themselves in the foot ;)
I've been trying to soak in all the controversy surrounding the COM interop and so far, I see it as a *good *thing. I will go as far to say that maybe they should of went even further...of course, depending on perspective.
If you consider SL as a AIR competitor, Microsoft has a leg up on Adobe with COM support. In AIR, if folks want to do p/invoke, they'd create some sort of local tcp service and send messages for communication for their service to execute.
If you were a hardware OEM running SL running inside a toaster oven, you'd be glad Microsoft added some sort of p/invoke so you could talk to your toaster oven's hardware. I suppose this would be the same idea behind Silverlight on a mobile phone.
If you just spent a zillion hours/dollars on a SL project, then after release you get a requirement that would be satisfied by something that COM interop gives you...well you just saved yourself having to rewrite your app in desktop .NET.
Write-once-run-everywhere is good in theory..and was great marketing material for Java, but a more honest phrase would be "Write once, run everywhere. You are free to do anything you want...just as long as you do it in your 8x10 [web] cell." We might like to think SL gives us a 100% consistent cross-platform runtime, but hw acceleration on the Mac is an example of this being untrue. In my eyes, write-once-cross-platform means, "I don't do much particularly well...but at least you only wrote it once!" Microsoft can't possibly give us everything under the sun in a trusted environment, so I'm glad they have an escape hatch.
The bottom line to me is COM is only supported in OOB + Elevated Permissions. If a dev has gone that far, they should know what the limitations of their application are.
Just my take on it,
-Jer
On Wed, Jan 20, 2010 at 9:53 AM, Dr. WPF <a...@drwpf.com> wrote:
> +1 Fantastic article!
> Although I do agree with Shawn that adding COM+ to SL was a slap in the > face to the cross-platform, write once run everywhere proposition. Even if > they do add support for AppleScript, you’ll still have a spaghetti code > nightmare. On the other hand… guns aren’t bad, it’s the people who use > them. Right? ;-)
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > *Sent:* Wednesday, January 20, 2010 9:22 AM
It's a really good article, but - and I ask this not having tried the COM stuff yet - doesn't this represent a major potential security flaw. Unrestricted file system access?????
I wouldn't classify this as any more security risk than downloading and installing another 3rd party application. COM interop will only work in OOB _and_ with elevated permissions enabled. The end user installing the OOB is warned and forced to wait for a few second "cool down" period before he/she initiates the OOB installation.
The main *conceptual *security issue I see is that this is a mixture of "trust levels". The CoreCLR is still *not *in* full trust* mode, but any COM instance, by definition, runs outside the sandbox. I think this can be confusing to both developers and users who expect/assume one thing, but get another...which generally isn't good when you are talking about security.
On Wed, Jan 20, 2010 at 1:09 PM, Peter O'Hanlon <pete.ohan...@gmail.com>wrote:
> It's a really good article, but - and I ask this not having tried the COM > stuff yet - doesn't this represent a major potential security flaw. > Unrestricted file system access?????
> On Tue, Jan 19, 2010 at 11:45 PM, Justin Angel <J...@justinangel.net> wrote:
>> Hi folks,
>> Just blogged about some full trust features enabled using Silverlight 4 >> COM+ support.
Jer, Here's one question for you: Does the elevated trust also require Admin rights on the machine on which you install ? In other words, can a regular non-admin user install an OOB app with elevated trust and run COM interop code ?
On Wed, Jan 20, 2010 at 6:13 PM, Jeremiah Morrill <
> I wouldn't classify this as any more security risk than downloading and > installing another 3rd party application. COM interop will only work in OOB > _and_ with elevated permissions enabled. The end user installing the OOB is > warned and forced to wait for a few second "cool down" period before he/she > initiates the OOB installation.
> The main *conceptual *security issue I see is that this is a mixture of > "trust levels". The CoreCLR is still *not *in* full trust* mode, but any > COM instance, by definition, runs outside the sandbox. I think this can be > confusing to both developers and users who expect/assume one thing, but get > another...which generally isn't good when you are talking about security.
> On Wed, Jan 20, 2010 at 1:09 PM, Peter O'Hanlon <pete.ohan...@gmail.com>wrote:
>> It's a really good article, but - and I ask this not having tried the COM >> stuff yet - doesn't this represent a major potential security flaw. >> Unrestricted file system access?????
>> On Tue, Jan 19, 2010 at 11:45 PM, Justin Angel <J...@justinangel.net> wrote:
>>> Hi folks,
>>> Just blogged about some full trust features enabled using Silverlight 4 >>> COM+ support.
>>> Among the features listed are Full file system access, CMD access, full >>> operating system access, external devices access, Win7 API access, etc.
>>> -- Justin
>> -- >> Peter O'Hanlon
-- Pavan Podila, MVP - Client App Dev Author of WPF Control Development Unleashed --| http://blog.pixelingene.com |--
Elevated trust does not require admin rights. So a non-admin can install apps, but of course, all the install info goes into the HKCU, and files go inside folders off their home directory. An elevated trust SL app (with COM) has the same rights as any other app running under your user. So the OS still protects ya and you of course cannot register a COM component w/o admin rights.
On Wed, Jan 20, 2010 at 4:42 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
> Jer, > Here's one question for you: Does the elevated trust also require > Admin rights on the machine on which you install ? In other words, can a > regular non-admin user install an OOB app with elevated trust and run COM > interop code ?
> On Wed, Jan 20, 2010 at 6:13 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> Peter,
>> I wouldn't classify this as any more security risk than downloading and >> installing another 3rd party application. COM interop will only work in OOB >> _and_ with elevated permissions enabled. The end user installing the OOB is >> warned and forced to wait for a few second "cool down" period before he/she >> initiates the OOB installation.
>> The main *conceptual *security issue I see is that this is a mixture of >> "trust levels". The CoreCLR is still *not *in* full trust* mode, but any >> COM instance, by definition, runs outside the sandbox. I think this can be >> confusing to both developers and users who expect/assume one thing, but get >> another...which generally isn't good when you are talking about security.
>> On Wed, Jan 20, 2010 at 1:09 PM, Peter O'Hanlon <pete.ohan...@gmail.com>wrote:
>>> It's a really good article, but - and I ask this not having tried the COM >>> stuff yet - doesn't this represent a major potential security flaw. >>> Unrestricted file system access?????
>>> On Tue, Jan 19, 2010 at 11:45 PM, Justin Angel <J...@justinangel.net>wrote:
>>>> Hi folks,
>>>> Just blogged about some full trust features enabled using Silverlight 4 >>>> COM+ support.
>>>> Among the features listed are Full file system access, CMD access, full >>>> operating system access, external devices access, Win7 API access, etc.
>>>> -- Justin
>>> -- >>> Peter O'Hanlon
> -- > Pavan Podila, MVP - Client App Dev > Author of WPF Control Development Unleashed > --| http://blog.pixelingene.com |--
jeremiah.morr...@gmail.com> wrote: > Elevated trust does not require admin rights. So a non-admin can install > apps, but of course, all the install info goes into the HKCU, and files go > inside folders off their home directory. An elevated trust SL app (with > COM) has the same rights as any other app running under your user. So the > OS still protects ya and you of course cannot register a COM component w/o > admin rights.
> On Wed, Jan 20, 2010 at 4:42 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>> Jer, >> Here's one question for you: Does the elevated trust also >> require Admin rights on the machine on which you install ? In other words, >> can a regular non-admin user install an OOB app with elevated trust and run >> COM interop code ?
>> On Wed, Jan 20, 2010 at 6:13 PM, Jeremiah Morrill < >> jeremiah.morr...@gmail.com> wrote:
>>> Peter,
>>> I wouldn't classify this as any more security risk than downloading and >>> installing another 3rd party application. COM interop will only work in OOB >>> _and_ with elevated permissions enabled. The end user installing the OOB is >>> warned and forced to wait for a few second "cool down" period before he/she >>> initiates the OOB installation.
>>> The main *conceptual *security issue I see is that this is a mixture of >>> "trust levels". The CoreCLR is still *not *in* full trust* mode, but >>> any COM instance, by definition, runs outside the sandbox. I think this can >>> be confusing to both developers and users who expect/assume one thing, but >>> get another...which generally isn't good when you are talking about >>> security.
>>> On Wed, Jan 20, 2010 at 1:09 PM, Peter O'Hanlon <pete.ohan...@gmail.com>wrote:
>>>> It's a really good article, but - and I ask this not having tried the >>>> COM stuff yet - doesn't this represent a major potential security flaw. >>>> Unrestricted file system access?????
>>>> On Tue, Jan 19, 2010 at 11:45 PM, Justin Angel <J...@justinangel.net>wrote:
>>>>> Hi folks,
>>>>> Just blogged about some full trust features enabled using Silverlight 4 >>>>> COM+ support.
>>>>> Among the features listed are Full file system access, CMD access, full >>>>> operating system access, external devices access, Win7 API access, etc.
>>>>> -- Justin
>>>> -- >>>> Peter O'Hanlon
>> -- >> Pavan Podila, MVP - Client App Dev >> Author of WPF Control Development Unleashed >> --| http://blog.pixelingene.com |--
-- Pavan Podila, MVP - Client App Dev Author of WPF Control Development Unleashed --| http://blog.pixelingene.com |--
On a side note, I'm working on an experimental hack to allow execution of any desktop .NET assembly..without COM registration. This isn't easy considering you can only instantiate COM objects that a) Have a ProgId b) Support IDispatch, so you can imagine how hacky my solution is ;).
To give an idea, I created a native dll, which gets executed by rundll32 via the wshell script (wshell script comes with windows, works with SL com out of the box). I then inject the dll into the SL OOB process and do some method hooking on some ole32.dll methods. When SL code requests a "Fake.ProgId", my hook injects a desktop .NET proxy and returns the IntPtr from Marshal.GetIUnknownForObject(clrProxy). This gets returned back to silverlight and you can use the .NET object as you would any other COM object in Silverlight. It's a damn dirty solution, but it works. I'll let you guys know when I clean it up...so you guys can get a good laugh =P
-Jer
On Wed, Jan 20, 2010 at 5:16 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
> Thanks Jer. I may hit you with a few more trust related questions soon :)
> On Wed, Jan 20, 2010 at 7:47 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> Elevated trust does not require admin rights. So a non-admin can install >> apps, but of course, all the install info goes into the HKCU, and files go >> inside folders off their home directory. An elevated trust SL app (with >> COM) has the same rights as any other app running under your user. So the >> OS still protects ya and you of course cannot register a COM component w/o >> admin rights.
>> On Wed, Jan 20, 2010 at 4:42 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>> Jer, >>> Here's one question for you: Does the elevated trust also >>> require Admin rights on the machine on which you install ? In other words, >>> can a regular non-admin user install an OOB app with elevated trust and run >>> COM interop code ?
>>> On Wed, Jan 20, 2010 at 6:13 PM, Jeremiah Morrill < >>> jeremiah.morr...@gmail.com> wrote:
>>>> Peter,
>>>> I wouldn't classify this as any more security risk than downloading and >>>> installing another 3rd party application. COM interop will only work in OOB >>>> _and_ with elevated permissions enabled. The end user installing the OOB is >>>> warned and forced to wait for a few second "cool down" period before he/she >>>> initiates the OOB installation.
>>>> The main *conceptual *security issue I see is that this is a mixture of >>>> "trust levels". The CoreCLR is still *not *in* full trust* mode, but >>>> any COM instance, by definition, runs outside the sandbox. I think this can >>>> be confusing to both developers and users who expect/assume one thing, but >>>> get another...which generally isn't good when you are talking about >>>> security.
>>>> On Wed, Jan 20, 2010 at 1:09 PM, Peter O'Hanlon <pete.ohan...@gmail.com >>>> > wrote:
>>>>> It's a really good article, but - and I ask this not having tried the >>>>> COM stuff yet - doesn't this represent a major potential security flaw. >>>>> Unrestricted file system access?????
>>>>> On Tue, Jan 19, 2010 at 11:45 PM, Justin Angel <J...@justinangel.net>wrote:
>>>>>> Hi folks,
>>>>>> Just blogged about some full trust features enabled using Silverlight >>>>>> 4 COM+ support.
>>>>>> Among the features listed are Full file system access, CMD access, >>>>>> full operating system access, external devices access, Win7 API access, etc.
>>>>>> -- Justin
>>>>> -- >>>>> Peter O'Hanlon
>>> -- >>> Pavan Podila, MVP - Client App Dev >>> Author of WPF Control Development Unleashed >>> --| http://blog.pixelingene.com |--
> -- > Pavan Podila, MVP - Client App Dev > Author of WPF Control Development Unleashed > --| http://blog.pixelingene.com |--
