Re: Queries regarding DCOM Security Enhancements in Windows XP Service Pack 2

Perhaps you are looking for .NET? You can't restrict a
DCOM server as to what it can do at the machine it's
runing on - the server can do anything the account it's
running under is allowed.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Enquiring Mind" <Enquiring.Mind@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:Ovq0srsSHHA.5068@xxxxxxxxxxxxxxxxxxxxxxx

"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:OYgQ7uhSHHA.4260@xxxxxxxxxxxxxxxxxxxxxxx
I think your viewpoint is skewed. The situation is like the
following - machine-wide DCOM security belongs to the
administrator, while server security lies with the developer.
If you require certain level of security, you are asking the
administrator for it. If the administrator says they can't allow
certain unsafe practices, that renders your server unsuitable
for that machine automatically so the machine security isn't
compromised. Your server simply can't work on that machine.
Once you wrap yourself around the idea that the administrator
dictates the security - not you - it should all fall into place.
Specifically what you are describing is a perfect use case
scenario why an administrator should _not_ allow your server
to run. Your server requires a dedicated machine which
when compromised won't compromise other servers as well.
(It should also probably be placed in isolation from the rest
of the network.)

Thanks for bringing to my attention that particular security policy. To my
mind it seems to err on the defensive side. But then I am new to the
topic of security, my primary aim being to get a simple client-server
application built on top of DCOM up and running in a Workgroup network (my
own, as it happens!). So the following comments may betray ignorance of
what the risks and threats that the "defensive" security policy is seeking
to minimize really are.

I can see that if the computer administrator, due to a lack of any
knowledge whatsoever about the server application that is installed on his
computer, is not in a position to trust it, he should set the computer
wide restrictions (or, better, the server-specific restrictions) at a
stringent enough level to inhibit the running of malware. However if the
server application is from a trustworthy software source, or from a
company developer, the administrator should be able, in my opinion, to
assign to that specific server more relaxed restrictions that he/she
considers appropriate to the types of functions that the server can
actually perform, thereby overriding more stringent machine-wide
restrictions. The situation seems comparable to that of a firewall. If an
application is trusted or not security-critical, an administrator feels
comfortable with including it in the list of firewall exceptions, thereby
relaxing its accessability.

In the particular instance of an administrator faced with installing a new
server application from a new, as yet untrusted, source, if he wishes to
pursue a particularly cautious approach, he could initially install it on
a 'quarantine' computer dedicated to testing new servers, and monitor its
behaviour. Once the administrator is satisfied that the server is "safe",
i.e. does not constitute an unacceptable security risk, he should feel
comfortable about moving it to a 'production' computer and applying to it
the security settings that are appropriate to what the server actually can
do, as opposed to what an unknown, untested piece of software could do in
a worst case scenario.

For example, if the server application does not need to access the host
computer's file system, and does not need to know the identity of users
that launch client program instances, because that is not relevant to the
server's functionality, then why specify user authentication, and restrict
launch and access rights to a list of identified users?

In another situation, the security implemented by the operating system may
not be adequate for the client-server application, and the client and
server applications may need to carry out their own security checks (as is
common in database applications and web applications). It is often the
role of the server, rather than of the oeprating system, to maintain a
directory of registered users and their respective roles. In such a case
why encumber the application with additional security that it doesn't need
and is not particularly relevant?

Finally, what the server can and can't do is also dictated by the server
Launch Identity rights. Can these be set so as to ensure that even if an
untrusted server is launched without client user authentication, there is
very little it can do to damage the system?

Regards,

Enquiring Mind


.



.

Relevant Pages

  • RE: Cant set Local Security policies. They fail to save
    ... I followed your instructions on applying the predefined security templates. ... I still can’t set any of the local security policies on the server box. ... > using local Administrator account to test, ... >>> member of either the Remote Operators group or the Domain Power Users ...
    (microsoft.public.windows.server.sbs)
  • Re: UnauthorizedAccessException when using MSDTC
    ... dispatcher2 is the user logged on the client pc. ... Event Source: Security ... Object Server: SC Manager ... Primary Domain: BLITZ ...
    (microsoft.public.data.ado)
  • Re: Routing and Remote Access - Authentication Failure
    ... because the real client computer can tunel through it's local NAT router, ... travel the Intrenet, join the VPN and access the server, when this feature ... Their security system decided that the server was trying to steel ...
    (microsoft.public.windows.server.networking)
  • Re: WCF security advice (and clarification) needed
    ... You, the client, resolve the foo.mycompany.com hostname within your ... TCP/IP) with that ticket as the security token. ... There are two parties participating in a security scenario, the server ... HTTP supports other authentication ...
    (microsoft.public.dotnet.framework.webservices)
  • RE: Problems with security requirements in Windows WorkGroups.
    ... "A remote side security requirement was not fulfilled during authentication. ... small chat application between a client and a server ... When I try to use the TCP channel I get the error (with NO inner exception ...
    (microsoft.public.dotnet.languages.csharp)
Loading