Built-in admin account

I created a standard user account to use for my daily activities thinking I
could just use run as administrator when necessary. I was thinking that
this "best practice" might actually be more practical on Vista whereas on XP
its not possible to "run as..." on control panel apps, active x installers,
etc but in vista since these are marked as requires admin it should prompt
me even when I am logged in as a standard user.

I was doing okay for short while with uac enabled but then had issues
accessing my usb drive. When I attempted access the files I recieved no
prompt and an access denied error, and windows exporer does not provide a
run as administrator to access files, so I grumble a bit and login as
administator, but guess what... thanks to the UAC split token my
administrator account is not really an administrator so when I attempt to
access the drive I again recieve an access denied error and no elevation
prompt. It took me a bit to discover that I had removed Everyone from the
ACL on my USB drive when I was using XP as I use it for backups and I didn't
want some application writing to it when I was logged in as a standard user,
had I realized that was the problem I could have changed the ACL via
elevation when logged in as my standard user but it brings up an interesting
question....

What exactly is the advantage (if you can call it that) of the split-token
except the ability to elevate by pressing continue instead of typing in
credentials, yea!, but at the expense of numerous application compatiblity
issues. Why UAC decided best practice is to create administrative accounts
that are actually standard user accounts with credential-less elevation is
beyond me, instead they should have created a third type of user Standard
User With Approved Admin group for credential-less elevation and leave the
administrator account alone! Correct me if I'm wrong but with UAC enabled
if I can't perform the task as a standard user then I won't be able to
perform the task as an administrator either! And so, if I need to login as
administrator I want every process I run to actually run as administrator
even when (especially when) the application is not marked as requiring
administrator privilages (if it was I could have performed the task via
elevation from my standard user account), as far as I know the only way to
do that is disable UAC because automatic elevation still requires the app to
be marked as requires admin or the use of run as administrator.

I thought the solution to this would be rather simple, just disable UAC.
However once I disabled UAC I found my standard user account no longer
prompts for credentials when I click run as administrator (just runs
normally as my standard user) and IE Protected mode no longer works! So my
question can I somehow login as the built-in adminstrator when I really want
and/or need a real administrator token due to some compatibility issue with
an app not marked as requires admin rather then disable UAC?

- Kurt

Hello,

<snip>
> What exactly is the advantage (if you can call it that) of the split-token
> except the ability to elevate by pressing continue instead of typing in
> credentials, yea!, but at the expense of numerous application compatiblity
> issues.

The majority of users operate their computer while logged in as an
administrator. The benefit here is that the applications that need admin
access can get it *easily* from the user (not requring a complete log-in),
while the majority of programs that DON'T need admin access don't have it.

Also, running "administrative" programs in the context of another user
seperate from the main user on the same desktop introduces some pretty
severe application compatability issues itself [think seperate registry
hives and program storage locations] - the split-token solution is superior
to this in my opinion.

> Why UAC decided best practice is to create administrative accounts that
> are actually standard user accounts with credential-less elevation is
> beyond me, instead they should have created a third type of user Standard
> User With Approved Admin group for credential-less elevation and leave the
> administrator account alone!

Essentially, what you have described is what was done.

Built-in admin account: all programs run with admin permission. This account
is disabled by default and is not intended to be used except in an emergency
(i.e. no other admin accounts are available and the computer is in safe
mode).

Administrators group: "standard user" with on-demand approval required for
admin permission usage

Users group: "standard user", must log in as an admin user in order to run
administrative programs

> Correct me if I'm wrong but with UAC enabled if I can't perform the task
> as a standard user then I won't be able to perform the task as an
> administrator either!

"Run as administrator" is your friend in both scenarios. If you are trying
to do something that won't work, and you suspect that it is because the
application is not prompting for admin permission, then you must run the
program explicitly with admin permission by right-clicking it and clicking
run as administrator.

It is the application's responsibility to automatically prompt you for admin
rights usage, not Windows.

Granted, there is no way to do Run As Administrators on files; instead, you
have to use Run As Administrator on the program that is used to access those
files.

But, there is nothing that you can't do in a UAC-restricted admin account
that you CAN do with UAC off. You may have to learn a new way to do it (run
as administrator), but it is possible.

> And so, if I need to login as administrator I want every process I run to
> actually run as administrator even when (especially when) the application
> is not marked as requiring administrator privilages (if it was I could
> have performed the task via elevation from my standard user account), as
> far as I know the only way to do that is disable UAC because automatic
> elevation still requires the app to be marked as requires admin or the use
> of run as administrator.

This "run every process as admin" is disabled by default because of its
inherent insecurity. All applications do not require admin permissions - it
is kind of foolish to allow all of them to have such permision.

> I thought the solution to this would be rather simple, just disable UAC.
> However once I disabled UAC I found my standard user account no longer
> prompts for credentials when I click run as administrator (just runs
> normally as my standard user) and IE Protected mode no longer works! So
> my question can I somehow login as the built-in adminstrator when I really
> want and/or need a real administrator token due to some compatibility
> issue with an app not marked as requires admin rather then disable UAC?

The best solution is to mark the application as requiring admin permissions
yourself. Right-click the program, click proeprties, click the compatability
tab, and then check run this program as administrator. You can also do this
on a shortcut: right-click it, properties, advanced button, check run as
administrator.

