[thelist] [OT] MS vs *nix WAS:( New Critical Security PatchforWindows)

[Ken Schaefer]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Shawn K. Quinn" <skquinn at xevious.kicks-ass.net>
Subject: Re: [thelist] [OT] MS vs *nix WAS:( New Critical Security
PatchforWindows)


: > : It's not just popularity. The Windows security model, even in
: > : Windows 2000, has fundamental flaws that need to be addressed.
: >
: >
: > Interesting - and what are these "fundamental" security flaws?
:
: One that sticks out in my mind is this:
:
: On Unix, a user has to run 'su' or 'sudo' to actually run commands as
: root (administrator). On the *BSD systems, that user has to also be in
: the wheel group (Richard Stallman has a reason for not implementing the
: wheel group in GNU su). It's considered poor practice to directly log
: in as root except when absolutely necessary.
:
: On Windows 2000, once a user logs in and is in the administrator group,
: it is as if they logged in as administrator all the time. That user
: cannot drop administrator privileges when they aren't needed and is not
: prompted for additional confirmation for actions that require
: administrator privileges.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'd like to address this on a number of levels.
a) it is wrong to say that an "administrator" cannot drop administrative
privileges
b) the Windows security model as you describe does not constitute a
"fundamental security" flaw
c) what actually constitutes a "secure" system
d) do Windows "administrative" privileges even exist?

(A) Windows offers a "runas" command that works in a similar fashion to su
in the *nix world. Someone logged on interactively with "administrative"
privileges can use "runas" to run an application under a different user
context, including one with fewer privileges. In a similar manner, a user
logged on without administrative priveleges can use runas to run an
application with elevated privileges. Thus it is incorrect to say that an
administrator can not "lose" administrative privileges. (obviously this only
applies to Windows OSes that have a concept of multiple users, such as
Windows 2000, rather than, say, Win9x)

(B) You described the above as a "fundamental security flaw". However, it
merely constitutes a different method of handling resource access
authorisation to what *nix users are familiar with. Windows works in a
different way when it comes to assigning privileges, and placing Access
Control Lists on resources. This trips up many *nix users who ask what the
Windows equivalent to CHMOD is. There isn't one. In the Windows world, users
belong to one (or more) groups. Groups are assigned permissions and
privileges. Your particular user account's priveleges are the sum of all the
permissions and privileges of all the user groups you are a member of. There
is no direct implementation of the concept of User | Group | World.

How do I know this is merely a different implemention of a secure
infrastructure rather than a fundamentally flawed system? For starters there
are independant standards for evaluating the security of software - the US
DoD Orange Book is a classic. Vendors can submit their software for
evaluation and receive a rating. Windows NT 4 (in certain configurations)
received a C2 rating.

(C) What constitutes a secure operating system?
To be a secure system, it must implement (at a minimum) 4 essential
subsystems:
    (1) Authentication. Each and every user must authenticate themselves as
a valid user of the system. This may be via the classic username/password
challenge, by smartcard, or even programmatically in the case of software
invoking other software. Each and every process or operation *must* run
under the context of a user account. Additionally, no user of the system may
be able to subvert this authentication process.

    (2) Authorisation. The authenticated user must have explicit permission
to use the resource, or to create the token, or start the process requested.
It is not enough that the user be authenticated. The user must also be
authorised to perform the requested action. The software must keep a
comprehensive list of ACLs on resources, and a list of possible actions to
be invoked and check the user's permissions against this list. No user may
be able to subvert this.

    (3) Auditing. Each and every action performed (resource access, token
creation or process invokation) must be auditable (either for success or
failure). Comprehensive logs can thus be created for each and every minute
action performed, even changing the audit policy. This allows a complete
trail to be created of all the actions performed on the system. Additionally
no user may be able to subvert this auditing.

    (4) Non-repudiation. No user can deny that are certain audited action
was in fact performed by that user account. The auditing procedure itself
must be invulnerable to subversion so that a user can not cast doubt upon
the veracity of the audit log.

Whether or not an interactively logged in user is an administrator or not,
or can drop admnistrative privileges is thus irrelevant to the discussion of
whether a system is secure or not. Thus, I fail to see how your example
shows a "fundamental flaw" in the Windows 2000 security systems.

(D) Windows Administrative privileges:

: On Windows 2000, once a user logs in and is in the administrator group,
: it is as if they logged in as administrator all the time

Administrator privileges that you speak of (I'm assuming things like "act as
part of the operating system", "create a token object" etc) can be revoked
on a group-by-group or user-by-user basis. So just because a user is in the
"Administrators" group doesn't mean they have "administrative" privileges,
because there's no such thing. There is a default assignment of priveleges
to the local "Administrators" group, but that can be altered. For example,
you can edit the local security policy to deny "take owernship of files or
other objects" rights to Administrators.

Taking this concept a little further (namely that there is no such thing as
"administrative privileges" per se) explains why there are groups called
"Schema Admins", "Domain Admins", "Enterprise Admins" and so forth in an AD
environment. Not all "Administrators" are the same. There is no such thing
as the monolithic "administrative" privileges that you allude to.

Cheers
Ken

Microsoft MVP - Windows Server (IIS)