Built-in admin account

[Kurt Harriger]

You're right, MS doesn't have anything better (or really comparable). But
it really is with the best of intentions ... SUID fights with the
user-based security model. A user EITHER has the permissions they are
assigned OR the permissions assigned to a program (which takes precedence
with SUID). There is really no middle way here, following a strict *nix
implementation.

Gosh, imagine if malwares could drop programs and SUID them as
administrator ... where even GUESTS, anonymous users, and the like could
run the program with full rights! Imagine the ruccus people would make!
"How could Microsoft allow such a mechanism," they would cry!

SUID should not just be some attribute that follows around and is granted
simply by copying it to the machine. Perhaps a trusted install location
where execute file permission is not "inherited from parent" and a
management tool like services that allows administrators to enable suid
specify the user to run as AND who can access it.

Malware could also install a windows service that is accessible to all users
and as a bonous windows will even start the services automatically. Unless
the service (such as SQL) provides some sort of security configuration tool
the only control the administrator has is what user the service runs as not
which users can access it. Services are IMHO SUID applications that require
custom security configuration tools to manage access.

As for windows' security model being broken ... I would say the model
itself is fine conceptually - it makes sense and is consistant with itself
However, nobody wants to USE the security model (either users or
programs) - that is the problem. And, it definately could be improved
upon.

Before Vista, Windows looked at securty strictly at the granularity of the
user logon, even though under-the-coveres it is applied per-process. When
a user was logged on, everything had that user's power. This is a problem
when most of your desktops are running as administrator - because that
effectively nullifies almost ALL of Windows security. Windows really has
an amazing security infrastructure, but few utilize it .

IMHO, MS is in DENIAL that the everyone CAN USE the current security model.
In tightly controlled environments where users have desktop machines and
administrators are available when users must perform an administrative task
they will do whatever is necesary to make it work. However many smaller
companies cannot afford the overhead and even if they would like to run
users as standard users it is just not practical. Likewise with laptop
users where an administrator cannot follow the user around to be there when
the user needs to perform some administrative task it just isn't practical.

There was a poll I saw at one time "In what percentage of of desktops that
you manage are the users administrators?" followed by "On Windows Vista,
what percentage of desktops that you manage will be administrators?"
http://blogs.msdn.com/uac/archive/2006/07/28/susan.aspx. Although poll is a
rather small sampling and non-scientific it appears that at about half of
those that currently grant their user administrative accounts have a desire
to change this. What might actually be more interesting to see is if any of
those users that expressed the desire to change this were actually sucessful
in doing so after deploying Vista.

Now, Vista is looking at security at the granularity of the process (which
is as granular as the current model supports). Microsoft is paving the
road to allow for more control in this area, and I really hope they
continue to do so.

I imagine the day where ADMINISTRATORS (whether a fully-privileged
superuser or some lower-level admin that only has a subset of full
privileges) can log in with their privileged account, every-day, for EVERY
TASK, and with NO application compatability problems, and find the idea of
creating a seperate account for normal use for "security purposes" insane
because it is not necessary.

We are certainly getting there with Windows Vista ... I use my admin
account today, every day, and feel very secure knowing I am getting the
same benefits of running as a standard user, and there is no REASON to
seperate my accounts.

However, as you point out, most programs that I use that need admin
permission get TOO MUCH admin permission. And there are still tons of app
compat problems.


LOL. Well of course ... if you don't have a privilege, and you NEED it,
you are up a proverbial creek. Perhaps you should bribe your boss to
assign you the privilege ... with some cookies?


You're right, the "administrators" group is meant for "god" like
super-powers. If Windows did not allow SOME kind of account that could
perform these actions, then NOBODY would have been able to do them.

I think what you object to here is ALL privileged users being part of the
"administrators" group. This is not necessary, has NEVER been necessary
(except to deal with poorly designed third party apps), and SUID has NEVER
been needed for this to happen.

You use privileges and permissions to define WHAT a person can do. You
used SUID to define HOW they can do it. Windows doesn't have the HOW in
the form of SUID (because it can affect that WHAT too much) ... but it has
always had the WHAT.


True. That is why nobody should have the admin passwords in a corporate
network except those people who are required to have the privileges.

Agreed. However the user still needs to be able to perform his job.
For example, a travelling sales guy has an online meeting with the client in
10 minutes, but when he navigates his browser to the meeting place finds out
that he needs to install an updated meeting control and is unable to do so.
He gives you a call and how important this is. The ActiveX control does not
require administrative privilages to run but the user still requires
administrative privilages to install it. Since he is currently on the road
you can't walk over to his computer and provide over-the-shoulder
administative credentials. What would you do?

Vista does not change the "administrative password" requirement and UAC's
requiresAdministrator may even make an administrative password even more
necessary.

Windows has never had an administrative password requirement. Third party
apps, perhaps. But not Windows.

You can't start limiting privilege usage for programs, or even change the
Windows security model THAT MUCH, if the programs don't adhere to the
security model to begin with and WON'T RUN if they don't have God-like
superpowers.

UAC should start to reverse this behavior, and once apps start to get in
line, it should be much easier for Microsoft to further fine-tune the
security model.

However, after considering your statement about requiresAdministrator ...
you are RIGHT! This kind of suggests a sharp seperation between ADMIN vs.
NON-ADMIN that doesn't really exist.

One of the aims of UAC, as I see it, is to loosen in the grip of assumed
privileges made by programmers ... but this sort of REWARDS IT ... Two
steps forward and one step back, I guess.

Microsoft should have made programs define what privileges they need, and
then if a user account didn't have those privileges, it should ask for the
user/pass of a user with those privs that are needed to log in and approve
the action.

With UAC, an app has two easy choices - it can tell Windows that it needs
ALL PRIVILEGES (requiresAdmin) *which SHOULD NEVER BE THE CASE and SHOULD
NOT be an option at all!*, or that it needs NO PRIVILEGES, and Windows
will then take care of everything for it - elevation, and all that jazz.

For an app to be implemented correctly - using the UAC mode AsInvoker - an
application is pretty much telling Windows that it will handle security
itself, and then gets NO HELP from Windows whatsoever! It has to do a lot
more work to determine if the user has only the privileges they need to
perform the action, and if not, to manually ask the user for some other
user with the correct privileges - In effect, an applications has to
RE-IMPLEMENT UAC behavior itself if it wants it to work correctly outside
of the two extremes, full privs and no privs!

Luckily, however, programs that use requriesAdministrator will always
throw up that consent prompt. Hopefully many programs will [correctly] use
asInvoker instead and work within the bounds of what privileges the user
has, as this will not throw a prompt unless the user is logged in as an
administrator.

Still, I'm sure that many programs will simply use requriesAdministrator
when it is incorrect to do so!

UAC in its current behavior is *STILL* letting apps get by with not
working correctly unless they are being ran in a full-privileged
administrator account, just in a different way! What a pity ...

I can't believe I didn't catch that before .

Man, you hit the nail on the head about increasing the need for admin
passwords in Vista ... I hope MS changes this behavior in a future
version of Windows.

I'm open to alternative suggestions.... but SUID works and I haven't
really heard any better ideas.

SUID conceptually really doesn't need to be changed that much. The Windows
architecture would need to be changed, but not much at the lowest levels.
The big thing that would need to be changed is applications and the way
applications are installed - they would need to describe to the OS exactly
what privs they need to run, and what securable objects they need access
to.

I imagine MS could make a tool that would help automate the process of
defining what privileges a program needs, and make it very easy for a
program to set this up using Windows Installer.


Step 1 -> Define the privileges of the user

Windows already does this.

Step 2 -> Define the privileges the application needs

I would do this using the same low-level privilege/permission structure
Windows already utilizes for user permissions, with some differences
higher up the abstraction layer to enforce the correct security model.

Every .EXE (or anything else that translates into a process, such as a com
component) would be assigned a unique security identifier (takes the place
of a user account in SUID), and these security ID's would then be assigned
into logical groups that represent applications (for example, there could
be a MICROSOFT ACCESS application group that is linked to the .exe's / com
component security ID's installed with MS ACCESS, which could itself
further be a member of the MICROSOFT OFFICE application group).

It should be mandatory that the installer create at least one root
application group, in the name of the application (or app suite), and that
all further applications groups and .exe security identifiers be children
of this mandatory group.

An application cannot make its application groups or its .EXE's a member
of another application group, unless another application has pre-approved
this process using digital signatures to uniquely identify another setup
program that has such access.

As an example, you install Microsoft Access by itself, and the Access
installer sets up the Microsoft Office program-security heirarchy, but
only installs Access. If you then install Excel, Excel should be able to
install it's EXE's and application groups into the Microsoft Office
application-security group, and can prove this by using digital
signatures: when Access is installed, it can tell the OS that any program
with digital signature X has permission to add itself to the Microsoft
Office application group, and then all the MS Office app installers will
have digital signature X.

Also, every file should have two owners - a user owner and an .EXE owner.
During installation of an application, all files created by that installer
should be program-owned by either the application group of the app, or an
.EXE file that is installed.

Also, any file created will be program-owned by the .EXE associated with
the process that creates the file.

In this way, Windows and admins knows WHICH USER created files on the
computer AND which application created/owns a file.

In essense, security-wise, an application (an abstract concept) consists
of executable things that turn into processes that have defined the
privileges they need, and applications may further be a part of
application suites.

Durring application installation, setup would create this application
group / .exe security hierarchy, and then perform the following actions
for every .exe/com component it creates:

1) Create the securtiy identifier for the .exe/com component. The .EXE /
COM object won't run without one of these.

2) Define what privileges are needed by assigning them to the security
identifier (SeDebug, etc)

3) Define what access the security identifier must have to securable
objects (registry, files, etc) by adding ACLs onto those securable objects
granting the desired permission to the specific .exe's / com components
security identifier

This must be done per EXE, not per application group. Application groups
are to be used by the system administrator - they ONLY contain EXE's / Com
components and they are for administration purposes only.

So, Windows now knows what privileges specific EXE's / com components need
to run, but even better, Windows also knows what the abstract thing
"Application" consists of (what privileges it needs OVERALL, and exactly
what files, registry keys, etc it consists of or were created using it),
which is what we need to know as administrators.

