|
Posted by hshen.ca on January 16, 2006, 4:04 pm
Please log in for more thread options Thanks!
Roger Abell [MVP] wrote:
> Thanks for the clarification.
>
> On your last point, it is not the client application that needs to do
> everything
> (launch and then access). The component can be instanciated by other code
> in different security context, perhaps not ever remote.
> Access controls access - which implies component has been spun up.
> Remote client does not have to do it all. Consider case of a service that
> makes its remote methods available by instancing components. You do
> not want the remote client to cause the instancing, but only the use.
>
>
> On the Launch vs Activation you are right, things really are clouded in
> the docs, are they not. I notice in current MSDN on-line lib one finds
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/c9f6d06c-da24-48ea-908a-2462c33f7ee3.asp
> <quote>
> Activation security (also called launch security) helps control who can
> launch a server. Activation security is automatically applied by the Service
> Control Manager (SCM) of a particular machine. . . .
> </quote>
> but one can also find
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/3474f8ad-f041-4886-ad39-ff0603c5c69e.asp
> <quote>
> If the client does not specify an explicit COAUTHINFO structure and
> instead sets the pointer to NULL, COM will attempt to authenticate the
> client. If it cannot authenticate the client, COM checks the launch
> permission
> security descriptor to see whether there is a NULL DACL or an ACL that
> allows access to Everyone. If this check succeeds, the server is launched.
> Therefore, even if the client does not specify a COAUTHINFO structure,
> unsecure activation may take place when the server allows it.
> </quote>
>
> Roughly speaking (as a non-Com-programmer) it seems to be saying that
> to use a component there are two things involved. Getting use of the
> methods
> of the component and the other getting the RPC transport established for
> this.
> It is sounding like activation is a function of the last. If it is not in
> use then only
> the prior call based security governs what does or does not happen, while if
> it is in use it functions much like share level permissions do for remote
> access
> to NTFS storage in that one must first pass that check and it sets limit of
> what
> call-level can allow.
> You might want to check the notes for the coserverinfo structure, and
> notice
> how it may be used to alter the credentials or auth methods used by RPC and
> hence subsequent COM calls
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/88c94a7f-5cf0-4d61-833f-91cba45d8624.asp
>
> Again, I am not a COM programmer.
>
> > Hi Roger,
> >
> > Thanks for your quick response. My comments and questions are inline
> >
> > Thanks!
> > hshen
> >
> > Roger Abell [MVP] wrote:
> >> > 1. Is the "Computerwide restriction" the same thing as "machine-wide"
> >> > restriction used before but with different semantics?
> >> >
> >>
> >> I take computer-wide and machine-wide as stating the same.
> >> However, I am not familiar with what you refer to as "used before".
> >> The service pack added a new layer that did not exist before.
> >> Previously there was (and there still is) a set of default permissions
> >> for launch and access. Previously (and still) components could have
> >> set their own component unique permissons for these, or could not
> >> and so default. The new layer controls use of defaulted components.
> >>
> > "Before" means before SP1. I knew that the machine-wide default
> > settings are there before SP1. But the semantics are different before
> > and after, that is the source of trouble (or benefit) of SP1. Before
> > SP1, the default settings take effect only when the components do not
> > customize their own settings. In SP1, the default settings play the
> > role as bottom line - means that if the default settings denies the
> > request, the request will fail no matter what is set in the component
> > customized settings.
> >
> >> > 2. If I am so desperate to change the "computerwide" settings, should I
> >> > do it the same way as change "machine-wide" settings? (through
> >> > Component Service, properties of the interested machine)
> >> >
> >>
> >> The Component services UI was enhanced for the new settings
> >>
> >> > 3. What is the difference between launch permission and activation
> >> > permission? To me, both are the permissions that allow a client to
> >> > create a server object on the server machine.
> >> >
> >>
> >> I take activation and launch to be the same, i.e. to spin up a server
> >> obj.
> >>
> > Then, why does Microsoft bother to have two separate permissions for
> > launch and activation (for Windows Server 2003 SP1 as well as Windows
> > XP SP2)?
> >
> >> > 4. Most confusing part is here. If a remote client does not have the
> >> > remote launch/activation permission, how could s/he possibly access a
> >> > remote DCOM object? The default setting is that Everyone does not have
> >>
> >> some other security principal launched the factory, and then, with it
> >> running the account with only access does just that
> >>
> > Still not clear to me. Do you mean that the client program uses one
> > account with high privilege to launch/activate the remote object and
> > then fallbacks to common user account to access the object? I don't
> > think that this scheme provides any security benefit. Where does the
> > client program get the high privilege security credential? If the
> > client program can get it without human involved, a malicious user can
> > get it either (at least in theory).
> > Another possible scenario is that somebody launches the factory in
> > remote server, and somehow let the remote access the factory object. I
> > am puzzled how to do it?
> >
| 
XML Sitemap