You can also enable the built-in administrator account, which is excluded
from "admin approval mode", using local users and groups in computer
management. However, note that while logged in as the built-in administrator
you don't get the benefits of UAC either (i.e. protected mode in IE). If you
decide to use this account, you should use it sparingly.


--
- JB

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

Hi,

The way I see it, elevation should simply not be allowed at all.

Since year 2000 we've been running all our apps with user rights and
none of our users have Admin password so it's impossible for them to
"Run as Administrator".

The sheer complexity of Vista and UAC is demonstrated by the amount of
text in this single NNTP thread!

I may be wrong, but it's quite possible this level of complexity (and
ability to elevate) will offer new and exciting opportunities for
hackers and virus writers.

Jimmy Brush wrote:
> Hello,
>
> <snip>
>> What exactly is the advantage (if you can call it that) of the
>> split-token except the ability to elevate by pressing continue instead
>> of typing in credentials, yea!, but at the expense of numerous
>> application compatiblity issues.
>
> The majority of users operate their computer while logged in as an
> administrator. The benefit here is that the applications that need admin
> access can get it *easily* from the user (not requring a complete
> log-in), while the majority of programs that DON'T need admin access
> don't have it.
>
> Also, running "administrative" programs in the context of another user
> seperate from the main user on the same desktop introduces some pretty
> severe application compatability issues itself [think seperate registry
> hives and program storage locations] - the split-token solution is
> superior to this in my opinion.
>
>> Why UAC decided best practice is to create administrative accounts
>> that are actually standard user accounts with credential-less
>> elevation is beyond me, instead they should have created a third type
>> of user Standard User With Approved Admin group for credential-less
>> elevation and leave the administrator account alone!
>
> Essentially, what you have described is what was done.
>
> Built-in admin account: all programs run with admin permission. This
> account is disabled by default and is not intended to be used except in
> an emergency (i.e. no other admin accounts are available and the
> computer is in safe mode).
>
> Administrators group: "standard user" with on-demand approval required
> for admin permission usage
>
> Users group: "standard user", must log in as an admin user in order to
> run administrative programs
>
>> Correct me if I'm wrong but with UAC enabled if I can't perform the
>> task as a standard user then I won't be able to perform the task as an
>> administrator either!
>
> "Run as administrator" is your friend in both scenarios. If you are
> trying to do something that won't work, and you suspect that it is
> because the application is not prompting for admin permission, then you
> must run the program explicitly with admin permission by right-clicking
> it and clicking run as administrator.
>
> It is the application's responsibility to automatically prompt you for
> admin rights usage, not Windows.
>
> Granted, there is no way to do Run As Administrators on files; instead,
> you have to use Run As Administrator on the program that is used to
> access those files.
>
> But, there is nothing that you can't do in a UAC-restricted admin
> account that you CAN do with UAC off. You may have to learn a new way to
> do it (run as administrator), but it is possible.
>
>> And so, if I need to login as administrator I want every process I run
>> to actually run as administrator even when (especially when) the
>> application is not marked as requiring administrator privilages (if it
>> was I could have performed the task via elevation from my standard
>> user account), as far as I know the only way to do that is disable UAC
>> because automatic elevation still requires the app to be marked as
>> requires admin or the use of run as administrator.
>
> This "run every process as admin" is disabled by default because of its
> inherent insecurity. All applications do not require admin permissions -
> it is kind of foolish to allow all of them to have such permision.
>
>> I thought the solution to this would be rather simple, just disable
>> UAC. However once I disabled UAC I found my standard user account no
>> longer prompts for credentials when I click run as administrator (just
>> runs normally as my standard user) and IE Protected mode no longer
>> works! So my question can I somehow login as the built-in
>> adminstrator when I really want and/or need a real administrator token
>> due to some compatibility issue with an app not marked as requires
>> admin rather then disable UAC?
>
> The best solution is to mark the application as requiring admin
> permissions yourself. Right-click the program, click proeprties, click
> the compatability tab, and then check run this program as administrator.
> You can also do this on a shortcut: right-click it, properties, advanced
> button, check run as administrator.
>
> You can also enable the built-in administrator account, which is
> excluded from "admin approval mode", using local users and groups in
> computer management. However, note that while logged in as the built-in
> administrator you don't get the benefits of UAC either (i.e. protected
> mode in IE). If you decide to use this account, you should use it
> sparingly.
>
>


--
Gerry Hickman (London UK)

Don't run QuickBooks, do you? :-)

If you've been running your users as "Power Users" there's no essential
difference between that level of rights and Administrator rights in XP/2000.
Power Users have only a very few limits on their rights compared to
Administrators as far as the end-user box goes.

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.

--
Richard G. Harper [MVP Shell/User] rgharper@gmail.com
* NEW! Catch my blog ... http://msmvps.com/blogs/rgharper/
* PLEASE post all messages and replies in the newsgroups
* The Website - http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm


"Gerry Hickman" <gerry666uk@newsgroup.nospam> wrote in message
news:ueyK%23k8DHHA.4464@TK2MSFTNGP06.phx.gbl...
> Hi,
>
> The way I see it, elevation should simply not be allowed at all.

"Gerry Hickman" <gerry666uk@newsgroup.nospam> wrote in message
news:ueyK%23k8DHHA.4464@TK2MSFTNGP06.phx.gbl...
> Hi,
>
> The way I see it, elevation should simply not be allowed at all.
>
> Since year 2000 we've been running all our apps with user rights and none
> of our users have Admin password so it's impossible for them to "Run as
> Administrator".