Step 3 -> Allow constrainment of user privs and perms

The user token should be modified so that it can contain per-application
constrainments on the privileges assigned the user. For example, the user
token can say "SeDebug for <application security ID for Vistual Studio>".

Also, permissions assigned to securable objects can be constrained in this
manner ... i.e. permission could be applied to the HOSTS file for user
John to have write access only from the program security ID for notepad

Step 4 -> Security subsystem modifications

Now, let's talk about how this beast works when running.

1) When a process is created, it contains two security tokens - one for
the user, one for the .EXE/com component.

The constrainment of the user token also happens at this time - any
privileges inside the user token that aren't applicable for this program
are ignored.

If the .EXE contains more privs than the user token, UAC can either prompt
for credentials, access is denied, or continue to let the program run and
deny it or prompt for UAC authentication to the privileges when requested.
The .EXE should dictate how it wants to proceed in these cases.

Also, privileges may be marked in group policy as ALWAYS require consent -
in this case, whenever an app is about to be granted privileges on this
list, UAC is prompted for consent.

2) When code running inside of a process attempts to access a securable
object (registry key, file, etc), the security subsystem looks at both
what the user can access and what the program can access to determine what
action to take.

Permissions on the object that don't apply due to constrainment are
ignored. For example, if the process is Notepad (which is we'll say a
member of the application group Windows Utilities), and there is a
permission that only applies to the user when running Microsoft Office,
then that permission is ignored.

- If the user *or* the program is denied access, access is denied.
- If the user *and* the program are granted access, access is granted.
- If the user is GRANTED access, but the program is NOT GRANTED (and not
denied) access, UAC might pop up for consent or return access denied,
depending on system configuration.
- If the user *and* the program are NOT GRANTED (and not denied) access,
UAC might prompt for credentials or return access denied.
- Otherwise, access is denied.

Also, an action on a securable object should be able to be marked "Always
require consent". In this case, if both a user and an app have permission
to the file, consent is still requested before it is authorized.

Step 5 -> Administration

I can invision a nice administration UI that would be like a super
permission and privilege editor. You would be able to view and edit
privileges and permissions applied to a user or user group.

In privilege editor mode, the privileges applied to the user/user group
would be visible, both overall and the constrained privileges per
application (or even .exe).

In permission mode, you would be able to select the User (or user group)
and see every file/folder/registry key the entity has access to overall,
with the files they have access to but are constrained to a certain
application displayed differently, and the files they do NOT have access
to again displayed differently, with the option to show/hide each type.

