Questions about the artical "DCOM Security Enhancements" for Windows Server 2003 SP1

Posted by hshen.ca on January 15, 2006, 9:47 pm

Please log in for more thread options

Hi,

A remote DCOM gives access denied error in our program after the server
is upgraded to the SP1. The article "DCOM Security Enhancements" seems
to address this issue
(http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/4c9a2873-2010-4dbb-b9dd-6a7d1e275f0f.mspx).
But I am quite confused. Here are my questions:

1. Is the "Computerwide restriction" the same thing as "machine-wide"
restriction used before but with different semantics?

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)

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.

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
the remote launch and activation permission but has the remote access
permission. And the doc mentions that:

"By default, the Everyone and Anonymous groups are granted remote
access permissions. This enables most COM client scenarios, including
the common case where a COM client passes a local reference to a remote
server, in effect turning the client into a server."

What does this paragraph really mean? Is it in some language other than
English?

Thanks for your help
hshen

Posted by Roger Abell [MVP] on January 16, 2006, 12:41 am

Please log in for more thread options

I will take a try at your questions, but do not take these
as the final word . . .

show/hide quoted text
(http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/4c9a2873-2010-4dbb-b9dd-6a7d1e275f0f.mspx).
show/hide quoted text

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.

show/hide quoted text

The Component services UI was enhanced for the new settings

show/hide quoted text

I take activation and launch to be the same, i.e. to spin up a server obj.

show/hide quoted text

some other security principal launched the factory, and then, with it
running the account with only access does just that

show/hide quoted text

That a reasonable question.
I take it to mean, we are controlling how a COM factory gets spun up,
but are not controlling what happens to it at that point.
Again, this is for components with their security defaulted.

show/hide quoted text

Posted by hshen.ca on January 16, 2006, 9:49 am

Please log in for more thread options

Hi Roger,

Thanks for your quick response. My comments and questions are inline

Thanks!
hshen

Roger Abell [MVP] wrote:
show/hide quoted text
"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.

show/hide quoted text
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)?

show/hide quoted text
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?

Posted by Roger Abell [MVP] on January 16, 2006, 3:13 pm

Please log in for more thread options

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
show/hide quoted text
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. . . .
show/hide quoted text
but one can also find
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/3474f8ad-f041-4886-ad39-ff0603c5c69e.asp
show/hide quoted text
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.
show/hide quoted text

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.

show/hide quoted text

Posted by hshen.ca on January 16, 2006, 4:04 pm

Please log in for more thread options

Thanks!

Roger Abell [MVP] wrote:
show/hide quoted text
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/c9f6d06c-da24-48ea-908a-2462c33f7ee3.asp
show/hide quoted text
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/3474f8ad-f041-4886-ad39-ff0603c5c69e.asp
show/hide quoted text
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/88c94a7f-5cf0-4d61-833f-91cba45d8624.asp
show/hide quoted text