And it still is impossible with UAC. Of course, the "ideal" situation is not
yet possible for the majority of people, primarily due to application and
even system incompatibility with standard user mode. UAC is the means by
which it will become possible.

> The sheer complexity of Vista and UAC is demonstrated by the amount of
> text in this single NNTP thread!

UAC is a very, very simple change to the core architecture of Windows. Don't
mistake my attempt to explain it as a representation of its complexity

> I may be wrong, but it's quite possible this level of complexity (and
> ability to elevate) will offer new and exciting opportunities for hackers
> and virus writers.

If you consider trying to defeat a very well-implemented and challenging
security model as "new and exciting", then I completely agree with you.


--
- JB

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

> Hello,
>
> <snip>
>> What exactly is the advantage (if you can call it that) of the
>> split-token except the ability to elevate by pressing continue instead of
>> typing in credentials, yea!, but at the expense of numerous application
>> compatiblity issues.
>
> The majority of users operate their computer while logged in as an
> administrator. The benefit here is that the applications that need admin
> access can get it *easily* from the user (not requring a complete log-in),
> while the majority of programs that DON'T need admin access don't have it.
>
> Also, running "administrative" programs in the context of another user
> seperate from the main user on the same desktop introduces some pretty
> severe application compatability issues itself [think seperate registry
> hives and program storage locations] - the split-token solution is
> superior to this in my opinion.
>
>> Why UAC decided best practice is to create administrative accounts that
>> are actually standard user accounts with credential-less elevation is
>> beyond me, instead they should have created a third type of user Standard
>> User With Approved Admin group for credential-less elevation and leave
>> the administrator account alone!
>
> Essentially, what you have described is what was done.

Not really, there is no longer an administrative group. IMHO it creates a
great deal of ambiguity, especially regarding remote administration. As an
administrator I should be able to access administrative shares or use the
computer management snapin from another computer, etc... yet at the same
time I only want this permissions if I connect to the computer as an
admistrator account. Since vista's best practice is to create
pseudo-administrator accounts then users could perform these activities
remotely with no-prompt. That doesn't seem that bad at first after all you
might think that such activities require the user to open computer
management right click computer and connect to another computer, surely they
are doing it on purpose. However, this could leave the door open for
exploits from software running running on an XP computer with their
credentials even if that XP account is a non-administrator if the
user/password is the same as their Vista pseudo-admin account, which is
usually the case for laptop users like myself that want to be access shares
without having a domain controller and without being prompted all the time.

I will admit that if you make it to easy to login to the admin account users
will create start creating real admin accounts again and vendors will feel
less pressure to seperate standard user and admin functionality. But IMHO
it was just the wrong approach entirely, I wish it worked more like the .NET
CLR security where every application could be granted a permission set and
the application would receive the intersection of the user permissions and
the desired permissions, if it doesn't have enough permissions a user with
the required permssions would grant the application permission to run as his
user account and set the allowed permission set. Unfortunatly MS believes
that SUID used by every other (more secure) OS is evil. But we see how well
that worked out in XP because without SUID users were forced to use an admin
account. Even with Vista users must either have an admin account or know
the administrator password to perform any administrative task even if the
administrator would be willing to grant the user permissions for that
specific task or specific application they can't do so (at least not without
having considerable development skills necessary to create a secure windows
service or com+ application to perform the elevated task as a service user).
Not nearly the same granularity provided by SUID. IMHO, until MS has the
experience to become truely inovative they should stick with what works well
on other platforms rather then bashing it as the most common cause of
elevation attacks on other platforms, because the most common source of
elevation attacks on windows is having users login as administrator, MS has
a far worse problem and I think they need to reconsider.

>
> Built-in admin account: all programs run with admin permission. This
> account is disabled by default and is not intended to be used except in an
> emergency (i.e. no other admin accounts are available and the computer is
> in safe mode).
>
> Administrators group: "standard user" with on-demand approval required for
> admin permission usage
>
> Users group: "standard user", must log in as an admin user in order to run
> administrative programs
>
>> Correct me if I'm wrong but with UAC enabled if I can't perform the task
>> as a standard user then I won't be able to perform the task as an
>> administrator either!
>
> "Run as administrator" is your friend in both scenarios. If you are trying
> to do something that won't work, and you suspect that it is because the
> application is not prompting for admin permission, then you must run the
> program explicitly with admin permission by right-clicking it and clicking
> run as administrator.
>
> It is the application's responsibility to automatically prompt you for
> admin rights usage, not Windows.
>
> Granted, there is no way to do Run As Administrators on files; instead,
> you have to use Run As Administrator on the program that is used to access
> those files.

I suppose I could use another less friendly program like cmd shell to copy
files, just not windows explorer - the most common windows application used
to manage files and folders, I can change the permissions but I actually
prefer that I can't access those files unless I login as administrator so
that I or some other software doesn't accidently corrupt them, and changing
permissions back after I'm done is going to be forgotten at some point.

>
> But, there is nothing that you can't do in a UAC-restricted admin account
> that you CAN do with UAC off. You may have to learn a new way to do it
> (run as administrator), but it is possible.