You would also be able to narrow down permission mode to view/modify only
the selected user/user group's permissions when using certain applications
(or even individual .exe's) - this allows you to easily create constrained
permissions. In this mode, the UI would only show the files that the
selected application group/exe needs access to (as defined when the app
was created), all other files would be hidden. The files the user has
access to when using that application would be showed differently than the
files the user has no access to when using that app, and the UI would
easily allow the administrator to modify how the selected user/group has
access to those files.

You should also be able to move the focal point from the viewpoint of user
to the viewpoint of the application - i.e. show what privileges all users
in the system have when using a specific app or exe, as well as show all
the files/folders that an app has access to and what users can access
those files when running the app.

I agree this model would be a significant improvement.
So why didn't MS implement this instead?

Wow, you're right ... I believe this is a bug.


It is complex, but the abstraction is pure. I think it could be done and
administrated at a high-enough level on the abstraction layer to make it
managable.

I think it will take a few iterations to get right, .NET CAS is very
powerful but is too complex for the average user to understand or manage.
..NET 1.1 simply denied ability for internet applications that required more
permission to then the default zone to execute so rather then allow the user
to change the permissions to fit the desired application they came up with
ClickOnce which allows the user to install the application granting it
fulltrust instead, despite its flexibilty very few .NET applications
actually use CAS and many .NET developers don't even know it exists, I think
the security config was actually moved into the SDK because no one uses it.

The user knowing the admin password has never been the windows security
model. If you are referring to home users, with few exceptions, they ARE
the administrator - this is inevitable. If you are referring to
corporations, most have NEVER (I would hope) allowed their users (and most
administrators with limited privileges) to know the admin password.

Except in tightly controlled environmetns many users do have administrative
rights on their local machine. The poll I mentioned above shows nearly 80%
of users have administrative user accounts. Even without administrative
accounts user's machines are concidered to be insecure, secure resources are
placed on servers locked up in secured rooms, protected by firewalls, users
are only allowed to talk to the application server and the application
server will perhaps go through yet another firewall to update an SQL server
to prevent users from directly accessing these services. Users don't talk
directly to services they talk to application servers, even file servers now
days have increasingly become SharePoint sites instead.

Prompting at too specific of a level can lead to too many prompts; not
prompting at a specific enough of a level can lead to too little prompts
that authorize too many actions. It's a bit of an impossible juggling
act..


This is a TOUGH cookie to crack, and this problem isn't going away any
time soon. This is why I believe UAC will ALWAYS be there in some form.

I think it would be possible if the application had a security token also.
An application that does not have privilaged permissions would be prevented
from launching one that does and even prevented from sending messages to an
application that does (ie cannot send keys to windows explorer to launch
one).

Agreed, however UAC already accomplishes this - only it is limited to two
privilege levels, non-admin and Admin.


LOL, it's not as bad as SUID, but due to the requiresAdministrators
behavior I have to agree.

We both agree a better model is needed. SUID may not be it, but I think it
is better then using custom services.

 

[Jimmy Brush]

SUID should not just be some attribute that follows around and is granted

simply by copying it to the machine. Perhaps a trusted install location
where execute file permission is not "inherited from parent" and a
management tool like services that allows administrators to enable suid
specify the user to run as AND who can access it.

Agreed, there are many ways to mitigate the problem. But SUID simply can't
exist inside Windows as-is; Windows must be re-architected to support the
model, and it will look differently than SUID does in *nix. Not knowing
enough about the *nix architecture I can't really make a comment as to how
well SUID fits in with it - but I have serious doubts about this.

Malware could also install a windows service that is accessible to all
users and as a bonous windows will even start the services automatically.

Agreed - anything that can be done via an SUID app could also be done via a
service. I used a bad example here.

Unless the service (such as SQL) provides some sort of security
configuration tool the only control the administrator has is what user the
service runs as not which users can access it.
Services are IMHO SUID applications that require custom security
configuration tools to manage access.

Well, I was waiting for you to point this out . Yes, services in Windows
ARE an implementation of the SUID model. But services *ARE NOT* SUID apps,
and Windows HAS NO equivalent to SUID, which is why you would have a hard
time managing services thinking they are SUID.

The difference between services and SUID apps is the layer at which they run
and what they are for. Services ARE the operating system, they implement
functionality in a privileged environment that is exposed to applications
[the user]. Applications ARE the user, they run with the privs of the user
to consume OS services. This seperation of privilege is enforced by Windows
at a very low level, and it is safe to say that only maldesigned services or
the OS can leak privileges unexpectedly to the user.

SUID is for constraining how the user can utilize a privilege, but it
doesn't fit with the Windows architecture as implemented in *nix. You can
have SUID-like behavior using services, but as you point out, that's not
PRECISELY what services are for. If you want to do so using services, you
have to be a programmer - you can't modify a pre-existing service or
application to do this.

Windows does not have SUID because it was not designed to. Tacking it on to
Windows without molding it into the Windows architecture is simply an
unthinkable act that, although could be useful, ends up destroying the
seperation of privilege created by the current Windows architecture,
resulting in a big security-flawed mess.

A service running in the context of a user account is technically "OK"
(albiet this is certainly a stretch of the imagination) because the user
accounts are always constraining the full privileges of the OS. Services ARE
the OS, and if it wants to artificially limit the access it has to itself,
the more the merrier.

SUID apps essentially are Windows Services in an application form. Since
users ARE the applications they run, the user essentially becomes the OS
when running the SUID app. Although the power of an SUID app may be
constrained in some fashion via the user account it runs under, just like
services can, they still inherit their "power" from the OS, not the user,
which is what breaks things.

The intent of SUID is to give the user privileges constrained only to a
certain app. And it APPEARS to do so in a windows environment - but this is
not so. Until Vista, Windows has *NOT* seperated privileges between
applications ran by the user. Although this model has changed in the Vista
timeframe, there are still incongruencies between the SUID model and the
Windows model that must be worked out to ensure a bulletproof SUID
implementation.

This is why I say privilege escalation is unavoidable in this scenario.
Windows views all the applications that a user is running AS THE USER,
because this IS the Windows model. Before Vista, there was very limited
seperation of privileges between apps on the user's desktop, because this
simply wasn't necessary. Remember, back then, all apps had the same privs
(whatever was assigned to the user) - no reason to enforce any sort of
seperation. The primary seperation of privilege line is drawn between
applications and services/OS, NOT between applications running on a user's
desktop, and even in Vista where lines do exist here, they are not quite
what is needed for SUID-like behavior.

If a user were to run an app with higher privileges on their desktop (which
was the case where services show UI's onto the screen, which Vista now
prevents), it was pretty trivial for the user through applications (or
applications of their own volition) to use those higher privileges that have
presented themselves on their desktop in any way they wanted. Once a
higher-privileged app appeared on their desktop, the user could use those
higher privileges outside of the constrainment intended by the application.

This is why I say that whenever you break the security model privilege
escalation is ALWAYS possible - because the entire system depends on this
model, and when you break it, things no longer fit, and privilege escalation
is the end result..

This is why I say SUID is conceptually flawed in the context of the Windows
model, precisely because it doesn't follow the Windows model, and that the
Windows model has to change to make this happen .

It is only NOW, in Vista, that the notion of different privilege levels is
starting to be enforced inside of a user account, thru UAC. The Windows
architecture is slowly being adapted in such a way that SUID-type behavior
won't break it - it's not quite there yet, but it is getting there, and
that is why I am hopeful that in the future we will have this wonderful
feature, in a nice and secure manner .

IMHO, MS is in DENIAL that the everyone CAN USE the current security
model. In tightly controlled environments where users have desktop
machines and administrators are available when users must perform an
administrative task they will do whatever is necesary to make it work.

If you want users to be able to perform an administrative task, then give
them the privileges to do so. That IS the windows security model. You assign
users privileges, and then they can use programs to use those privileges.

If a user does not have permission to perform an action, then they MUST get
an administrator to perform the action or delegate to them permission.

SUID only affects HOW a user uses their privilege - not whether they HAVE
the privilege. SUID has no effect on the situation you describe.

However many smaller companies cannot afford the overhead and even if
they would like to run users as standard users it is just not practical.

Not practical because WHY? They can't afford to pay administrators? That's
not the fault of the security model. Windows allows admins to delegate
whatever privileges users need to the users so they can get whatever work
they need to do without bother admins.

The only break here is application refusing to comply with the security
model.

If admins have it set up so that users cannot do their work without an admin
hovering over their workstation, THAT IS THE ADMIN'S FAULT, not Windows'
fault.

Likewise with laptop users where an administrator cannot follow the user
around to be there when the user needs to perform some administrative task
it just isn't practical.

You seem to be making the case that all users should be administrators
because it is impractical to limit what standard users can do?

Admins can grant users privileges to do things REMOTELY or through remote
desktop or remote management the admins THEMSELVES can do the task - or they
can edit the user's permissions and privileges directly, delegating to them
the privilege to carry out whatever task they need to do. In the later case,
the user would just have to logoff and log back in to get their new
privileges.

There was a poll I saw at one time "In what percentage of of desktops that
you manage are the users administrators?" followed by "On Windows Vista,
what percentage of desktops that you manage will be administrators?"
http://blogs.msdn.com/uac/archive/2006/07/28/susan.aspx. Although poll is
a rather small sampling and non-scientific it appears that at about half
of those that currently grant their user administrative accounts have a
desire to change this. What might actually be more interesting to see is
if any of those users that expressed the desire to change this were
actually sucessful in doing so after deploying Vista.

I imagine, although I as well have no hard data to back up my claim, that
most of those people running their users as admin do so not because of some
inherent flaw with the windows security architecture, but due to
APPLICATIONS refusing to work inside of said architecture.

UAC will help change this behavior, and one of the benfits is that thru
virtualization many of the problem applications will magically start to work
when ran from a privilege-limited account, which should allow many companies
to begin implementing security in their organization.

Although the point you make about using requiresAdministrator does have me
worried a bit.

However the user still needs to be able to perform his job.
For example, a travelling sales guy has an online meeting with the client
in 10 minutes, but when he navigates his browser to the meeting place
finds out that he needs to install an updated meeting control and is
unable to do so. He gives you a call and how important this is. The
ActiveX control does not require administrative privilages to run but the
user still requires administrative privilages to install it. Since he is
currently on the road you can't walk over to his computer and provide
over-the-shoulder administative credentials. What would you do?

Remote desktop into his laptop and install it myself. Or, grant the user the
privilege to install the ActiveX control or MSI-based installation program.

Granted, you may run into scenarios where due to applications checking for
admin or whatnot and artificially refusing to run/install even if the user
has been delegated permission - but this is the fault of third-party apps,
and not a limitation of the windows security model.

But this is really the only problem - otherwise, without limitation, if your
users need to be able to do something, you grant them the privileges. The
only added thing SUID does is to constrain the user into only using those
privileges when using certain applications - it does not affect what
privileges the user has.

I agree this model would be a significant improvement.
So why didn't MS implement this instead?

I think they are getting there. The windows architecture is evolving to make
something like this possible; what I proposed here changes many things and
depends on answering many tough problems before it could work, problems that
are already being addressed in Vista.

I think it will take a few iterations to get right, .NET CAS is very
powerful but is too complex for the average user to understand or manage.
.NET 1.1 simply denied ability for internet applications that required
more permission to then the default zone to execute so rather then allow
the user to change the permissions to fit the desired application they
came up with ClickOnce which allows the user to install the application
granting it fulltrust instead, despite its flexibilty very few .NET
applications actually use CAS and many .NET developers don't even know it
exists, I think the security config was actually moved into the SDK
because no one uses it.

Applications define what privileges they must have to work. If those
privileges are unavailable, the application cannot run. You're right, the
problem in that instance was the user could not [easily] give the program
the privileges it needed to run. In the model I suggested, the user would be
able to easily give programs permission to run through consent (if required)
as long as the user themselves had the privileges necessary.

Except in tightly controlled environmetns many users do have
administrative rights on their local machine. The poll I mentioned above
shows nearly 80% of users have administrative user accounts. Even without
administrative accounts user's machines are concidered to be insecure,
secure resources are placed on servers locked up in secured rooms,
protected by firewalls, users are only allowed to talk to the application
server and the application server will perhaps go through yet another
firewall to update an SQL server to prevent users from directly accessing
these services. Users don't talk directly to services they talk to
application servers, even file servers now days have increasingly become
SharePoint sites instead.

Well, my opinion is that the reason users would have to be local admin is
primarily caused by application incompatability. I think MS found that about
half of the apps they tested with vista would not run correctly when not ran
inside of an admin account - but I can't recall the source. Through vista's
app compat features, I think they got 80-90 percent to work - so I do think
this will help companies that wish to un-adminize their users on a
per-machine basis to do so.

As to securing secure resources in the manner you described - this just kind
of makes sense. Why would you run an SQL server on a user's machine and/or
let them talk directly to it, when they are only meant to use it from a
certain app? Essentially, this is the same thing SUID does on a
local-machine basis - and it is a good idea, which is why I support the
concept .

I think it would be possible if the application had a security token also.
An application that does not have privilaged permissions would be
prevented from launching one that does and even prevented from sending
messages to an application that does (ie cannot send keys to windows
explorer to launch one).

Windows Explorer does NOT have SeDebug privilege. The user double-clicks
Visual Studio, which DOES have the SeDebug privilege. UAC is needed to
determine if the user intended to launch Visual Studio with elevated
privileges, because the Application (Explorer) is the one that determines
what action the UI input takes, NOT Windows.

To put it another way: An application (SaveLotsOfMoney.exe) shows the user a
message saying they won a zillion dollar and to CLICK HERE to collect thier
prize. They click the button, and another process, TakeOverComputer.exe is
executed that requests some nasty privileges. UAC is needed here to
determine if the user INTENDED to launch a higher-privileged app, because it
cannot make that determination itself.

If no lower-privileged apps can start higher-privileged apps, your user is
going to be very, very upset, because this situation will come up a lot,
where the user wants to start a higher-privileged app from within a
lower-privileged one (the shell, for example).

The challenge here is finding a way for Windows to KNOW that a user is
intending for this privileged action to take place without asking the user.

We both agree a better model is needed. SUID may not be it, but I think
it is better then using custom services.

The purpose of SUID I agree with; I disagree with the way it is designed
and implemented. Custom services can be used to implement SUID-like
behavior, but that is really not their purpose. Neither as-is are a good
solution for limiting the user's privileges only to certain applications .

 

[Kurt Harriger]

SUID should not just be some attribute that follows around and is granted
simply by copying it to the machine. Perhaps a trusted install location
where execute file permission is not "inherited from parent" and a
management tool like services that allows administrators to enable suid
specify the user to run as AND who can access it.

Agreed, there are many ways to mitigate the problem. But SUID simply can't
exist inside Windows as-is; Windows must be re-architected to support the
model, and it will look differently than SUID does in *nix. Not knowing
enough about the *nix architecture I can't really make a comment as to how
well SUID fits in with it - but I have serious doubts about this.

Malware could also install a windows service that is accessible to all
users and as a bonous windows will even start the services automatically.

Agreed - anything that can be done via an SUID app could also be done via
a service. I used a bad example here.

Unless the service (such as SQL) provides some sort of security
configuration tool the only control the administrator has is what user
the service runs as not which users can access it.
Services are IMHO SUID applications that require custom security
configuration tools to manage access.

Well, I was waiting for you to point this out . Yes, services in Windows
ARE an implementation of the SUID model. But services *ARE NOT* SUID apps,
and Windows HAS NO equivalent to SUID, which is why you would have a hard
time managing services thinking they are SUID.

The difference between services and SUID apps is the layer at which they
run and what they are for. Services ARE the operating system, they
implement functionality in a privileged environment that is exposed to
applications [the user]. Applications ARE the user, they run with the
privs of the user to consume OS services. This seperation of privilege is
enforced by Windows at a very low level, and it is safe to say that only
maldesigned services or the OS can leak privileges unexpectedly to the
user.

SUID is for constraining how the user can utilize a privilege, but it
doesn't fit with the Windows architecture as implemented in *nix. You can
have SUID-like behavior using services, but as you point out, that's not
PRECISELY what services are for. If you want to do so using services, you
have to be a programmer - you can't modify a pre-existing service or
application to do this.

Windows does not have SUID because it was not designed to. Tacking it on
to Windows without molding it into the Windows architecture is simply an
unthinkable act that, although could be useful, ends up destroying the
seperation of privilege created by the current Windows architecture,
resulting in a big security-flawed mess.

A service running in the context of a user account is technically "OK"
(albiet this is certainly a stretch of the imagination) because the user
accounts are always constraining the full privileges of the OS. Services
ARE the OS, and if it wants to artificially limit the access it has to
itself, the more the merrier.

SUID apps essentially are Windows Services in an application form. Since
users ARE the applications they run, the user essentially becomes the OS
when running the SUID app. Although the power of an SUID app may be
constrained in some fashion via the user account it runs under, just like
services can, they still inherit their "power" from the OS, not the user,
which is what breaks things.

The intent of SUID is to give the user privileges constrained only to a
certain app. And it APPEARS to do so in a windows environment - but this
is not so. Until Vista, Windows has *NOT* seperated privileges between
applications ran by the user. Although this model has changed in the Vista
timeframe, there are still incongruencies between the SUID model and the
Windows model that must be worked out to ensure a bulletproof SUID
implementation.

This is why I say privilege escalation is unavoidable in this scenario.
Windows views all the applications that a user is running AS THE USER,
because this IS the Windows model. Before Vista, there was very limited
seperation of privileges between apps on the user's desktop, because this
simply wasn't necessary. Remember, back then, all apps had the same privs
(whatever was assigned to the user) - no reason to enforce any sort of
seperation. The primary seperation of privilege line is drawn between
applications and services/OS, NOT between applications running on a user's
desktop, and even in Vista where lines do exist here, they are not quite
what is needed for SUID-like behavior.

If a user were to run an app with higher privileges on their desktop
(which was the case where services show UI's onto the screen, which Vista
now prevents), it was pretty trivial for the user through applications (or
applications of their own volition) to use those higher privileges that
have presented themselves on their desktop in any way they wanted. Once a
higher-privileged app appeared on their desktop, the user could use those
higher privileges outside of the constrainment intended by the
application.

This is why I say that whenever you break the security model privilege
escalation is ALWAYS possible - because the entire system depends on this
model, and when you break it, things no longer fit, and privilege
escalation is the end result..

This is why I say SUID is conceptually flawed in the context of the
Windows model, precisely because it doesn't follow the Windows model, and
that the Windows model has to change to make this happen .

It is only NOW, in Vista, that the notion of different privilege levels is
starting to be enforced inside of a user account, thru UAC. The Windows
architecture is slowly being adapted in such a way that SUID-type behavior
won't break it - it's not quite there yet, but it is getting there, and
that is why I am hopeful that in the future we will have this wonderful
feature, in a nice and secure manner .

You've said before elevation is always possible with SUID applications,
perhaps I'm missing something here... I would expect the application I run
as SUID to have different, perhaps elevated, privilages, but my assumption
was that specific application could use/misuse the elevated privilages... in
which case it doesn't seem much different then a service but instead of
using IPC to communicate with applications it communicates directly to the
user. But I think what you might be saying is that if I created a simple
application that does absolutely nothing except display a simple form with a
giant close button and run this application as an elevated user that it
could still be exploited by another application running on the users desktop
perhpas another application could steal the elevated user token thus by
simply running the application you could be "leaking" privilages to other
applications?

If you want users to be able to perform an administrative task, then give
them the privileges to do so. That IS the windows security model. You
assign users privileges, and then they can use programs to use those
privileges.

If a user does not have permission to perform an action, then they MUST
get an administrator to perform the action or delegate to them permission.

SUID only affects HOW a user uses their privilege - not whether they HAVE
the privilege. SUID has no effect on the situation you describe.


Not practical because WHY? They can't afford to pay administrators? That's
not the fault of the security model. Windows allows admins to delegate
whatever privileges users need to the users so they can get whatever work
they need to do without bother admins.

The only break here is application refusing to comply with the security
model.

If admins have it set up so that users cannot do their work without an
admin hovering over their workstation, THAT IS THE ADMIN'S FAULT, not
Windows' fault.


You seem to be making the case that all users should be administrators
because it is impractical to limit what standard users can do?

Admins can grant users privileges to do things REMOTELY or through remote
desktop or remote management the admins THEMSELVES can do the task - or
they can edit the user's permissions and privileges directly, delegating
to them the privilege to carry out whatever task they need to do. In the
later case, the user would just have to logoff and log back in to get
their new privileges.

You make it sound so simple... the reality is always something quite
different. Many of our consultants are working from corporate offices that
have network security so tight some are lucky if they are even allowed
browse to the google home page, if I'm lucky they might be able to do a
"request remote assistance" but RDP 3389 is always blocked by the firewall.
Some do have cellular wireless cards and can get around these restrictions
but an internet connection doesn't necessarily imply remote management is
possible. Even if you could RDP in whenever necessary, many applications
don't function correctly in a standard user account, MS apps included, such
as my previous example of installing an activex control, even if that
control does not require admin privilages and only that user needs to use it
you need to be admin. MS is the one that basically required logo apps to be
installed in Program Files folder as such nearly every application requires
admin privilages to install even if the app itself does not use require
admin privilages nor need to be shared by multiple users. And all
applications have been pre-installed for the user some other applications
just don't function correctly. I don't think vendors are entirely to blame
for poor application compatibility, many of which are just following MS's
lead.

I've already uninstalled Vista from my computer because of application
compat issues... many of which are MS apps. SQL developer requires
installation of SP2 which is still a CTP, OWA required a patch to be
installed on the exchange server, VS 2005 reported app compat issues, the
right click context menus do not work in WinRar (using slightly older
licensed version, the new version does work) and my printer/scanner doesn't
work which I use nearly every week (no vista drivers, I didn't have 64 bit
drivers either but I was able to run an XP 32 VM for printing/scanning using
XP 64 as a host since VMWare allows mapping USB devices, anoying but it
works, no such luck on Vista. I wasn't able to connect the usb device to
the VM without first installing the drivers otherwise I would just use
VMWare to solve my app compat issues).

I imagine, although I as well have no hard data to back up my claim, that
most of those people running their users as admin do so not because of
some inherent flaw with the windows security architecture, but due to
APPLICATIONS refusing to work inside of said architecture.

Agreed. But without applications windows itself doesn't do much more than
move around files and play music (unless you live in the EU

UAC will help change this behavior, and one of the benfits is that thru
virtualization many of the problem applications will magically start to
work when ran from a privilege-limited account, which should allow many
companies to begin implementing security in their organization.

I hope so, it definately brings the "need" for administrative privilages to
the attention of both user and vendor. Hopefully apps that do not really
need admin privilages will change their behavior enough so administrative
privilages are no longer required. I'm not entirely sure how things will
work out for the apps that do have a valid need for administrative
privilages, but maybe by seperating the non-privilaged and privilaged
hopefully they will find it easier to move to the next windows version -
less code to rewrite .

Although the point you make about using requiresAdministrator does have me
worried a bit.


Remote desktop into his laptop and install it myself. Or, grant the user
the privilege to install the ActiveX control or MSI-based installation
program.

Granted, you may run into scenarios where due to applications checking for
admin or whatnot and artificially refusing to run/install even if the user
has been delegated permission - but this is the fault of third-party apps,
and not a limitation of the windows security model.

Perhaps not a problem with the security model itself but it can
significantly limit its use.

But this is really the only problem - otherwise, without limitation, if
your users need to be able to do something, you grant them the privileges.
The only added thing SUID does is to constrain the user into only using
those privileges when using certain applications - it does not affect what
privileges the user has.

I agree this model would be a significant improvement.
So why didn't MS implement this instead?

I think they are getting there. The windows architecture is evolving to
make something like this possible; what I proposed here changes many
things and depends on answering many tough problems before it could work,
problems that are already being addressed in Vista.

I think it will take a few iterations to get right, .NET CAS is very
powerful but is too complex for the average user to understand or manage.
.NET 1.1 simply denied ability for internet applications that required
more permission to then the default zone to execute so rather then allow
the user to change the permissions to fit the desired application they
came up with ClickOnce which allows the user to install the application
granting it fulltrust instead, despite its flexibilty very few .NET
applications actually use CAS and many .NET developers don't even know it
exists, I think the security config was actually moved into the SDK
because no one uses it.

Applications define what privileges they must have to work. If those
privileges are unavailable, the application cannot run. You're right, the
problem in that instance was the user could not [easily] give the program
the privileges it needed to run. In the model I suggested, the user would
be able to easily give programs permission to run through consent (if
required) as long as the user themselves had the privileges necessary.

Except in tightly controlled environmetns many users do have
administrative rights on their local machine. The poll I mentioned above
shows nearly 80% of users have administrative user accounts. Even
without administrative accounts user's machines are concidered to be
insecure, secure resources are placed on servers locked up in secured
rooms, protected by firewalls, users are only allowed to talk to the
application server and the application server will perhaps go through yet
another firewall to update an SQL server to prevent users from directly
accessing these services. Users don't talk directly to services they
talk to application servers, even file servers now days have increasingly
become SharePoint sites instead.

Well, my opinion is that the reason users would have to be local admin is
primarily caused by application incompatability. I think MS found that
about half of the apps they tested with vista would not run correctly when
not ran inside of an admin account - but I can't recall the source.
Through vista's app compat features, I think they got 80-90 percent to
work - so I do think this will help companies that wish to un-adminize
their users on a per-machine basis to do so.

As to securing secure resources in the manner you described - this just
kind of makes sense. Why would you run an SQL server on a user's machine
and/or let them talk directly to it, when they are only meant to use it
from a certain app? Essentially, this is the same thing SUID does on a
local-machine basis - and it is a good idea, which is why I support the
concept .

I think it would be possible if the application had a security token
also. An application that does not have privilaged permissions would be
prevented from launching one that does and even prevented from sending
messages to an application that does (ie cannot send keys to windows
explorer to launch one).

Windows Explorer does NOT have SeDebug privilege. The user double-clicks
Visual Studio, which DOES have the SeDebug privilege. UAC is needed to
determine if the user intended to launch Visual Studio with elevated
privileges, because the Application (Explorer) is the one that determines
what action the UI input takes, NOT Windows.

To put it another way: An application (SaveLotsOfMoney.exe) shows the user
a message saying they won a zillion dollar and to CLICK HERE to collect
thier prize. They click the button, and another process,
TakeOverComputer.exe is executed that requests some nasty privileges. UAC
is needed here to determine if the user INTENDED to launch a
higher-privileged app, because it cannot make that determination itself.

If no lower-privileged apps can start higher-privileged apps, your user is
going to be very, very upset, because this situation will come up a lot,
where the user wants to start a higher-privileged app from within a
lower-privileged one (the shell, for example).
True.


The challenge here is finding a way for Windows to KNOW that a user is
intending for this privileged action to take place without asking the
user.

I was thinking to completely block other applications from faking user input
so that if the user double clicks a program windows explorer knows that it
was actually the user and not another application that performed the double
click. But there would still need to be some way for accesiblity
applications like an on-screen keyboard to work, and explorer shouldn't run
with trusted permissions either so if non-privilaged apps were prevented
from starting privilaged ones the shell would be affected also. There are
definately some technical challenges but I'm confident they can/will be
solved it just going to take some time.

 

[Jimmy Brush]

You've said before elevation is always possible with SUID applications,

perhaps I'm missing something here... I would expect the application I run
as SUID to have different, perhaps elevated, privilages, but my assumption
was that specific application could use/misuse the elevated privilages...
in which case it doesn't seem much different then a service but instead of
using IPC to communicate with applications it communicates directly to the
user. But I think what you might be saying is that if I created a simple
application that does absolutely nothing except display a simple form with
a giant close button and run this application as an elevated user that it
could still be exploited by another application running on the users
desktop perhpas another application could steal the elevated user token
thus by simply running the application you could be "leaking" privilages
to other applications?

Yes, this is what I have been trying to say . A program running at a
higher privilege level on a user's desktop can easily leak those privileges
to other applications, even if the application just showed an empty window
with a close button. This is called a "shatter" attack:

http://en.wikipedia.org/wiki/Shatter_attack

This "attack" is made possible because Windows assumes that every program
running on the user's desktop has the same privileges, and that those
privileges are that of the user. This isn't really a bug in Windows - this
is the way Windows was designed. Different-privileged applications were not
meant to be operated inside of a user's desktop.

In Vista, Windows seperates different "privilege levels" of applications
away from each other, so that this kind of attack is not possible except
inside privilege boundaries, by preventing applications of different
privileges levels from interacting with each other (this is why you can't
drag-and-drop from a lower-privileged application to a higher one).

However, this privilege seperation doesn't "fix" the architecture of
Windows - it just mitiages the design problem - and wouldn't really work
inside of a true multi-privilege environment. A true fix would be to
re-architect the Win32 subsystem to be multi-privilege-level aware.

You make it sound so simple... the reality is always something quite
different. Many of our consultants are working from corporate offices
that have network security so tight some are lucky if they are even
allowed browse to the google home page, if I'm lucky they might be able to
do a "request remote assistance" but RDP 3389 is always blocked by the
firewall. Some do have cellular wireless cards and can get around these
restrictions but an internet connection doesn't necessarily imply remote
management is possible. Even if you could RDP in whenever necessary, many
applications don't function correctly in a standard user account, MS apps
included, such as my previous example of installing an activex control,
even if that control does not require admin privilages and only that user
needs to use it you need to be admin. MS is the one that basically
required logo apps to be installed in Program Files folder as such nearly
every application requires admin privilages to install even if the app
itself does not use require admin privilages nor need to be shared by
multiple users. And all applications have been pre-installed for the user
some other applications just don't function correctly. I don't think
vendors are entirely to blame for poor application compatibility, many of
which are just following MS's lead.

I believe Applications have always been allowed to be installed to a
per-user location inside of the user's profile folder (without needing
admin). If not before, than they can now. Installing a program that can be
accessed by any user should require special privileges. And, it has always
been possible to delegate the ability to install programs to another user -
the power users group did this. Of course, applications that check for
membership in the administrors group and then failing if this was not the
case would not work in this case.

That aside, admins can bless MSI's to be installed without admin privs on a
machine, and can now do the same thing with ActiveX controls.

However, the problem here is mostly app compatability, not a design flaw in
the security architecture. SUID would not fix this problem - in both
scenarios, you, the administrator, would have to assign the user special
privileges in order to allow them to do what they want BEFOREHAND.

In the Windows Model, you would have had to have granted them privileges to
install the ActiveX control beforehand. In the SUID model, you would have
created a program with extra privileges that they could use to install
certain ActiveX controls.

Let me reverse the scenario - lets say you were administering a linux
machine and the user needed immediate access to a security-restricted file,
but you had no access to that file from your present location. How would you
allow them access? Unless you had planned on allowing them access to that
file beforehand and created an SUID program that gives them access (the same
as pre-blessing an ActiveX control in the Windows example), you still cannot
solve the user's problem without using your admin powers to do it.

As for MS setting a poor lead ... I'm afraid I can't disagree with you there
. The "correct" way of doing things has always seemed to be a "footnote"
in the documentation, and from the developers point of view, it has always
been easier to do it another way than the "correct" way - even for MS
developers.

MS needs to make doing things correctly the easier way - or at least the
path of least painfulness.

I've already uninstalled Vista from my computer because of application
compat issues... many of which are MS apps. SQL developer requires
installation of SP2 which is still a CTP, OWA required a patch to be
installed on the exchange server, VS 2005 reported app compat issues, the
right click context menus do not work in WinRar (using slightly older
licensed version, the new version does work) and my printer/scanner
doesn't work which I use nearly every week (no vista drivers, I didn't
have 64 bit drivers either but I was able to run an XP 32 VM for
printing/scanning using XP 64 as a host since VMWare allows mapping USB
devices, anoying but it works, no such luck on Vista. I wasn't able to
connect the usb device to the VM without first installing the drivers
otherwise I would just use VMWare to solve my app compat issues).

