UAC failed to ask for confirmation. Bug?

[Roof Fiddler]

Running RC2 with default UAC settings and default filesystem ACLs, logged in
as an administrator, I pressed win+e to open windows explorer (thus explorer
was not run as administrator) and browsed to another user's home directory,
and read a file therein, and got no UAC confirmation prompt.
Wasn't I supposed to get a prompt?

 

[Dr. Network]

I was just getting ready to post a similar bug. I'm running RC2, build 5744.

I'm sitting in a Vista developer class right now and learning about the
manifest that are required to make an exceutable elevate to
requireAdministrator when it starts up. I'm logged on as a local
administrator on my laptop. UAC is turned on. I open control panel and the
User Accounts. With UAC on, anything with a shield should prompt me to
elevate to the administrator token. I click on "Turn User Accounts On or
Off", which has a shield next to it. I'm not getting prompted.

I cycled UAC off and on (two reboots). On the second reboot, the Explorer
shell seemed to hang. Killed it in Task Manager and restarted it in Task
Manager.

I'm still not prompted by a Shield task even with UAC on. It is as if UAC
were not on.

Is anyone else having this problem?

Thanks,

Chuck

 

[Dr. Network]

I cycled my OS one more time. I'm still not getting prompted for Shield icon
tasks with UAC turned on.

Why not? Is there some setting that causes the UAC prompting to turn off? I
don't think there should be. Obviously I've done it somehow. What gives?

Chuck

 

[Dr. Network]

I figured out my problem. In Local Security Policy, I had "User Account
Control: Behavior of the elvation prompt for administrators in Admin
Approval Mode" set to "Elevate without prompt".

This was my problem. Check your Local Security policies under the the User
Account Control settings.

Chuck

 

[Vipin]

It makes sense to prompt only if it is a program and running it requires
admin rights.

 

[Vipin]

Were you using a built-in administrator account by any chance?

 

[Roof Fiddler]

I figured out my problem. In Local Security Policy, I had "User Account
Control: Behavior of the elvation prompt for administrators in Admin
Approval Mode" set to "Elevate without prompt".

Mine's still set to "Prompt for consent" (which is the default).

 

[Roof Fiddler]

Were you using a built-in administrator account by any chance?

No.

 

[Roof Fiddler]

It makes sense to prompt only if it is a program and running it requires
admin rights.

So users are supposed to have unrestricted access to each other's files?

 

[Jimmy Brush]

Hello,

If you have browsed to this folder location before, been prompted by UAC,
and then browsed into the folder, then Windows has changed the ACL's on
those files to allow your specific username read access. This is a permanent
operation that once completed will allow you to read those files without
going thru UAC.

Explorer is not designed to elevate its entire window to administrator
privileges, which would be required in order to browse a folder that is
accessible to you only through your status as an administrator. Instead, if
you browse to a folder that you do not explicitly have access to, it
attempts to run a seperate program with admin powers that edits the securtiy
on the files to specifically give you permanent read access.

I do not agree with this behavior - I think there should at least be an
advanced button on the message box that comes up that allows you to select
how to proceed (i.e. edit security on files to give you read access, edit
security to give you full access, or do not edit security just elevate
explorer to administrator status).

 

[Roof Fiddler]

Hello,

If you have browsed to this folder location before, been prompted by UAC,
and then browsed into the folder, then Windows has changed the ACL's on
those files to allow your specific username read access.

[snip]

That's very surprising, but I'm glad to at least know what's actually
happening.
Thanks for the explanation.

I do not agree with this behavior - I think there should at least be an
advanced button on the message box that comes up that allows you to select
how to proceed

I certainly agree with you. It could be a security hole; when Explorer
modifies ACLs like that, it's granting read access to that user's other
processes as well, and such processes might not be trusted to have such
access. Do you know whether the people in charge of deciding that Explorer
should silently modify ACLs have offered any explanation to justify that
behavior?

 

[Jimmy Brush]

That's very surprising, but I'm glad to at least know what's actually
happening.
Thanks for the explanation.

No problem.

Do you know whether the people in charge of deciding that Explorer should
silently modify ACLs have offered any explanation to justify that
behavior?