This worked so well in XP I don't know why have doubts that I'm going to be
able to right click and run as administrator every time I need it - control
panel apps, active x controls, shell extensions etc, were not possible to
run as in XP. Control panel and active x issues have hopefully been
resolved but still no run as for explorer so hopefully I wont need
administrative shell extensions, as it is if it requires admin I'm assuming
these aren't going to work until updated for vista.


>
>> And so, if I need to login as administrator I want every process I run to
>> actually run as administrator even when (especially when) the application
>> is not marked as requiring administrator privilages (if it was I could
>> have performed the task via elevation from my standard user account), as
>> far as I know the only way to do that is disable UAC because automatic
>> elevation still requires the app to be marked as requires admin or the
>> use of run as administrator.
>
> This "run every process as admin" is disabled by default because of its
> inherent insecurity. All applications do not require admin permissions -
> it is kind of foolish to allow all of them to have such permision.

Mostly just windows explorer.

>
>> I thought the solution to this would be rather simple, just disable UAC.
>> However once I disabled UAC I found my standard user account no longer
>> prompts for credentials when I click run as administrator (just runs
>> normally as my standard user) and IE Protected mode no longer works! So
>> my question can I somehow login as the built-in adminstrator when I
>> really want and/or need a real administrator token due to some
>> compatibility issue with an app not marked as requires admin rather then
>> disable UAC?
>
> The best solution is to mark the application as requiring admin
> permissions yourself. Right-click the program, click proeprties, click the
> compatability tab, and then check run this program as administrator. You
> can also do this on a shortcut: right-click it, properties, advanced
> button, check run as administrator.
>
> You can also enable the built-in administrator account, which is excluded
> from "admin approval mode", using local users and groups in computer
> management. However, note that while logged in as the built-in
> administrator you don't get the benefits of UAC either (i.e. protected
> mode in IE). If you decide to use this account, you should use it
> sparingly.
>
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/

<snip>
> Not really, there is no longer an administrative group. IMHO it creates a
> great deal of ambiguity, especially regarding remote administration.
> [...]

Actually, a member of the administrators group has been redefined as only a
'local' administrator - his power is only good at the console (or when
logged in via remote desktop) - he has no admin rights when authentciated
via the network as you suggest.

This behavior, of course, can be changed via group policy, and is discussed
elsewhere.

Basically, ANY TIME an administrator local to a computer tries to use his
admin power, he/she must be able to authenticate with the computer thru UAC
so that the computer knows that he is the one requesting that the action
take place.

If this authentication is not possible, than the action does not take place.

Domain-level administrators are not constrained in this manner.

> I wish it worked more like the .NET CLR security where every application
> could be granted a permission set and the application would receive the
> intersection of the user permissions and the desired permissions, if it
> doesn't have enough permissions a user with the required permssions would
> grant the application permission to run as his user account and set the
> allowed permission set.

Essentially, it does kind-of work like this beneath-the-covers, but not to
the extent in .net, and certainly not to the extent of SUID.

However, you have to realize the problem UAC is solving: it prevents
privilege escalation without admin consent. Esentially, UAC enforces
privilege barriers, and in order to transcend from one to the other, the
user must consent to the transition, assuming the user has permission to
access the higher privilege.

In your scenario, sure the rights assigned to the program would fit the
program like a glove and would thus provide maximum security with minimum
loss of functionality; however, the problem of privilege escalation remains.
A program could execute a program with more permissive privileges and then
exploit this other programs behavior. Or, a program could request privileges
that it does not need, and then abuse the power.

In essense, the user/admin has control at installation time (choosing the
permissions to be applied to the program), but after that, the user no
longer has control, and the UAC model is broken.

UAC is Windows' way of allowing a user to control the power programs have.
This control only remains "pure" if it is asked EVERY time programs try to
use this power. If a permission state is permanently applied to a program,
then that program is no longer under the user's control, and other program
can take advantage of that program to circumvent the security. This would
introduce an architectural bug into UAC - its very design would allow itself
to be circumvented.

I am in agreement that something similar to SUID is needed; however, I don't
think that this would replace the current UAC behavior, but rather augment
it.

> Unfortunatly MS believes that SUID used by every other (more secure) OS is
> evil.

It's not that it's evil. It's just that the security model MS is trying to
enforce cannot be enforced with that behavior in place

> But we see how well that worked out in XP because without SUID users were
> forced to use an admin account. Even with Vista users must either have an
> admin account or know the administrator password to perform any
> administrative task even if the administrator would be willing to grant
> the user permissions for that specific task or specific application they
> can't do so (at least not without having considerable development skills
> necessary to create a secure windows service or com+ application to
> perform the elevated task as a service user). Not nearly the same
> granularity provided by SUID. IMHO, until MS has the experience to become
> truely inovative they should stick with what works well on other platforms
> rather then bashing it as the most common cause of elevation attacks on
> other platforms, because the most common source of elevation attacks on
> windows is having users login as administrator, MS has a far worse problem
> and I think they need to reconsider.

You're right, Windows doesn't allow for programs to run with admin power
when launched by a standard user. Instead, an admin must provide
over-the-shoulder credentials or launch this admin process his/herself. I
don't see this behavior as ever changing, even if Windows does implement
something like SUID. A user is granted X permissions - they should not be
able to run programs with >X permissions.