Yeah, there are a ton of app compat issues. Windows Vista is certainly not
Windows XP, and a lot of stuff has changed. This will require updates from
application vendors, inclusing Microsoft. I think this is a big reason why
things were not changed more drastically - Vista really has made a lot of
changes, and is paving the road for even more changes ... but if they had
gone much farther, the state of app compat would have been much, much worse.

I hope so, it definately brings the "need" for administrative privilages
to the attention of both user and vendor. Hopefully apps that do not
really need admin privilages will change their behavior enough so
administrative privilages are no longer required. I'm not entirely sure
how things will work out for the apps that do have a valid need for
administrative privilages, but maybe by seperating the non-privilaged and
privilaged hopefully they will find it easier to move to the next windows
version - less code to rewrite .

I hope so too.

Perhaps not a problem with the security model itself but it can
significantly limit its use.

Agreed. Hopefully thing will reverse such that developers can easily create
programs that "fall in line" with the Windows model, and have a much more
difficult time "breaking" the model.

I was thinking to completely block other applications from faking user
input so that if the user double clicks a program windows explorer knows
that it was actually the user and not another application that performed
the double click.

This could be possible - however, Windows still doesn't know the INTENT of
the user. Explorer itself (an untrusted third party in the eyes of the
Windows) decides how to act on user input - it determines how to react on
the UI. Windows receives the UI from the user and sends it to the
application. Windows doesn't know 1) What the app is going to do with the UI
or 2) What the user was intending to do by performing the UI action in the
first place. Windows needs to know the answer to both of these questions in
order to make an intelligent decision.

