> You are assuming that the passwords are using two-way encryption. Which I
> believe that they aren't.
The passwords stored in the *application* have to be two-way encrypted or
else they can't be handed to the security subsystem to get a valid SID
back. Whether the token handed to the security subsystem is the password
itself or something derived from the password, it has to be stored somewhere
in a recoverable form or you can't authenticate yourself (either to log in,
run as a service, or impersonate a user (their equivalent of SU)).
> As far as traceability, although things can always be circumvented, NT
> allows for per file logging of each and any modification to a files
> contents.
Logging by itself buys you nothing. You need to have someone who can go
through the logs and detect an inappropriate access from context. If there's
a write to some-obscure.dll in the middle of what's obviously an install of
a program on a user's workstation, are you going to be able to tell that
it's a trapdoor? Programs install DLLs in system directories all the time.
In UNIX, it's very rare for a program to install a shared library in a
system directory... and you need to explicitly do the install as "root"
to do that... which raises a red flag. And since the install scripts are
almost always plain text you can look and see what it's going to do ahead
of time.
> So there can be traceability, just like UNIX. And the accounts
> aren't hidden, they show up just like any other account, and they can easily
> be seen as having administrative privileges.
Like logging, you have to know that these privileges aren't required for that
account... and if it is routine, as the message I'm responding to claimed, for
applications to install these accounts it's unlikely that you're going to
know if it's legit or not.
In UNIX if an application requires an account it will not just go ahead and
create it, and almost always requests you set up a normal, non-privileged
account.
> And of course accounts can be
> setup with only those specific administrative privileges that they need.
If they are "Administrator" accounts on a standard NT system they can boost
any other privileges they need, including backup... which lets them read
and write files as any user.
I'm sure this can all be fixed by a sufficiently determined system admin,
but a merely normally paranoid admin with a large number of systems is
unlikely to be able to get all the details right... and applications are
installed in such a way that if you take normal precautions you're simply
unable to operate because you're all the time patching special cases where
this or that application requires "dangerous" privileges.
This is, again, assuming that the original note that network applications
on NT "routinely" require such access is correct. Certainly my own experience
with what applications do during installation leads me to believe it's true.
References:
|
|