> I suppose I could use another less friendly program like cmd shell to copy
> files, just not windows explorer - the most common windows application
> used
> to manage files and folders, I can change the permissions but I actually
> prefer that I can't access those files unless I login as administrator so
> that I or some other software doesn't accidently corrupt them, and
> changing permissions back after I'm done is going to be forgotten at some
> point.

In earlier builds of Vista, you could run-as-administrator Windows Explorer.
Unfortunately, I have yet to install Vista RTM, so I'm not sure what RTM
behavior is.

> This worked so well in XP I don't know why have doubts that I'm going to
> be able to right click and run as administrator every time I need it -
> control
> panel apps, active x controls, shell extensions etc, were not possible to
> run as in XP. Control panel and active x issues have hopefully been
> resolved but still no run as for explorer so hopefully I wont need
> administrative shell extensions, as it is if it requires admin I'm
> assuming these aren't going to work until updated for vista.

You're right - the scenarios you mention will require updated versions in
order to work right "out of the box". As I said earlier, I am not 100% sure
if Explorer can be run-as-administratored (I know it couldn't in XP, but in
some Vista builds it could). If it can, then that would allow the scenarios
you mentioned to work thru user intervention.


--
- JB

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

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:B17C9F66-922E-4E3A-A31D-A76F745D3AF7@microsoft.com...
> <snip>
>> Not really, there is no longer an administrative group. IMHO it creates
>> a great deal of ambiguity, especially regarding remote administration.
>> [...]
>
> Actually, a member of the administrators group has been redefined as only
> a 'local' administrator - his power is only good at the console (or when
> logged in via remote desktop) - he has no admin rights when authentciated
> via the network as you suggest.
>
> This behavior, of course, can be changed via group policy, and is
> discussed elsewhere.
>
> Basically, ANY TIME an administrator local to a computer tries to use his
> admin power, he/she must be able to authenticate with the computer thru
> UAC so that the computer knows that he is the one requesting that the
> action take place.
>
> If this authentication is not possible, than the action does not take
> place.
>
> Domain-level administrators are not constrained in this manner.

Okay, that seems resonable to me, no open doors unless the user opens it
via the group policy and domain admins can still do their job effectively.

>
>> I wish it worked more like the .NET CLR security where every application
>> could be granted a permission set and the application would receive the
>> intersection of the user permissions and the desired permissions, if it
>> doesn't have enough permissions a user with the required permssions would
>> grant the application permission to run as his user account and set the
>> allowed permission set.
>
> Essentially, it does kind-of work like this beneath-the-covers, but not to
> the extent in .net, and certainly not to the extent of SUID.
>
> However, you have to realize the problem UAC is solving: it prevents
> privilege escalation without admin consent. Esentially, UAC enforces
> privilege barriers, and in order to transcend from one to the other, the
> user must consent to the transition, assuming the user has permission to
> access the higher privilege.
>
> In your scenario, sure the rights assigned to the program would fit the
> program like a glove and would thus provide maximum security with minimum
> loss of functionality; however, the problem of privilege escalation
> remains. A program could execute a program with more permissive privileges
> and then exploit this other programs behavior. Or, a program could request
> privileges that it does not need, and then abuse the power.
>
> In essense, the user/admin has control at installation time (choosing the
> permissions to be applied to the program), but after that, the user no
> longer has control, and the UAC model is broken.
>
> UAC is Windows' way of allowing a user to control the power programs have.
> This control only remains "pure" if it is asked EVERY time programs try to
> use this power. If a permission state is permanently applied to a program,
> then that program is no longer under the user's control, and other program
> can take advantage of that program to circumvent the security. This would
> introduce an architectural bug into UAC - its very design would allow
> itself to be circumvented.
>
> I am in agreement that something similar to SUID is needed; however, I
> don't think that this would replace the current UAC behavior, but rather
> augment it.
>
>> Unfortunatly MS believes that SUID used by every other (more secure) OS
>> is evil.
>
> It's not that it's evil. It's just that the security model MS is trying to
> enforce cannot be enforced with that behavior in place
>
>> But we see how well that worked out in XP because without SUID users were
>> forced to use an admin account. Even with Vista users must either have
>> an admin account or know the administrator password to perform any
>> administrative task even if the administrator would be willing to grant
>> the user permissions for that specific task or specific application they
>> can't do so (at least not without having considerable development skills
>> necessary to create a secure windows service or com+ application to
>> perform the elevated task as a service user). Not nearly the same
>> granularity provided by SUID. IMHO, until MS has the experience to
>> become truely inovative they should stick with what works well on other
>> platforms rather then bashing it as the most common cause of elevation
>> attacks on other platforms, because the most common source of elevation
>> attacks on windows is having users login as administrator, MS has a far
>> worse problem and I think they need to reconsider.
>
> You're right, Windows doesn't allow for programs to run with admin power
> when launched by a standard user. Instead, an admin must provide
> over-the-shoulder credentials or launch this admin process his/herself. I
> don't see this behavior as ever changing, even if Windows does implement
> something like SUID. A user is granted X permissions - they should not be
> able to run programs with >X permissions.
>

I don't really have a problem with the prompts for elevation, but rather the
inability for an administrator to pre-approve a program to run with elevated
permissions, without the user knowing the administrative password. To grant
the user permission to run a single administrative task the administrator
must grant him permission to run every administrative task.