But there would still need to be some way for accesiblity applications
like an on-screen keyboard to work, and explorer shouldn't run with
trusted permissions either so if non-privilaged apps were prevented from
starting privilaged ones the shell would be affected also. There are
definately some technical challenges but I'm confident they can/will be
solved it just going to take some time.

Agreed. But I also think this is a conceptual/design challenge as well - how
do you get Windows to know what the intent of the user is? Windows can know
what the user is doing, but it can't know what the user intends to do by
his/her actions.

The solution will definately involve more metadata about UI and resulting
actions to be made available from the application to windows. For example,
if an application wants to start a program when the user clicks a button,
Windows needs to know this, and Windows also needs to be 100% certain that
the user also knows if they click on that button a program will be launched.

 

[Kurt Harriger]

Yes, this is what I have been trying to say . A program running at a
higher privilege level on a user's desktop can easily leak those
privileges to other applications, even if the application just showed an
empty window with a close button. This is called a "shatter" attack:

http://en.wikipedia.org/wiki/Shatter_attack

That is what I was missing! As long as arbitrary code can be injected into
the privilaged process, SUID would be suicidal. Programs should only
exchange messages and data, not code; windows basically enforces this for
services but gui apps are always vunerable. In unix console apps are
generally statically linked and send messages via stdin/stdout making it far
more difficult to inject code into a process. I'm not entirely sure if the
same sort of injection attacks are possible in unix gui apps but I think all
the admin guis always delegated the work to these console apps. Unix
console apps in someways act like services, but unlike windows services can
be invoked on demand rather than started at startup and can be easily
consumed directly from the command shell. Using stdin/stdout to send
messages to other processes as a form of code reuse is so common in unix
I've never really concidered its architectual significance. Perhaps it
could be safe to create suid console apps with no message loop; providing,
they aren't allowed to execute any other applications that have message
loops, allowing the possibilty for services on-demand rather then always
running type services. In any event now I understand why implementing SUID
in windows is "evil."

This "attack" is made possible because Windows assumes that every program
running on the user's desktop has the same privileges, and that those
privileges are that of the user. This isn't really a bug in Windows - this
is the way Windows was designed. Different-privileged applications were
not meant to be operated inside of a user's desktop.

In Vista, Windows seperates different "privilege levels" of applications
away from each other, so that this kind of attack is not possible except
inside privilege boundaries, by preventing applications of different
privileges levels from interacting with each other (this is why you can't
drag-and-drop from a lower-privileged application to a higher one).

Interesting, hadn't noticed that.

However, this privilege seperation doesn't "fix" the architecture of
Windows - it just mitiages the design problem - and wouldn't really work
inside of a true multi-privilege environment. A true fix would be to
re-architect the Win32 subsystem to be multi-privilege-level aware.


I believe Applications have always been allowed to be installed to a
per-user location inside of the user's profile folder (without needing
admin). If not before, than they can now. Installing a program that can be
accessed by any user should require special privileges. And, it has always
been possible to delegate the ability to install programs to another
user - the power users group did this. Of course, applications that check
for membership in the administrors group and then failing if this was not
the case would not work in this case.

That aside, admins can bless MSI's to be installed without admin privs on
a machine, and can now do the same thing with ActiveX controls.

However, the problem here is mostly app compatability, not a design flaw
in the security architecture. SUID would not fix this problem - in both
scenarios, you, the administrator, would have to assign the user special
privileges in order to allow them to do what they want BEFOREHAND.

True, you still need to know beforehand what scenarios need to be supported.
But maybe for those unforseen scenarios you could create a sort of admin
command shell that requires a different password each time; the system would
generate a random code and associated password for that code the user could
call the administrator tell him the code and the reason he needs to be
administrator and if approved the administrator would provide the password
and walk the user through the necessary steps. Of course there isn't
anything to gaurentee he didn't make something up to get admin privilages
for some other reason--and that he doesn't immediatly type mmc to reset the
admin password while your telling him the steps he should be performing--but
it might be a bit better then just flat out providing the administrative
password, but not really all that much.