Well, I haven't read anything from the shell or security teams about this
behavior. I imagine this was put in place to allow for people who upgrade or
dual-boot earlier versions of Windows. In this scenario, you won't have
access to files created in the other OS. With this functionality in place,
Vista will give you read access to these files when you try to access them
from explorer. Unfortunately, most people also want WRITE access to their
files as well, so this ends up confusing things more than helping in my
opinion.

I think the correct behavior would be:

1) Change the "edit security" dialog to allow the user to chose what action
to take: elevate to admin and access the files as an administrator while
leaving security in tact, change the security to give read access, or change
the security to give full control

2) Make the "edit securtiy" dialog to show up when restricted files are
accessed by ANY MEANS - currently, it only shows up when using explorer ..
it doesn't show up when you are accessing files from any other program. This
would be very challenging, though not impossible, to implement while still
allowing my changes in #1.

 

[Gerry Hickman]

Hi,

Maybe I'm misunderstanding something here, but did he say that merely
browsing to a restricted folder, but then clicking UAC, will actually
CHANGE the ACL's on that folder???

I certainly hope this isn't the case!

 

[Jimmy Brush]

Here's what happens:

- You browse to a folder to which you do not have any access to (no read, no
write, etc)
- The shell prompts you with a message: "You don't currently have permission
to access this folder. Click continue to get access to this folder."
[Contine | Cancel]
- You click continue
- You are prompted via UAC to authenticate or authorize in order to run a
secondary program ("edit security") with admin privileges
- The "edit security" program runs in the backgrouns and adds a single ACL
entry into all folders, subfolders, and files in that folder that grants
your specific username read, execute, read attribs, read extended attribs,
and read permissions permission.

If the folder you are attempting to browse to is inaccessible to both you
and the administrators group, a message will be displayed: "You have been
denied permission to access this folder. To gain access to this folder you
will need to use the security tab"

 

[Gerry Hickman]

Hi Jimmy,

The bit I don't like the sound of is where you say "runs in the
background", it sounds like it changes ACLs behind your back?

If you are saying it pops up the security tab on the folder properties
dialog, that's different, as you'd see what it was doing and could
cancel out of it.

This seems (to me) another disadvantage of UAC, it's just an OK button
so how does anyone know what is going to happen next?

"Program abc.exe is about to send all your bank details over the
internet, click OK to continue". Hmm.

Here's what happens:

- You browse to a folder to which you do not have any access to (no
read, no write, etc)
- The shell prompts you with a message: "You don't currently have
permission to access this folder. Click continue to get access to this
folder." [Contine | Cancel]
- You click continue
- You are prompted via UAC to authenticate or authorize in order to run
a secondary program ("edit security") with admin privileges
- The "edit security" program runs in the backgrouns and adds a single
ACL entry into all folders, subfolders, and files in that folder that
grants your specific username read, execute, read attribs, read extended
attribs, and read permissions permission.

If the folder you are attempting to browse to is inaccessible to both
you and the administrators group, a message will be displayed: "You have
been denied permission to access this folder. To gain access to this
folder you will need to use the security tab"

 

[Jimmy Brush]

Hi Jimmy,

The bit I don't like the sound of is where you say "runs in the
background", it sounds like it changes ACLs behind your back?

The windows explorer "edit security" program run at the user's request
(Explorer prompts a dialog asking the user if they want to give themselves
access to the files).

The edit security program, if given permission thru UAC, then modifies the
ACLs in the background (the progress bar in Windows Explorer shows the
progress as it is editing the security).

If you are saying it pops up the security tab on the folder properties
dialog, that's different, as you'd see what it was doing and could cancel
out of it.

It doesn't do that. The only UI that is shown is the progress bar animation
that Windows Explorer displays. You may be able to click the X next to the
address bar to stop the process, I've never tried it.

This seems (to me) another disadvantage of UAC, it's just an OK button so
how does anyone know what is going to happen next?

You're right, UAC doesn't KNOW what is going to happen. In fact, it can't
know. Windows doesn't know how a program will use admin powers; it just
knows how to approve or revoke a program to have such power. UAC is about
giving the user a choice - run a program with admin power or not. You are
absolutely correct - it is just an OK button. The user must decide whether
they trust the application they are using enough to allow it to have such
power.

This is not a disadvantage of UAC - it is one reason why UAC is necessary.
If Windows knew EXACTLY what a program was about to do [and more
specifically, if the user was wanting those actions to occur], it wouldn't
need to bug the user so much about whether or not to trust an application -
Windows would be able to make those sort of decisions itself.