I was once a unix administrator and we had a support team that would perform
various administrative tasks such as installing updates on the client
systems which required root permissions. When we were rather small those
tasks were performed as root user by someone with enough experience to
perform the activities correctly. As we grew in size, and rather quickly,
we often had to perform many of the same activities on dozens of systems
which became too much of a burden on us and we began adding more support
personel that would work from set of instructions. One of our support guys
however was not so careful with his typing and thinking he had learned a few
tricks attempted to remove a directory tree with rm -r * which accidentially
became rm -r /* and I was on a plane by the end of the day. The problem was
that these tasks required root permissions and our support staff therefore
needed to login as root to perform these tasks. After that incident we
developed shell scripts to perform all root tasks that would be performed by
our support team, we marked these scripts to run as root and granted only
the support users access to these scripts, the root passwords were changed
and it never happened again.

This is why I think SUID is so great, because of this experience I can see
the need to grant a subset of the administrative tasks to specific user
groups. It is not impossible on windows, but requires a develper to write a
windows service or com+ application to perform the task as a service user on
the users behalf, which is usually is not a task the average administrator
can perform and if developed incorrectly could open the system up to other
unintended exploits. However with SUID all that the administrator needed to
do was to grant an application permissions to run as specified user and
restrict the ACLs to the desired user groups. These type of SUID
applications may not require any IPC, a simple command line application or
gui with a few with the pre-approved task this user can perform.

My concern with Vista is that we will see an explosion of applications that
install windows services to perform administrative tasks later without
prompts and self updating applications with apis like
installupdate(filename), which because they are running in the background
necessarily require some form of IPC to communicate with the client
application and so they may also open the door to potential exploits that
may have been avoided if IPC was not required.
I could careless if the user was prompted before running a SUID application
and Vista could easily prompt the user that this application runs as an
elevated user... do you want to continue? But the windows alternatives do
not really give Vista a chance to ask concent, when and how often do you ask
for concent on a windows service? I have a feeling that the next major
security issue in windows is going to poorly written services and microsoft
is again going blame vendors, block services and com+ apps afrom installing
without explicit concent prevent services from communicating with
nonadministrative users, etc

Vista will be difficult if not impossible for some users to use if they
don't have an administrative password. Administrators are not going to want
to come around to every workstation in the morning and type in his
credentials so users can run a specific application without knowing the
administrative password. Requiring the user to be an administrator or
provide administrative credentials defeats the benefits of SUID. If all
unix users always knew the root password there would have been no need for
SUID.

UAC may be a step in the right direction however as it does allow the user
to have multiple security tokens to resolve registry and user specific path
issues which may be necessary in a windows environment and having the
ability to prompt for concent before running an SUID could be useful. But I
don't see how SUID could possibly be useful if the user must first have the
required permissions and/or aquire them before running the application.

The purpose of SUID applications is not to elevate the users permissions but
rather to take them away. SQL Server is a good example. In order to grant
the user a subset of the ACLs on the database file, ie modify table data but
not schema or database elements, you must first grant another user (SQL
Service User) permissions to the necessary resources, develop an SUID
application (SQL Server Service) to perform those activities on the users
behalf, grant the user permissions to use this application, and then you can
take away these permissions from the user. This is much more secure then an
access database where the user can either access the database or he cannot,
with SQL Server the user does not need to have permission to write directly
to the database file to modify the contents of a table, in fact allowing the
user to do so would allow also allow the user to bypass SQL security and
modify not just the table contents, but truncate the entire database.

<snip>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/

<snip>
> I don't really have a problem with the prompts for elevation, but rather
> the inability for an administrator to pre-approve a program to run with
> elevated permissions, without the user knowing the administrative
> password. To grant the user permission to run a single administrative
> task the administrator must grant him permission to run every
> administrative task.

The problem here is that users are assigned rights to do certain things, and
programs inherit these rights from the user - not the other way around. SUID
violates this abstraction, resulting in potential privilege escalation. This
is a conceptually flawed design.

This is just as bad, perhaps even worse, as the example given where a
programmer [incorrectly, I should add] creates a service to expose some
admin functionality which is consumable by all applications, because in the
case of SUID, not only can other programs take advantage of the rights given
to the SUID program, but the user can DIRECTLY take advantage of this leaky
privilege to escalate his/her privileges, without programming anything.

> This is why I think SUID is so great, because of this experience I can see
> the need to grant a subset of the administrative tasks to specific user
> groups.

You're trying to have your cake and eat it too. I agree it tastes good, but
it comes with a price. You want your admins to be able to do X, but then
again, you don't . I understand what you are saying, but I don't think the
SUID as implemented in *nix is a correct solution.

The way I see it, you should be able to grant your admins/users rights to do
whatever it is that they need to do via user permissions. Then, you should
be able to further limit how much of those rights individual applications
can use. In this way, the programs are able to use only the rights that it
needs from the pool of rights the user is assigned.

This does not violate the programs-inherit-permissions-from-users
abstraction, but still gives you some benefits from SUID.

> It is not impossible on windows, but requires a develper to write a
> windows service or com+ application to perform the task as a service user
> on the users behalf, which is usually is not a task the average
> administrator can perform and if developed incorrectly could open the
> system up to other unintended exploits.

I agree whole-heartedly with this statement; but, as I said before, this 'if
developed incorrectly' clause applies to SUID apps as well, and perhaps is
of even greater importance.

Services are designed to provide abstract functionality that is to be
consumed by applications. This abstract functionality, although it may be
implemented using admin functionality, should not expose such admin
functionality directly to the consumer (programs). Services are to extend
the functionality of the operating system, not break the security model.

In essense, SUID moves this concept up one abstraction layer - it allows a
PROGRAM to implement some admin-type behavior, with the implicit
understanding that the program will not allow privilege escalation, and the
program is to be consumed directly by a USER. But this is incorrect design,
because privilege escalation in this scenario is unavoidable . I know this
is a very fine distinction, but it is nonetheless very different and a very
real security threat.

I am ardently aware that many programmers will misuse the service
abstraction to bypass security, and I am very concerned with and
disappointed by this behavior as well (I hope I conveyed this well enough a
few threads back . But the solution is not SUID - this is just breaking
the security abstraction even more, in a way that fundamentally can never
fit the security model.

> However with SUID all that the administrator needed to do was to grant an
> application permissions to run as specified user and restrict the ACLs to
> the desired user groups. These type of SUID applications may not require
> any IPC, a simple command line application or gui with a few with the
> pre-approved task this user can perform.

Again, if the user does not have direct permission to carry out this
pre-approved task, then allowing both the user directly and other programs
indirectly to perform this task through a specific program is still
privilege escalation! Only allowing privileges to be carried out through
certain programs is still allowing that user or programs that the user runs
to misuse that task to his/her advantage.

In the service vs. program analogy, IPC was how the lower-privileged app
talked to the higher-privileged one. In the case of SUID, this communication
channel exists, but not in the form of IPC - it exists in the form of
executing and interacting with a program. In this case, any lower-privileged
process (and the user directly) can execute a higher-privileged SUID
process, and interact with it, either via the command line options or by
other means.

However, if the program was unable to exceed the rights of the user, and the
program was limited as to what it could access/do based on the rights of the
user, then this would indeed be a very useful security tool .

> My concern with Vista is that we will see an explosion of applications
> that install windows services to perform administrative tasks later
> without prompts and self updating applications with apis like
> installupdate(filename),

I am very, VERY concerned with this as well.

> which because they are running in the background necessarily require some
> form of IPC to communicate with the client application and so they may
> also open the door to potential exploits that may have been avoided if IPC
> was not required.

IPC is conceptually the channel of communication between the non-privileged
process and the privileged one. This channel must exist in some form
whenever non-privileged meets privileged, so even though it would not be IPC
in the case of SUID, it still exists.

> I could careless if the user was prompted before running a SUID
> application and Vista could easily prompt the user that this application
> runs as an elevated user... do you want to continue?

Even if the user is prompted, it would still be privilege escalation, if the
user his/herself did not have the same rights as the rights assigned the
program. Although, this would be much preferable to not being prompted

> But the windows alternatives do not really give Vista a chance to ask
> concent, when and how often do you ask for concent on a windows service?

Excellent point. However, the alternatives are NOT meant to do what you
describe

> I have a feeling that the next major security issue in windows is going to
> poorly written services and microsoft is again going blame vendors, block
> services and com+ apps afrom installing without explicit concent prevent
> services from communicating with nonadministrative users, etc

I agree, and I am curious (and not in a good way) as to how Microsoft will
respond. Microsoft needs some way to enforce the service abstraction - that
is, providing abstract functionality to applications that needs to be
implemented with admin powers but does not expose direct admin power to
applications.

> Vista will be difficult if not impossible for some users to use if they
> don't have an administrative password. Administrators are not going to
> want to come around to every workstation in the morning and type in his
> credentials so users can run a specific application without knowing the
> administrative password. Requiring the user to be an administrator or
> provide administrative credentials defeats the benefits of SUID. If all
> unix users always knew the root password there would have been no need for
> SUID.

You're right in the fact that the user should be assigned ONLY the
permissions they need to carry out their tasks. But, they MUST have
permission to do what is expected of them. SUID is not needed to allow this
to happen.

Although, some of the SUID functionality could be implemented to lock-down
applications so they only have the chunks of permission from the user that
they specifically need to carry out their specific tasks.

<snip>
> But I don't see how SUID could possibly be useful if the user must first
> have the required permissions and/or aquire them before running the
> application.

I think you do - and you say it yourself in your very next statement.

> The purpose of SUID applications is not to elevate the users permissions
> but rather to take them away.



> SQL Server is a good example. In order to grant the user a subset of the
> ACLs on the database file, ie modify table data but not schema or database
> elements, you must first grant another user (SQL Service User) permissions
> to the necessary resources, develop an SUID application (SQL Server
> Service) to perform those activities on the users behalf, grant the user
> permissions to use this application, and then you can take away these
> permissions from the user. This is much more secure then an access
> database where the user can either access the database or he cannot, with
> SQL Server the user does not need to have permission to write directly to
> the database file to modify the contents of a table, in fact allowing the
> user to do so would allow also allow the user to bypass SQL security and
> modify not just the table contents, but truncate the entire database.

The difference between the implementation of SQL server and the
implementation of SUID is subtle, but very, VERY important.

The part of SQL Server that runs as a service basically extends the features
of the operating system - it exposes a new object, a database, and exposes
the functionality to access databases to APPLICATIONS. Applications are then
created the are COMPOSED of this functionality, which is then provided to
the user. The APPLICATIONS that are composed of this functionality run with
the rights of the user.

This is "correct" because a SERVICE running at a higher privilege level
exposes abstract things that PROGRAMS are COMPOSED of. This is the reason
the service model exists at all - to allow for this. This is how the
operating itself is set up - all unprivileged actions, once you get thru to
the lower levels of the abstraction, are composed of privileged actions.
This DOES NOT, however, create privilege escalation scenarios if implemented
correctly.

SUID is "incorrect" because it is an APPLICATION that is running at a higher
privilege level that allows USERS and other programs to INTERACT with it.
Notice here the difference - users are not COMPOSED of applications, users
INTERACT with them. This conceptually creates the availability of privilege
escalation that is by design - no matter HOW it is implemented, privilege
escalation is possible, because that is the nature of the design.

Now, I would be foolish to say that SUID is not useful - you yourself have
used it very well with great results. And I'm not saying that the security
issues it introduces can't be mitigated - this can be done, as is done in
most *nix environments. But, the fact is, it is conceptually flawed by
breaking the security abstraction - and no matter how this is mitigated, or
implemented, this flaw will always be present, as it is a design flaw. I
support Microsoft's decision not to implement it, but I would VERY MUCH like
to see some of the ideas in SUID be introduced into the Windows Security
Architecture in such a way as not to break the design.

Wow, this is an excellent discussion, thank you for bringing it up!!!


--
- JB

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

<snip>
> But we see how well that worked out in XP because without SUID users were
> forced to use an admin account.

People were forced to use admin accounts in XP due to application and system
incompatibility due to programs not being designed to run correctly in a
standard user environment. One of the results of UAC will be to fix this
problem .

Sure, it was the intent of Windows XP that their idea of "privilege
seperation" be implemented by users logging in as standard users and then
only using admin accounts to administer the system. But, that didn't work;
so, UAC now enforces privilege seration - and it is a much more secure model
than the old way, since even when running as an administrator, the processes
that don't need admin power don't have it, preventing them from being
exploited or messing up and fluking the system.

Windows has a very rich security model that allows privileges to be
delegated to users; Just because there is an "Administrators" group that has
full privileges by default doesn't mean this is the only class of user
available - you are free to make your own groups with their own specific,
constrained permissions however you like. Windows XP and Windows Vista both
support this model.

> Even with Vista users must either have an admin account or know the
> administrator password to perform any administrative task even if the
> administrator would be willing to grant the user permissions for that
> specific task or specific application they can't do so (at least not
> without having considerable development skills necessary to create a
> secure windows service or com+ application to perform the elevated task as
> a service user).

Users can be delegated specific permissions to do whatever is required of
them. If they need to be able to change the system time, for example, they
can be granted only this adminsitrative power and nothing else - and, when
logged in under their user account, even though they are NOT an
administrator, they will be able to change the system time WITHOUT using an
administrator password, since their account has that privilege.

Same thing when accessing objects such as files and registry keys - you can
grant your users privileges however you want, without requring them to know
the administrator account's password.

> I suppose I could use another less friendly program like cmd shell to copy
> files, just not windows explorer - the most common windows application
> used
> to manage files and folders, I can change the permissions but I actually
> prefer that I can't access those files unless I login as administrator so
> that I or some other software doesn't accidently corrupt them, and
> changing permissions back after I'm done is going to be forgotten at some
> point.

When logged in as an administrator with UAC enabled, you should be able to
run-as-administrator explorer. The split-token design should allow this to
work correctly - using run as administrator when logged in as administrator
starts the program with the full admin token instead of the filtered token,
and does not do any other hocus pocus - it is a very simple operation and
should work on all .exes.

When logged in as a standard user, when you run-as-administrator a program,
you are actually logging in with the user profile of the administrator
account and running the program from that other user profile, not your
standard user account, and for some reason explorer does not and has never
supported this. This is indeed unfortunate, but as you mentioned, this is
the behavior you want - you don't want to be able to do this from your
standard user account, but you do from your administrator account.

The standard user / admin user account methodology still works with UAC. It
seems you have found something that you can't do under a standard user
account that you can only do from an admin account .

The administrators group is STILL around and is just as powerful now as it
was in Windows XP - the only difference is, it requires consent before
running an app with the admin token, and some apps don't automatically ask
for the token (but you can run ANY app with the elevated token using run as
admin under an admin account). You can't directly run a non-app, such as an
ActiveX control or shell extention as admin, because these are hosted inside
of another app that you must elevate instead. Also, I should point out, that
if an elevated app (i.e. cmd.exe) starts another app (i.e. you start an app
from cmd), than that child app automatically is elevated, with no prompt.

This "admin approval mode" from administrators is also more secure because
UAC prevents "admin" apps from talking to "normal" apps in most ways,
preventing most forms of shatter attacks, in the same way that IE protected
mode prevents internet explorer from talking to the rest of the system.

Vista standard user accounts still have the shortcommings of Windows XP
standard user accounts, as you have found out, because they essentially work
the same as they did in Windows XP (run as administrators works exactly like
run as did in XP in this case), but they do take advantage of the app-compat
features of UAC (such as virtualization) and the privilege seperation
enforced by UAC (seperating higher-privileged processes from lower ones).

--
- JB

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