In the Windows Model, you would have had to have granted them privileges
to install the ActiveX control beforehand. In the SUID model, you would
have created a program with extra privileges that they could use to
install certain ActiveX controls.

Let me reverse the scenario - lets say you were administering a linux
machine and the user needed immediate access to a security-restricted
file, but you had no access to that file from your present location. How
would you allow them access? Unless you had planned on allowing them
access to that file beforehand and created an SUID program that gives them
access (the same as pre-blessing an ActiveX control in the Windows
example), you still cannot solve the user's problem without using your
admin powers to do it.

As for MS setting a poor lead ... I'm afraid I can't disagree with you
there . The "correct" way of doing things has always seemed to be a
"footnote" in the documentation, and from the developers point of view, it
has always been easier to do it another way than the "correct" way - even
for MS developers.

MS needs to make doing things correctly the easier way - or at least the
path of least painfulness.


Yeah, there are a ton of app compat issues. Windows Vista is certainly not
Windows XP, and a lot of stuff has changed. This will require updates from
application vendors, inclusing Microsoft. I think this is a big reason why
things were not changed more drastically - Vista really has made a lot of
changes, and is paving the road for even more changes ... but if they had
gone much farther, the state of app compat would have been much, much
worse.



I hope so too.



Agreed. Hopefully thing will reverse such that developers can easily
create programs that "fall in line" with the Windows model, and have a
much more difficult time "breaking" the model.


This could be possible - however, Windows still doesn't know the INTENT of
the user. Explorer itself (an untrusted third party in the eyes of the
Windows) decides how to act on user input - it determines how to react on
the UI. Windows receives the UI from the user and sends it to the
application. Windows doesn't know 1) What the app is going to do with the
UI or 2) What the user was intending to do by performing the UI action in
the first place. Windows needs to know the answer to both of these
questions in order to make an intelligent decision.


Agreed. But I also think this is a conceptual/design challenge as well -
how do you get Windows to know what the intent of the user is? Windows can
know what the user is doing, but it can't know what the user intends to do
by his/her actions.

The solution will definately involve more metadata about UI and resulting
actions to be made available from the application to windows. For example,
if an application wants to start a program when the user clicks a button,
Windows needs to know this, and Windows also needs to be 100% certain that
the user also knows if they click on that button a program will be
launched.

Well the best application to determine the users intent is the application
itself not windows, windows explorer knows the user intended to launch the
desired application by double clicking it, if windows explorer is unsure the
user intended to perform the action it would ask the user. But not all
applications clearly state the effect and risks of double-clicking this or
pressing this button so windows should perhaps step in somewhere to confirm.
My thought is perhpas to be able to grant a specific application the "right"
to bypass uac prompts; allowing users on an application by application basis
express to windows their trust and comfort level with the specified
application, once they are comfortable with the application they might check
a box saying never show this again, but before this could happen there
method to ensure the user--and not some other program or arbitrary code
injected into the process--faked the action, which sounds like quite a
challenge in itself.

All in all I think we're pretty much in agreement; the challenges are bigger
then they at first appear, but things are improving, and vendors need some
time to catch up.

 

[Jimmy Brush]

Well the best application to determine the users intent is the application
itself not windows, windows explorer knows the user intended to launch the
desired application by double clicking it, if windows explorer is unsure
the user intended to perform the action it would ask the user. But not
all applications clearly state the effect and risks of double-clicking
this or pressing this button so windows should perhaps step in somewhere
to confirm.
Agreed.

My thought is perhpas to be able to grant a specific application the
"right" to bypass uac prompts; allowing users on an application by
application basis express to windows their trust and comfort level with
the specified application, once they are comfortable with the application
they might check a box saying never show this again, but before this could
happen there method to ensure the user--and not some other program or
arbitrary code injected into the process--faked the action, which sounds
like quite a challenge in itself.

I'm not sure I would go along with allowing users to completely override UAC
for a program; however, I think it can be made much less painful if consent
could perhaps be ascertained in a different manner. I would say a compromise
is needed:

1) Windows needs to secure the UI input model. Applications need to be
confident that when they receive UI input, they are getting it from the user
and not some faked input from another application.

2) Applications need to inform windows when they want to use "elevated"
privileges, exactly what elevated privileges they want to use, and how the
user is to intiate this use of privilege (thru a button, for example).

3) Applications need to allow Windows to somehow "mark" the UI control (i.e.
button) that the application intends the user to be able to interact with to
use a privilege. Windows needs to be able to ensure that the marking cannot
be overriden by the application and that the markings accurately represent
what kind of privilege execution will happen when the user performs the UI.

I would say that by default, when the user performs some UI function with a
"marked" UI control, Windows will go ahead and display a UAC confirmation
dialog giving the user detailed information about what the application is
requesting and allowing the user to confirm or deny the operation.

However, I think the user should be able to tell Windows not to display
confirmation for either selected UI controls or entire applications, but the
"marked" UI controls should easily allow the user to see all of the
information that is available from the consent dialog.

In this way, Windows is still getting the user to consent to a privileged
action via UI marking (since an application cannot fake this input, so
Windows knows with certainty that the user is the one initiating the
action), but it is nowhere near as annoying as having multiple dialogs
flying up all the time.

All in all I think we're pretty much in agreement; the challenges are
bigger then they at first appear, but things are improving, and vendors
need some time to catch up.

Agreed.

 

[David W. Fenton]

As developers, programmers and corporations get their stuff in a
bag, there will be less need for elevation than before. But for
now, it's nearly essential.

I'm afraid I simply don't believe this. There are still programs
(like QuickBooks) that require admin permissions on Win2K and WinXP,
and Intuit has had since 1999 to fix that. They just refuse to do
it. And that's far from the only such application.

If you really think that software developers will adapt to UAC, then
I wonder how you explain the fact that so many of them never adapted
to *not* running as admin on older versions of Windows? This has
been the bane of my existence as a system admin for small
businesses.

 

[Jimmy Brush]

Hello,

If you really think that software developers will adapt to UAC, then
I wonder how you explain the fact that so many of them never adapted
to *not* running as admin on older versions of Windows?

Reason's simple ... before, developers could assume the user had admin
privileges with limited consequences - a few users (proportionally speaking,
of course) who were in the minority would have problems, but most users out
there would have no problems.