In Windows XP, ALL PROGRAMS were given admin power - the user had no choice
whatsoever.

"Program abc.exe is about to send all your bank details over the internet,
click OK to continue". Hmm.

I wish Windows could go into so much detail

 

[Gerry Hickman]

Hi Jimmy,

The edit security program, if given permission thru UAC, then modifies
the ACLs in the background (the progress bar in Windows Explorer shows
the progress as it is editing the security).

OK, I don't like it, but thanks for explaining it so well. At least I
know how it works now!

You're right, UAC doesn't KNOW what is going to happen. In fact, it
can't know. Windows doesn't know how a program will use admin powers; it
just knows how to approve or revoke a program to have such power. UAC is
about giving the user a choice - run a program with admin power or not.
You are absolutely correct - it is just an OK button. The user must
decide whether they trust the application they are using enough to allow
it to have such power.

"The user must decide";

LOL! Have you ever seen a user trying to decide if the Sony rootkit
installer is just helping them listen to their music, or is about to
open a massive security hole in their computer? Have you ever seen a
user decide if an Embedded ActiveX control in an advertising banner is
just part of the animation, or is actually something else? The whole
point is that the user has NO IDEA what is happening. The user does not
know how to load every program into a disassembler and monitor every
socket and comms channel. The user is therefore NOT qualified to click UAC.

In Windows XP, ALL PROGRAMS were given admin power - the user had no
choice whatsoever.

No they were not! Perhaps on badly configured systems where users were
running with Admin rights (as default dictated by Microsoft).

All they needed to do was have an installer account (that does not have
internet access) and a user account where people can check their email
and look at their holiday snaps.

The way I see it, UAC is a watered-down half-measure that was only
introduced because Microsoft didn't have the guts to set user accounts
as defaults. Hell, they even watered down the security on the user
accounts by making them able to redirect HKLM!

 

[Jimmy Brush]

The user does not know how to load every program into a disassembler and
monitor every socket and comms channel. The user is therefore NOT
qualified to click UAC.

Do you know how to do those things? And if you do, do you do those things
before/while running every application? I certainly wouldn't know enough
about these things to get anything meaningful out of the analysis. I go by
my gut feeling when deciding on whether to run a program with admin rights.
And that's something all users can do, regardless of their technical
experience.

UAC is putting control in the user's hands for them to make these high-level
decisions about what programs to give complete control over their computer,
on an as-it-happens basis. It is not about low-level things like com ports
and sockets.

If the user has heard about those nasty rootkits and doesn't want to allow
sony software full control of their computer, UAC is the means that allows
them to stop this from happening. If the user could care less, then so be
it. Point is, they have the control.

The user is the only one qualified to click UAC, because that is who UAC is
for - the user of the computer. To allow them control over the programs they
run. If they don't know how or don't want to use it, then they don't have
to. If they do know how or want to learn how, they now have the power.

Trust isn't about analyzing the program to see what bits it is moving
around; a computer can do that. Trust is about the user deciding whether
they want a program they are running to have complete, unrestricted access
to their computer based on what they are doing at the time and what they
know about the author of the program. This is something the computer can't
do.

No they were not! Perhaps on badly configured systems where users were
running with Admin rights (as default dictated by Microsoft).

Well, the majority of people were running "badly configured systems" per
your definition here. Microsoft is fixing their previous mistake thru UAC

All they needed to do was have an installer account (that does not have
internet access) and a user account where people can check their email and
look at their holiday snaps.

Sure ... assuming Microsoft wants to break compatibility with every software
program known to man.

The way I see it, UAC is a watered-down half-measure that was only
introduced because Microsoft didn't have the guts to set user accounts as
defaults. Hell, they even watered down the security on the user accounts
by making them able to redirect HKLM!

UAC waters down nothing - UAC implements a pure security model while still
allowing older applications to work. Running as an administrator in UAC is
*exactly* the same as running as a standard user in XP/Vista and using a
seperate admin account to install programs. There was no compromise in
security - the only difference is the UAC model provides application
compatibility and a slightly better user experience.

I don't see an obvious security vulnerability created by a per-user
recreation of HKLM that only non-vista-compatible programs can see. The
changes/settings stored there don't affect anything global - they only
affect the application that writes those settings there.