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


"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)