Now, most users are running inside of a UAC enviornment - they are now the
majority. Developers tend to program for the majority. Microsoft has
essentially turned the tables, and is using this fact to force them to
update their applications. Unless developers want to inconvienence their
customers by forcing them to click on a prompt every time their applications
starts (and they won't do this unless absolutely necessary), they will
change their program.

 

[David W. Fenton]

Reason's simple ... before, developers could assume the user had
admin privileges with limited consequences

Why in the world would developers have assumed that? The only reason
I know that anyone sets up users as admins is because of the fact
that developers assume that users are set up as admins. If the
software developers did their job properly, nobody would have to run
as admins.

- a few users (proportionally speaking,

of course) who were in the minority would have problems, but most
users out there would have no problems.

Depends on what software you're running.

Now, most users are running inside of a UAC enviornment - they are
now the majority.

Huh? How in the world can most people be running in a UAC
environment when Vista has just been released?

Developers tend to program for the majority.

Then they should design their programs to *run* LUA. Installation is
a different matter, of course.

Microsoft has
essentially turned the tables, and is using this fact to force
them to update their applications. Unless developers want to
inconvienence their customers by forcing them to click on a prompt
every time their applications starts (and they won't do this
unless absolutely necessary), they will change their program.

Well, sure, but the locked down C: drive of Win2K didn't change
their habits, so why will UAC change them now? To me, it seems like
UAC just makes it *safe* to run as admin, rather than making it more
attractive to engineer your apps to run LUA.

 

[David J. Craig]

It is about time that developers finally created applications that do not
require admin access. If the free software folks can do it and have been
doing it for years, why does it take so long? Many Microsoft programs
require admin access, though newer versions may be better. I do know that
most of their developer tools needed it far too frequently. CD/DVD burning
software is another application category that needs it. There used to be a
fairly standard interface called ASPI but it hasn't been shipped with
Windows for a long time. That allowed any application to obtain access to a
device handle to CD & DVD drives while running in normal user mode. There
were some bugs where access to hard drives could be had and that was a
problem, but fixing it and publishing it would make it easier. Now almost
all burning software has to have a driver that can provide access to the
optical drives. Each one is unique and the API is not standard.

Let us hope that the new push towards UAC and everyone running in user mode
takes hold. I see far too many posts from those who just disable UAC and
think that is a good thing. My only question for them is why not keep using
XP. That would make sense. You can create a manifest for an existing
program that will identify its admin requirements and just use UAC.
Somewhat of a pain, but just like Linux when you run Yast it always requires
the root password.

 

[Jimmy Brush]

Reason's simple ... before, developers could assume the user had

Why in the world would developers have assumed that?

Because that was the truth - the majority of windows users operated their
computer within an administrator account. I'm definately not saying that's
the right way for the developer to look at things, but that was the cold,
hard reality.

The only reason
I know that anyone sets up users as admins is because of the fact
that developers assume that users are set up as admins.

Perhaps in a locked-down business world this is the case. However, things
are different in the consumer world. From the point of view of a software
developer, if they weren't specifically targeting customers using a
least-privileged enviornment, I can easily see why they wouldn't care if
their app didn't work 100% in a least-privilege environment [although I
don't agree with this behavior].

If the
software developers did their job properly, nobody would have to run
as admins.

Agreed.

This is kind of a chicken-and-the-egg problem. Developers won't program
software for non-admins until most people run as non-admins. People won't
run as non-admins until developers program for non-admins. Deadlock!

UAC solves this problem by making the majority of users run as both admin
and non-admin, with non-admin being default, and the transition into admin
mode undesirable from the viewpoint of the software developer.

Depends on what software you're running.

Well, actually the statement I made here depends on the market for a
software applicaton. My point here was that if a developer knows that their
user is running as an administrator [majority of cases for most markets
pre-Vista] then they have less motivation for making sure their app works
right in the minority case where their user is in a least-privileged
environment.

Huh? How in the world can most people be running in a UAC
environment when Vista has just been released?

I was speaking in abstract terms here. If a developer is writing an
application for Vista, then they must assume that the user will be in a
UAC-protected environment, since that is the default case.

Then they should design their programs to *run* LUA. Installation is
a different matter, of course.

That's my point - thanks to UAC, they have a very strong motivation to do
this .

Well, sure, but the locked down C: drive of Win2K didn't change
their habits, so why will UAC change them now? To me, it seems like
UAC just makes it *safe* to run as admin, rather than making it more
attractive to engineer your apps to run LUA.

In Vista, developers must either re-engineer the app to be LUA, or require
the user to click a prompt every time the app is run. Before, there was no
"down-side" to not engineering for a LUA environment for the general case
[where the user is an admin]; now, there is.

 

[David W. Fenton]

Because that was the truth - the majority of windows users
operated their computer within an administrator account. I'm
definately not saying that's the right way for the developer to
look at things, but that was the cold, hard reality.

That's a chicken and egg problem, seems to me. Yes, Microsoft's
setup routines encouraged setting up as an admin user, but that was
because it was the only practical way for MS to accomodate
developers that weren't adjusting their installers to run properly.
In the beginning, I guess it was a matter of accomodating legacy
software, but frankly, most legacy software runs pretty well under a
user-level logon.

Perhaps in a locked-down business world this is the case. However,
things are different in the consumer world.

Oh, puh-leaze. I am a computer consultant who works for
microbusinesses and individuals, and none of them have any problems
running as user-level logons. Of course, they wouldn't do that if I
hadn't set up their PCs properly.

From the point of view of a software
developer, if they weren't specifically targeting customers using
a least-privileged enviornment, I can easily see why they wouldn't
care if their app didn't work 100% in a least-privilege
environment [although I don't agree with this behavior].

That's a ridiculous attitude on the part of any software maker. By
not handling it, they are buying themselves customer support
problems the come with the incompatibilities. "Run as an admin" is
not a proper answer, but for some reason, the industry has let them
get away with it.

Agreed.

This is kind of a chicken-and-the-egg problem. Developers won't
program software for non-admins until most people run as
non-admins.

That's a STUPID attitude. The whole point of the MSI was to handle
the locked-down system drive and system folders. That was the point
at which all developers should have redesigned their apps to run in
LUA environments.

People won't
run as non-admins until developers program for non-admins.
Deadlock!

My clients are running LUA in domain-free environments. There are
only a small number of apps that have required one-time registry
permission tweaks to get them to run.

UAC solves this problem by making the majority of users run as
both admin and non-admin, with non-admin being default, and the
transition into admin mode undesirable from the viewpoint of the
software developer.

No, admin is the default for the user logon, but the applications
launch by default without full admin permissions. It's a backwards
way of doing it, seems to me -- run as admin all the time, but don't
actually give administrative permissions to the processes launched.

Well, actually the statement I made here depends on the market for
a software applicaton.

What's the justification for Quickbooks needing admin permission?
Ever tried to run it on a Terminal Server?

My point here was that if a developer knows that their
user is running as an administrator [majority of cases for most
markets pre-Vista]

And, of course, the reason why there are millions of zombie PCs out
their pumping out spam...

then they have less motivation for making sure their app works
right in the minority case where their user is in a
least-privileged environment.

Seems to me that "less motivation" = too lazy to bother.

I was speaking in abstract terms here. If a developer is writing
an application for Vista, then they must assume that the user will
be in a UAC-protected environment, since that is the default case.

But they don't have to do *anything* -- UAC handles it for them
(though in a way that may annoy the user).

That's my point - thanks to UAC, they have a very strong
motivation to do this .

To me it seems that UAC will relieve them of any responsibility to
bother one way or the other.

Well, sure, but the locked down C: drive of Win2K didn't change
their habits, so why will UAC change them now? To me, it seems
like UAC just makes it *safe* to run as admin, rather than making
it more attractive to engineer your apps to run LUA.

In Vista, developers must either re-engineer the app to be LUA, or
require the user to click a prompt every time the app is run.
Before, there was no "down-side" to not engineering for a LUA
environment for the general case [where the user is an admin];
now, there is.

Is it really *every single time*? That's one I didn't quite grasp, I
guess.

It has annoyed me for years and years and years (since the
introduction of Win2K) that apps supposedly developed to run on the
latest NT-based version of Windows were not LUA-compatible. And I've
never understood why any number of sysadmins I know of run their
desktops in a domain environment with local admin logons. How can
people in this day and age be so completely ignorant of the security
problems this creates? And, last of all, I blame MS for having made
machine setup default to an admin logon (with no password, and no
logon prompt). If MS had defaulted to LUA, then this problem would
have been solved a long, long time ago.

 

[David W. Fenton]

Let us hope that the new push towards UAC and everyone running in
user mode takes hold.

Perhaps I've misunderstood UAC, but I think what it does is allow
people to run as admin more safely, by only handing out the admin
credentials when the user has explicitly authorized it.

 

[Jimmy Brush]

Oh, puh-leaze. I am a computer consultant who works for
microbusinesses and individuals, and none of them have any problems
running as user-level logons.

I wasn't commenting here on whether one would have problems running as a
standard user.

Of course, they wouldn't do that if I
hadn't set up their PCs properly.

Aha! My point!

From the point of view of a software
developer, if they weren't specifically targeting customers using
a least-privileged enviornment, I can easily see why they wouldn't
care if their app didn't work 100% in a least-privilege
environment [although I don't agree with this behavior].

That's a ridiculous attitude on the part of any software maker. By
not handling it, they are buying themselves customer support
problems the come with the incompatibilities. "Run as an admin" is
not a proper answer, but for some reason, the industry has let them
get away with it.

Agreed.

This is kind of a chicken-and-the-egg problem. Developers won't
program software for non-admins until most people run as
non-admins.

That's a STUPID attitude.
Agreed.

People won't
run as non-admins until developers program for non-admins.
Deadlock!

My clients are running LUA in domain-free environments. There are
only a small number of apps that have required one-time registry
permission tweaks to get them to run.

By "people" I am referring to the majority of windows users, not you or your
clients .

No, admin is the default for the user logon, but the applications
launch by default without full admin permissions. It's a backwards
way of doing it, seems to me -- run as admin all the time, but don't
actually give administrative permissions to the processes launched.

Yeah, it seemed backwards to me at first as well... but the more I thought
about it, the more it made sense to me. If I am really an administrator, why
should I have to have a seperate limited user account for security reasons?
Why shouldn't I be able to control the privileges of applications I run from
a single account?

What's the justification for Quickbooks needing admin permission?
Ever tried to run it on a Terminal Server?

Right ... this is the "minority" of users with problems that I was talking
about. I imagine the justification would go something like "why should we
spend resources making these 'niche' scenarios work correctly when we could
be fixing bugs/refining/adding features that many more people will see and
use?"

My point here was that if a developer knows that their
user is running as an administrator [majority of cases for most
markets pre-Vista]

And, of course, the reason why there are millions of zombie PCs out
their pumping out spam...
True.

then they have less motivation for making sure their app works
right in the minority case where their user is in a
least-privileged environment.

Seems to me that "less motivation" = too lazy to bother.
LOL.

I was speaking in abstract terms here. If a developer is writing
an application for Vista, then they must assume that the user will
be in a UAC-protected environment, since that is the default case.

But they don't have to do *anything* -- UAC handles it for them
(though in a way that may annoy the user).

No, UAC does not handle anything for them [unless they decide to live with
forcing the user to approve their application to run whenever it starts, and
I just don't see any developer wanting that unless they are developing an
administrative program where this would be normal and acceptable].

UAC is just the means by which the system prompts the user if they want to
run a program with admin privileges. It is NOT automatic - an application
has to request this dialog to be shown WHEN IT STARTS. A process (or com
component) either receives admin privileges or it doesn't. If an app/com
component w/out admin privileges attempts to do an admin operation and it
has not been elevated via UAC, the operation will fail.

If a developer wants their program to run correctly without displaying a UAC
prompt, it will have to be programmed to work correctly as a standard user -
just like if they wanted it to work correctly in XP as a standard user.

There are a few "hacks" that UAC does for legacy XP apps in order to get
them to work, but they are not desirable as they can silently fail in some
pretty nasty ways.

To me it seems that UAC will relieve them of any responsibility to
bother one way or the other.

No ... if an app wants to use admin power, they will have to get the user's
permission when the program starts. If an app doesn't want to throw a
permission prompt, it must be designed to work under a standard user
account, otherwise it will fail.

UAC is forcing them to make their apps work under a standard user account to
avoid prompting the user every time their application starts.

This will force developers to only use admin power when absolutely
necessary, because they will not want their application prompting the user.

It has annoyed me for years and years and years (since the
introduction of Win2K) that apps supposedly developed to run on the
latest NT-based version of Windows were not LUA-compatible. And I've
never understood why any number of sysadmins I know of run their
desktops in a domain environment with local admin logons. How can
people in this day and age be so completely ignorant of the security
problems this creates? And, last of all, I blame MS for having made
machine setup default to an admin logon (with no password, and no
logon prompt). If MS had defaulted to LUA, then this problem would
have been solved a long, long time ago.

I agree with you, but I see UAC as something better than the traditional
"this is my standard user account and this is my admin account" approach.

I see UAC as fleshing out answers to some more fundamental questions: Why do
programs that don't need X privileges receive X privileges? My user account
grants me X privileges ... why can't I (or my administrator) set policy
describing which applications I can use my privileges with? Why must I have
more than one user account in order to have a secure system, when I am
really only a single user? Does that really make sense?

Happy New Year!
*throws confetti*

 

[David W. Fenton]

I agree with you, but I see UAC as something better than the
traditional "this is my standard user account and this is my admin
account" approach.

I agree that UAC is good, but it's good points have virtually
nothing to do with the problem of apps that are written to require
full admin permissions.

I see UAC as fleshing out answers to some more fundamental
questions: Why do programs that don't need X privileges receive X
privileges? My user account grants me X privileges ... why can't I
(or my administrator) set policy describing which applications I
can use my privileges with? Why must I have more than one user
account in order to have a secure system, when I am really only a
single user? Does that really make sense?

Absolutely. UAC allows those who really need to run as admin to be
able to do it safely. For users who have no need for that (which
ought to be MOST USERS), it really shouldn't be adding anything new.

I have worked at a number of companies with domain controllers and
all the users logged on with user-level permissions (with the
exception of QuickBooks users!). I really think it's only home users
and small businesses without proper system administration who are
running as admins.

If UAC forces software makers to fix what they've been doing wrong
since 1999, then that's great. But I see that as only a side effect
of the design of UAC, not its chief purpose.

 

[Jimmy Brush]

I agree that UAC is good, but it's good points have virtually
nothing to do with the problem of apps that are written to require
full admin permissions.

In the context of apps that *should not* need admin permission but require
it anyway, I disagree - UAC is designed to deal with these apps, by both
working around legacy apps that do this (virtualization) and making it much
more painful for developers to create such programs.

Granted, UAC does, in fact, allow programs to be written to require full
admin permission, and so one can say that it doesn't "concretely" solve this
problem; however, I think the reality of how an application runs with full
admin under UAC cannot be ignored, and will indeed be a major motivation for
devs to write software with least privilege.

However, in the case of actual admin apps requiring "an administrator" to
run them, you make an excellent point [and I have said this before]. UAC as
it's currently implemented makes it too easy for developers who have a need
to allow their program to have extra privileges to just mark their
applications as "requiring an administrator", instead of doing it the
correct way and testing to see if the user has the needed privileges and
prompting for elevation only if necessary.

This kind of sweeps the entire rich privilege model of Windows under the
rug, replacing it with "administrator" or "not an administrator". If I have
a certain privilege but am not an administrator, I should be able to run a
program that needs the privilege I hold without having to be a part of the
administrators group.

As an example, take the system clock. Users must hold the change system time
privilege in order to change the time. Windows does it at least
semi-correctly - if the user has this privilege, they can change the system
time, regardless of whether they are an administrator or not. However, if
the user doesn't hold this privilege, the clock requests an administrator to
log in. I'm sure this took a non-trivial amount of code to implement, when
UAC should do this automatically for the application.

As it stands, it is much easier for the developer to simply mark their app
as 'require admin' than to implement the logic necessary to check for
privileges and request elevation only if necessary. And this require admin
behavior is now kind of "supported" by Microsoft, whereas before testing for
admin and failing if not was considered hackish. This is going to set a
dangerous precedent IMHO.

If the system clock was implemented the way I see most developers
implementing it, it would be marked 'require administrator' to run,
resulting in all non-admins having to provide admin credentials to change
the system time, even if they held the appropriate privilege.

Absolutely. UAC allows those who really need to run as admin to be
able to do it safely. For users who have no need for that (which
ought to be MOST USERS), it really shouldn't be adding anything new.

Well, I would add here that UAC implements virtualization and integrity
concepts to the compatability and security architectures, which provide
benefits to standard user accounts. Virtualization allows many legacy apps
that wouldn't run in Windows XP as a standard user to run in Vista as a
standard user. Integrity control provides privilege seperation between
well-defined integrity levels (system vs. admin vs. non-admin vs.
restricted), helping to prevent shatter attacks between levels as well as
allowing each level to define a "sandbox" that controls which securable
objects that level can write to, that takes precedence over the permission
list on objects.

The infrastructure required to support different privileged apps inside of a
single user account can be useful for non-admin accounts as well .

I have worked at a number of companies with domain controllers and
all the users logged on with user-level permissions (with the
exception of QuickBooks users!). I really think it's only home users
and small businesses without proper system administration who are
running as admins.

If UAC forces software makers to fix what they've been doing wrong
since 1999, then that's great. But I see that as only a side effect
of the design of UAC, not its chief purpose.

You say tomato, I say tomato. Regardless of how we chose to classify it,
I certainly hope (and expect) to see significant change in this area in the
next few years, thanks primarily to UAC.



--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

 

[Gerry Hickman]

Hi Jimmy,

In the context of apps that *should not* need admin permission but
require it anyway, I disagree - UAC is designed to deal with these apps,
by both working around legacy apps that do this (virtualization)

But it's the wrong solution for the wrong problem.

and
making it much more painful for developers to create such programs.

Again, it's the wrong solution. If Microsoft had wanted to make sure
user apps would run without Admin rights (which 99% do) then the correct
solution would be to change the default user accounts to user accounts
and disable internet access on Adminintrators group. If they'd done this
on XP, QuickBooks would already be fixed, they'd have gone out of
business otherwise. What they did instead was crate a half-baked,
farcical dialog box that merely causes inconvenience. There is never a
case for filtering a token and there is never a case for privilege
elevation. This is actually a flaw of XP, it was not an issue on NT4 or
Windows 2000. What they did instead was try to appease Intuit and the
idiot home user who logs in with Admin rights and that's the ONLY reason
for the existence of UAC, it has no place in a corporate environment
because they users are never Administrators.

The case of virtualization is always wrong, and Microsoft state in the
Vista docs that this is an INTERIM solution with no future. It's
actually MUCH worse. If a home user wants to leave it on then fine, but
if any business if thinking of leaving virtualization turned on they are
fools - plain and simple. Look at the HKCU's if you don't believe me.

Granted, UAC does, in fact, allow programs to be written to require full
admin permission, and so one can say that it doesn't "concretely" solve
this problem; however, I think the reality of how an application runs
with full admin under UAC cannot be ignored, and will indeed be a major
motivation for devs to write software with least privilege.

But not as much as a motivation as if their app simply said "Access
Denied", which is what it should say, but Microsoft were too half-baked
to write a business class o/s (for the fifth year running).

However, in the case of actual admin apps requiring "an administrator"
to run them, you make an excellent point [and I have said this before].
UAC as it's currently implemented makes it too easy for developers who
have a need to allow their program to have extra privileges to just mark
their applications as "requiring an administrator", instead of doing it
the correct way

Exactly.

And Vista means this idiotic practice will continue for another five
years because of UAC. It will still encourage bad practice.

This kind of sweeps the entire rich privilege model of Windows under the
rug, replacing it with "administrator" or "not an administrator". If I
have a certain privilege but am not an administrator, I should be able
to run a program that needs the privilege I hold without having to be a
part of the administrators group.

It's simple, users run as users, Administrators run as Administrators.
Except on Vista, it's not simple, they all run as each other and it's a
total mess.

As an example, take the system clock. Users must hold the change system
time privilege in order to change the time. Windows does it at least
semi-correctly - if the user has this privilege, they can change the
system time, regardless of whether they are an administrator or not.
However, if the user doesn't hold this privilege, the clock requests an
administrator to log in. I'm sure this took a non-trivial amount of code
to implement, when UAC should do this automatically for the application.

It's absurd if users can change the clock. They could end up wrecking a
differential backup or cause all their program licenses to suddenly
expire. They should be locked out of the clock, only Admins should be
able to change it.

As it stands, it is much easier for the developer to simply mark their
app as 'require admin' than to implement the logic necessary to check
for privileges and request elevation only if necessary. And this require
admin behavior is now kind of "supported" by Microsoft, whereas before
testing for admin and failing if not was considered hackish. This is
going to set a dangerous precedent IMHO.

I agree, this is the whole issue. Microsoft have done it completely back
to front. It's the worst design you could possibly have, it breaks the
fundamental best practice of users running as users and Admins running
as Admins.

 

[Jimmy Brush]

Hello Gerry

* Virtualization - I agree with you that it is a temporary "hack" to get old
apps to work; however, it is a fundamental part of UAC right now, as without
it, this transition phase would have been impossible.

You can't just change core OS functionality that breaks tons of programs and
expect people to just deal with it - you have to have a transition phase
that deals with most of the broken apps, while moving the market to a new
direction. Again, this is a chicken and the egg problem: If you break
compatability completely, you have a great new OS, but no apps will work
with it. People won't install the OS until apps work with it, apps won't be
created for the new OS until people use it. You have to walk the middle path
here.

I was pointing out here that although core UAC may not fundamentally address
apps created that require admin, practically it DOES address a portion of
these apps, and I hope it will DIRECTLY address ALL of these types of apps
in the future .

The rest of the points you make in this post seem to be based on your view
that there are two kinds of people in this world: users and administrators,
and that this is a hard-drawn line in the sand that should not be violated
in any way, shape, or form.

Personally, I see things a bit differently, but it's all semantics really,
so I will go with this way of thinking for a minute. I will define "user"
here as someone with no special privileges, and "admin" as anyone who has
any extended privilege(s).

You have mentioned again and again the UAC is violating this
user-role-seperation abstraction. Well, it's not at all! It's just taking it
to the next level .

A "user" in your terms CANNOT perform "admin" tasks. They can start a
program that asks for admin credentials, but the ADMIN is actually the one
performing the task or delegating the task to the user if they chose to
authenticate, even though it is running on the user's desktop. Why force the
admin to log in to a completely seperate profile in order to accomplish
something that he might as well be able to do from any account?

You may think "well it makes it too easy for a user to get an admin password
and use it improperly" - this is EXACTLY the case in the "old way" as well!
The only thing that has changed is that it is now easier and quicker for
admins to use and/or delegate their powers, as compared to Windows XP (as
you pointed out XP can do this as well, but Vista makes this much easier).

Similarly, an ADMIN is not limited in any way with UAC turned on; he has all
the powers that his account is assigned. PROGRAMS are, however, limited.
Some programs act as if they are run by a standard user; but the admin can
override this. I mean really, WHY does the calculator need to have
privileges to format the hard drive? Why should I be worry that if I press
the "+" button in the wrong way it will fry my hard drive?

Admins are still admins and users are still users. USER/ADMIN ACCOUNTS have
a set amount of privileges, and they CANNOT VIOLATE THESE privileges. UAC
adds an abstraction layer BELOW the account abstraction, that further allows
privileges to be removed from application that run from within a user
account. And, the system also allows a program to be run in the context of
another user account (and all the privileges thereof) on any desktop, but
since it requires the OTHER USER to authenticate, this does not violate the
abstraction.

Things work differently now than they did in the past, but the abstraction
is still pure. Just because it's different doesn't make it bad.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/