Built-in admin account

[Kurt Harriger]

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

 

[Jimmy Brush]

Hello,

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]

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.

Hello,

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.

 

[Richard G. Harper]

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] (e-mail address removed)
* 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

 

[Jimmy Brush]

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.

 

[Kurt Harriger]

Hello,

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


"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.

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.

 

[Jimmy Brush]

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.

 

[Kurt Harriger]

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.

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.


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


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.

 

[Jimmy Brush]

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.

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!!!

 

[Jimmy Brush]

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).

 

[Jimmy Brush]

When logged in as an administrator with UAC enabled, you should be able to

run-as-administrator explorer.

OK, I finally got RTM installed, and was very displeased to find out that
you can't do this .

This is a big step in the wrong direction for Microsoft. I can only read
this as an artificial limitation for whatever reason, as this was working in
earlier builds. How do they expect people to manage their computers when
logged in as an administrator when Microsoft is breaking their own security
model by refusing to allow elevation for certain programs?

 

[Kurt Harriger]

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.

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.

I agree with you to an extent. If I wanted to allow users to archive and
clear the application event log I could very easily write a console
application clearmyeventlog.exe that would do so and grant this application
permission to clear the event log. Unfortunatly this would be application
specific and another developer would not be able to come around later and
create a windows form wizard application that could perform the same task,
the best they could do is invoke my application when the user presses
finish. A service would be more reusable but I'm not sure the added
complexities of developing a privilage service are worth the risks.

I'm more likely to understand and trust the behavior of a specific
application then that of a service. Many applications have alot of
validation logic within the UI that is not duplicated elsewhere, and if
these apis were directly exposed to untrusted data they may allow all sorts
of injection attacks. In a rush to get applications to be vista compatible
many vendors will likely pull out apis that were only intended to be used by
that specific application where the input has been validated and can be
trusted into a context where input cannot be trusted. I would much rather
trust a specific application where it is much easier to validate the correct
behavior than a service having an api which is mostlikely undocumented and
largely untested outside the context of few specific applications.

Thankfully vista provides the requiresAdministrator rather then requiring
the creation of priviliage services. But with so many users complaining
about the elevation prompts many vendors may take the privilaged service
approach either because they are purposely trying to avoid the prompts or
because they nievely think they are a symptom of poor application design and
seek other alternatives. As it is the administrator is mostly limited to
what the application vendor has provided, if the application vendor uses an
out-of-process app marked as requiresAdministrator there isn't much he can
do to pre-authorize it, but what might be even worse, is that if the vendor
provides a privilaged service the administrator is essentially forced to
pre-authorize the service activities or not install the application at all.
It would be nice to have some middle ground for those situations where the
administrator (not application vendor) wants to pre-authorize a trusted
application to run with elevated privilages. Putting control back into the
users hands you might say.

 

[Jimmy Brush]

I agree with you to an extent. If I wanted to allow users to archive and

clear the application event log I could very easily write a console
application clearmyeventlog.exe that would do so and grant this
application permission to clear the event log. Unfortunatly this would be
application specific and another developer would not be able to come
around later and create a windows form wizard application that could
perform the same task, the best they could do is invoke my application
when the user presses finish. A service would be more reusable but I'm
not sure the added complexities of developing a privilage service are
worth the risks.

Privileges just aren't applied to programs - they are given to users, and
then the applications inherit those privileges from the user.

If you want a user to be able to perform some function, then you give that
user the right to do it by giving them permission via editing the security
policy for the computer or changing the permissions on the object that they
need access to (I believe both would be necessary for the event log
example).

Any application the user runs can thus only do what the user has privileges
to do. It wouldn't matter what program that user runs - be it a specialized
clearmyeventlog.exe program you created or the event viewer - if the user
has the permissions to complete the operation, it will succeed; otherwise,
it will fail.

Programs are the will of the user, the user's proxy; From the viewpoint of
Windows, applications ARE the user. User privileges are enforced by the
operating system by limiting what programs can do. This is a clean
abstraction that (when programming correctly) prevents privilege escalation.

SUID "overrides" this behavior by applying privileges to a program -
essentially, the operating system is delegating its task of enforcing
privileges to THE USER HIS/HERSELF, because applications ARE the user. This
directly conflicts with the Windows security model, which creates privilege
escalation scenarios. Even if you super-tested your SUID program and are
confident it only lets the user do a certain task, there still could be
other forms of privilege escalation available to the user, because the user
has the ability to interact directly with the program running at a higher
privilege level.

The only time a service would need to be implemented is if you are exposing
new functionality or for some reason need to create a new type of custom
privilege - in this case, the service would be responsible for keeping track
of which users are allowed to the privileges, etc, and then expose the API
to access the functionality/privilege to other applications.

An application would then need to be written to access this functionality.
This is a must, because the application is what inherits the privileges from
the user. The application, running with the privileges of the user, calls
your service functions, and then your service functions use the privileges
of the user to determine whether these API calls succeed.

This effectively allows you to extend a new privilege to the user in the
model that Windows requires.

If you completely bypass the service, and the program itself is running with
the higher privileges, privilege escalation will always be possible, because
the user has direct control over a program operating with higher privileges,
and is interacting with it. When the higher privilege is abstracted down
into a service level, so long as the service is programmed correctly, the
privelege escalation threat can be contained.

It would be nice to have some middle ground for those situations where the
administrator (not application vendor) wants to pre-authorize a trusted
application to run with elevated privilages. Putting control back into
the users hands you might say.

Allowing this just really rubs things in the wrong direction. However, I am
starting to see what you are getting at, and it would be very handy for a
lot of purposes... I just can't think of a good way to get it to fit in with
the security model.

 

[Kurt Harriger]

Privileges just aren't applied to programs - they are given to users, and
then the applications inherit those privileges from the user.

If you want a user to be able to perform some function, then you give that
user the right to do it by giving them permission via editing the security
policy for the computer or changing the permissions on the object that
they need access to (I believe both would be necessary for the event log
example).

I agree that you should set permissions at the lowest level possible, the
resource itself when and if at all possible and if you don't need to use
SUID then don't. The clearmyeventlog as is, is not the best example,
however, if I revise the requirements slightly so that clearmyeventlog must
first save the eventlog prior to clearing it then I can't grant the user
permission to clear the event log as there is no way to guarentee the user
will actually save the eventlog before clearing it. The only way I can
enforce this rule is to require the user to use my application (or service)
to do so.

Windows does provide a fair amount of granularity via group policies but I
doubt that it is possible to grant explicitly grant the user every
administrative privilage, even if you grant the user access to every file,
folder, registry key, group policy, etc I think you would still run into
issues with many administrative tasks as some just check if the user is a
member of administrators group. Irronically, a perfect example is UAC. UAC
might prevent the user from using eventviewer to clear the log; even if the
user has the permission to perform the task, if he isn't an administrator
and the app is marked as requiresAdministrator the user wont be able to run
the application. Which goes back to what I had said before about Vista
being impossible for most users to use if they don't know the administrator
password. What MS should have done is create a requiresPermissions as .NET
does and prompt for concent only if the user does not have the declared
permissions.

Additionally, If you grant the user permission to clear the event log every
program that he runs will have this permission, the point of UAC was to
require the users approval before performing an administrative task so that
applications cannot abuse permissions the user DOES have. I like the idea
of being able to prompt the user before obtaining elevated permissions and I
don't see why this wouldn't be possible for SUID applications also.

It should also be noted that SUID does not require the elevated user to be
administrator it can be any user that has permissions to the necessary
resources, just as you don't need to run SQL as System you don't need to run
SUID applications as system/administrator either, a program the saves and
then clears the event log should run as a user that has only those
permissions. SUID might even be more useful to run as processes as more
restricted user then an elevated user, one without network access or one
with nework access but no file permissions.

Any application the user runs can thus only do what the user has
privileges to do. It wouldn't matter what program that user runs - be it a
specialized clearmyeventlog.exe program you created or the event viewer -
if the user has the permissions to complete the operation, it will
succeed; otherwise, it will fail.

Programs are the will of the user, the user's proxy; From the viewpoint of
Windows, applications ARE the user. User privileges are enforced by the
operating system by limiting what programs can do. This is a clean
abstraction that (when programming correctly) prevents privilege
escalation.

This is unfortunate, I think it should also be possible to grant/deny
permissions to individual applications. Why should I grant any program
except outlook access to my mailbox files, allow a program other then office
to disable macro security by editing the registry, these resources and
settings are private to the application unless of course I specifically
grant access to those resources. I don't even see any reason that the user
running the application even needs access to read a program exe, dlls,
images, and other resources, these are private application components that
should not be manipulated directly by the user, the only permission the user
should need for an application is execute. Applications should have ACL
lists of their own that specify who can execute, manage, update/patch,
uninstall, and perhaps other application specific ACLs; applications should
be treated as a system resources not just a set of files or "the user".

Applications should also have an security token of their own that could be
used to grant/deny permissions to other system resources. Some resources
such as private application components might even be owned by the
application rather then the user and the user owns the application. Windows
could then enforce that not only the user but the specific application(s)
has been granted permission to the specified resource, the current model
does not take into account that user may trust MS Office products more then
they trust a cool game they found on the internet. .NET security team is
miles head, allowing individual applications to have varing degrees of
trust, the only way to do this for unmanaged applications is by controlling
the user security token. I have a feeling that IE Protected mode does just
using UAC split-token technologies to run IE as a less privilaged user, an
"application" security token of sorts, its unfortunate that the user can't
run other applications like MSN Messanger in the same protected mode.

SUID "overrides" this behavior by applying privileges to a program -
essentially, the operating system is delegating its task of enforcing
privileges to THE USER HIS/HERSELF, because applications ARE the user.
This directly conflicts with the Windows security model, which creates
privilege escalation scenarios. Even if you super-tested your SUID program
and are confident it only lets the user do a certain task, there still
could be other forms of privilege escalation available to the user,
because the user has the ability to interact directly with the program
running at a higher privilege level.

The only time a service would need to be implemented is if you are
exposing new functionality or for some reason need to create a new type of
custom privilege - in this case, the service would be responsible for
keeping track of which users are allowed to the privileges, etc, and then
expose the API to access the functionality/privilege to other
applications.

An application would then need to be written to access this functionality.
This is a must, because the application is what inherits the privileges
from the user. The application, running with the privileges of the user,
calls your service functions, and then your service functions use the
privileges of the user to determine whether these API calls succeed.

This effectively allows you to extend a new privilege to the user in the
model that Windows requires.

If you completely bypass the service, and the program itself is running
with the higher privileges, privilege escalation will always be possible,
because the user has direct control over a program operating with higher
privileges, and is interacting with it. When the higher privilege is
abstracted down into a service level, so long as the service is programmed
correctly, the privelege escalation threat can be contained.

Is there something else I'm missing here? I don't understand how priviliage
elevation is always possible with a SUID application but the same is not
true of a service? I don't really see how a service is somehow inherently
more secure or less vunerable just because its a service. Granted the
service could never launch another application on the users desktop but
chances are if either were capable of spawing other processes you have a big
problem regardless of which desktop the application runs on. I'm not saying
SUID applications can't have bugs that could be exploited, but I don't think
it really matters much if the user interacts with an application or an
application interacts with it the service either one could be exploited.
But I do think its easier to test the behavior of an application then that
of a service. Additionaly, a service is usually running in the background
at all times, giving crackers plenty of time and opportunity to try their
best, whereas the application may only provide the elevation for a very
short period of time, and it is much easier to automate an attack on a
service then it is to automate an application by pumping windows messages
into the application message queue. SUID has many of the same risks as
services and if you don't need to use it don't, but I think either is better
then giving the user the administrator password to perform a couple of
administrative tasks (that you can't otherwise safely grant via group
policies).

 

[Kurt Harriger]

Privileges just aren't applied to programs - they are given to users, and
then the applications inherit those privileges from the user.

If you want a user to be able to perform some function, then you give that
user the right to do it by giving them permission via editing the security
policy for the computer or changing the permissions on the object that
they need access to (I believe both would be necessary for the event log
example).

I agree that you should set permissions at the lowest level possible, the
resource itself when and if at all possible and if you don't need to use
SUID then don't. The clearmyeventlog as is, is not the best example,
however, if I revise the requirements slightly so that clearmyeventlog must
first save the eventlog prior to clearing it then I can't grant the user
permission to clear the event log as there is no way to guarentee the user
will actually save the eventlog before clearing it. The only way I can
enforce this rule is to require the user to use my application (or service)
to do so.

Windows does provide a fair amount of granularity via group policies but I
doubt that it is possible to grant explicitly grant the user every
administrative privilage, even if you grant the user access to every file,
folder, registry key, group policy, etc I think you would still run into
issues with many administrative tasks as some just check if the user is a
member of administrators group. Irronically, a perfect example is UAC. UAC
might prevent the user from using eventviewer to clear the log; even if the
user has the permission to perform the task, if he isn't an administrator
and the app is marked as requiresAdministrator the user wont be able to run
the application. Which goes back to what I had said before about Vista
being impossible for most users to use if they don't know the administrator
password. What MS should have done is create a requiresPermissions as .NET
does and prompt for concent only if the user does not have the declared
permissions.

Additionally, If you grant the user permission to clear the event log every
program that he runs will have this permission, the point of UAC was to
require the users approval before performing an administrative task so that
applications cannot abuse permissions the user DOES have. I like the idea
of being able to prompt the user before obtaining elevated permissions and I
don't see why this wouldn't be possible for SUID applications also.

It should also be noted that SUID does not require the elevated user to be
administrator it can be any user that has permissions to the necessary
resources, just as you don't need to run SQL as System you don't need to run
SUID applications as system/administrator either, a program the saves and
then clears the event log should run as a user that has only those
permissions. SUID might even be more useful to run as processes as more
restricted user then an elevated user, one without network access or one
with nework access but no file permissions.

Any application the user runs can thus only do what the user has
privileges to do. It wouldn't matter what program that user runs - be it a
specialized clearmyeventlog.exe program you created or the event viewer -
if the user has the permissions to complete the operation, it will
succeed; otherwise, it will fail.

Programs are the will of the user, the user's proxy; From the viewpoint of
Windows, applications ARE the user. User privileges are enforced by the
operating system by limiting what programs can do. This is a clean
abstraction that (when programming correctly) prevents privilege
escalation.

This is unfortunate, I think it should also be possible to grant/deny
permissions to individual applications. Why should I grant any program
except outlook access to my mailbox files, allow a program other then office
to disable macro security by editing the registry, these resources and
settings are private to the application unless of course I specifically
grant access to those resources. I don't even see any reason that the user
running the application even needs access to read a program exe, dlls,
images, and other resources, these are private application components that
should not be manipulated directly by the user, the only permission the user
should need for an application is execute. Applications should have ACL
lists of their own that specify who can execute, manage, update/patch,
uninstall, and perhaps other application specific ACLs; applications should
be treated as a system resources not just a set of files or "the user".

Applications should also have an security token of their own that could be
used to grant/deny permissions to other system resources. Some resources
such as private application components might even be owned by the
application rather then the user and the user owns the application. Windows
could then enforce that not only the user but the specific application(s)
has been granted permission to the specified resource, the current model
does not take into account that user may trust MS Office products more then
they trust a cool game they found on the internet. .NET security team is
miles head, allowing individual applications to have varing degrees of
trust, the only way to do this for unmanaged applications is by controlling
the user security token. I have a feeling that IE Protected mode does just
using UAC split-token technologies to run IE as a less privilaged user, an
"application" security token of sorts, its unfortunate that the user can't
run other applications like MSN Messanger in the same protected mode.

SUID "overrides" this behavior by applying privileges to a program -
essentially, the operating system is delegating its task of enforcing
privileges to THE USER HIS/HERSELF, because applications ARE the user.
This directly conflicts with the Windows security model, which creates
privilege escalation scenarios. Even if you super-tested your SUID program
and are confident it only lets the user do a certain task, there still
could be other forms of privilege escalation available to the user,
because the user has the ability to interact directly with the program
running at a higher privilege level.

The only time a service would need to be implemented is if you are
exposing new functionality or for some reason need to create a new type of
custom privilege - in this case, the service would be responsible for
keeping track of which users are allowed to the privileges, etc, and then
expose the API to access the functionality/privilege to other
applications.

An application would then need to be written to access this functionality.
This is a must, because the application is what inherits the privileges
from the user. The application, running with the privileges of the user,
calls your service functions, and then your service functions use the
privileges of the user to determine whether these API calls succeed.

This effectively allows you to extend a new privilege to the user in the
model that Windows requires.

If you completely bypass the service, and the program itself is running
with the higher privileges, privilege escalation will always be possible,
because the user has direct control over a program operating with higher
privileges, and is interacting with it. When the higher privilege is
abstracted down into a service level, so long as the service is programmed
correctly, the privelege escalation threat can be contained.

Is there something else I'm missing here? I don't understand how priviliage
elevation is always possible with a SUID application but the same is not
true of a service? I don't really see how a service is somehow inherently
more secure or less vunerable just because its a service. Granted the
service could never launch another application on the users desktop but
chances are if either were capable of spawing other processes you have a big
problem regardless of which desktop the application runs on. I'm not saying
SUID applications can't have bugs that could be exploited, but I don't think
it really matters much if the user interacts with an application or an
application interacts with it the service either one could be exploited.
But I do think its easier to test the behavior of an application then that
of a service. Additionaly, a service is usually running in the background
at all times, giving crackers plenty of time and opportunity to try their
best, whereas the application may only provide the elevation for a very
short period of time, and it is much easier to automate an attack on a
service then it is to automate an application by pumping windows messages
into the application message queue. SUID has many of the same risks as
services and if you don't need to use it don't, but I think either is better
then giving the user the administrator password to perform a couple of
administrative tasks (that you can't otherwise safely grant via group
policies).

 

[Guest]

I agree that you should set permissions at the lowest level possible, the

resource itself when and if at all possible and if you don't need to use
SUID then don't. The clearmyeventlog as is, is not the best example,
however, if I revise the requirements slightly so that clearmyeventlog must
first save the eventlog prior to clearing it then I can't grant the user
permission to clear the event log as there is no way to guarentee the user
will actually save the eventlog before clearing it. The only way I can
enforce this rule is to require the user to use my application (or service)
to do so.

Here you are essentially wanting to constrain privilege use. The user has
the privilege to do a certain thing, but only under X circumstances. As you
point out very eloquently, this is almost impossible to do correctly in
Windows. However, I just don't think SUID is a valid solution, because
allowing a user to EXCEED thier privileges just doesn't fit into the Windows
architecture.

However, CONSTRAINING the user, with X privilege, to only using Y
application to USE that privilege, fits the model perfectly, while
accomplishing the same goal.

Windows does provide a fair amount of granularity via group policies but I
doubt that it is possible to grant explicitly grant the user every
administrative privilage, even if you grant the user access to every file,
folder, registry key, group policy, etc I think you would still run into
issues with many administrative tasks as some just check if the user is a
member of administrators group. Irronically, a perfect example is UAC. UAC
might prevent the user from using eventviewer to clear the log; even if the
user has the permission to perform the task, if he isn't an administrator
and the app is marked as requiresAdministrator the user wont be able to run
the application. Which goes back to what I had said before about Vista
being impossible for most users to use if they don't know the administrator
password.

You may be correct, but it will be due to misconfigured applications, as UAC
is designed to allow users with "extra" privileges to be able to use their
privileges, as long as applications utilize UAC correctly.

UAC has 3 states - requiresAdministrator, as much power as possible, and no
admin permission at all.

It is up to the application to define the correct state it requires. You are
absolutely correct that an application that is marked as requiring admin will
not allow a user that may have the correct privileges from being able to run
it. This is the application's fault for marking itself as requiring
administrator, however .

Applications or chunks of applications that use privileges that may or may
not be available to the user should be marked as "as much power as possible".
In this case, if the user is an administrator, the system WILL prompt for
consent; however, if the user is not an admin, the system will NOT prompt for
consent, but WILL allow the extra privileges to be used. Lastly, if a program
is marked as never needing admin, the program will never be granted extra
privileges, even if they are available to the user.

This explains the behavior of the MMC you have noted in other posts. MMC is
marked as "highest available". If the user is an admin, it prompts the user
for consent to run the program, since it will be running with the unfiltered
"admin" token that allows everything.

I should point out here that UAC not only filters an admin token, but also
normal user tokens. I don't think this is widely known. When a program is
marked as "highest available", and the user is NOT an administrator, the
program is ran with the user's unfiltered token (however much privileges that
user has been assigned). However, if the program is marked as "never needs
admin", then it will receive a filtered user token, that removes any
additional privileges the user may hold (such as the debug privilege).

So, when running the MMC (marked highest available), it will receive the
user's unfiltered token, which allows MMC to use any special privileges the
user has been assigned (and without prompting the user for consent).

What MS should have done is create a requiresPermissions as .NET
does and prompt for concent only if the user does not have the declared
permissions.

I agree, another possible UAC solution would have been if the applications
could have defined exactly what privileges they need, and then let UAC
determine based on this information whether to prompt or not.

In fact, without thinking about in in depth, I think this would have been a
better solution .

But, I should also point out, that this sort of model is still allowed with
the 3-state UAC, but it is still a rather blunt instrument.

Applications that essentially use all the powers of an administrator should
be marked requiresAdministrator. However, applications or chunks of
applications that only use certain privileges should be marked
highestAvailable or do other types of checks to ensure that it only prompts
for admin elevation if the user does not have the privileges.

This is how the system clock works when the user is logged in as a non-admin
- it checks to see if the user has the change time privilege. If they do,
then it just works ; if they don't, it requires an admin to log in to change
the time.

Additionally, If you grant the user permission to clear the event log every
program that he runs will have this permission, the point of UAC was to
require the users approval before performing an administrative task so that
applications cannot abuse permissions the user DOES have. I like the idea
of being able to prompt the user before obtaining elevated permissions and I
don't see why this wouldn't be possible for SUID applications also.

The problem is not that SUID is prompting the user for permission; it's that
they are being prompted for permission to do something that they do not have
rights to do.

UAC only prompts for permission when the user is taking action that they
HAVE permission to do, or asks for a user to log in who HAS the permissions.

It should also be noted that SUID does not require the elevated user to be
administrator it can be any user that has permissions to the necessary
resources, just as you don't need to run SQL as System you don't need to run
SUID applications as system/administrator either, a program the saves and
then clears the event log should run as a user that has only those
permissions. SUID might even be more useful to run as processes as more
restricted user then an elevated user, one without network access or one
with nework access but no file permissions.

I completely agree with SUID-type behavior for LIMITING what privileges the
user has. The part I disagree with is when using SUID to INCREASE privileges,
even if the user has given consent, and even if an admin has pre-approved it.

Now, the scenario I would support would be if the user has been given the
permission to do X, but the admin through some sort of policy has limited the
user from using this privilege except thru Y application. This would fit in
with the Windows security model, while at the same time reaching the same
outcome you are looking for .

We are essentially saying the same thing in different ways, I know ... but I
think it is an important distinction to make.

This is unfortunate, I think it should also be possible to grant/deny
permissions to individual applications. Why should I grant any program
except outlook access to my mailbox files, allow a program other then office
to disable macro security by editing the registry, these resources and
settings are private to the application unless of course I specifically
grant access to those resources. I don't even see any reason that the user
running the application even needs access to read a program exe, dlls,
images, and other resources, these are private application components that
should not be manipulated directly by the user, the only permission the user
should need for an application is execute. Applications should have ACL
lists of their own that specify who can execute, manage, update/patch,
uninstall, and perhaps other application specific ACLs; applications should
be treated as a system resources not just a set of files or "the user".

I agree with you that one should be able to control what access applications
can have to securable objects, as well as what privileges get filtered down
to the application.

However, saying things like "the user shouldn't even have access to .exe's"
is kind of crazy - the "user" is an abstract concept ... in actuality, there
are ONLY applications with security tokens. That is why I say applications
get their privileges from the user, and that the applications are the user's
agent - because, well, that's exactly what's going on .

How do you seperate the user from the application, at a technical level? You
can't. How do you DISALLOW the USER from doing something, while ALLOWING an
application to do that something? You can't.

Applications should also have an security token of their own that could be
used to grant/deny permissions to other system resources. Some resources
such as private application components might even be owned by the
application rather then the user and the user owns the application. Windows
could then enforce that not only the user but the specific application(s)
has been granted permission to the specified resource, the current model
does not take into account that user may trust MS Office products more then
they trust a cool game they found on the internet.

Well, Windows is STARTING to take this into account with UAC, but I agree
with you that it is just a start, and there is a LOT more that needs to be
done, as you have suggsested here.

.NET security team is
miles head, allowing individual applications to have varing degrees of
trust, the only way to do this for unmanaged applications is by controlling
the user security token.
Agreed.

I have a feeling that IE Protected mode does just
using UAC split-token technologies to run IE as a less privilaged user, an
"application" security token of sorts, its unfortunate that the user can't
run other applications like MSN Messanger in the same protected mode.

UAC protected mode is accomplished using mandatory integrity control and
virtualization, and I won't be surprised if third party tools pop up allowing
you to run other apps in this kind of mode.

Is there something else I'm missing here? I don't understand how priviliage
elevation is always possible with a SUID application but the same is not
true of a service? I don't really see how a service is somehow inherently
more secure or less vunerable just because its a service. [...]

I will respond to this later, after I come up with a better way to explain
it .

but I think either is better
then giving the user the administrator password to perform a couple of
administrative tasks (that you can't otherwise safely grant via group
policies).

You and I want the same thing, we are pretty much just debating convention.

Users have privileges. Applications are the means by which users use their
privileges. This is how it works so far. Through UAC, users can choose
whether an application USES or DOESN'T use their privileges...

... but users have no way of discriminating HOW MUCH of their privileges can
be used.

This is what you and I both ultimately want.

SUID should never be able to allow a user to EXCEED their privileges;
however, it should be allowed to CONSTRAIN them. If your goal is to allow a
user to only perform once specific task using a certain program, you can
achieve this using either the exceed or constrain mechanism; however, the
exceed mechanism is the wrong solution .

I am all for an implementation using the CONSTRAIN method.

- JB

 

[Kurt Harriger]

Here you are essentially wanting to constrain privilege use. The user has
the privilege to do a certain thing, but only under X circumstances. As
you
point out very eloquently, this is almost impossible to do correctly in
Windows. However, I just don't think SUID is a valid solution, because
allowing a user to EXCEED thier privileges just doesn't fit into the
Windows
architecture.

If I (the admin) big the user the ability to execute to the application I
GRANT them the privilage, but I only grant them the privilage to perform
task using the specified application so that I can ensure the evetlog is
saved before it is cleared. If windows provided a clear event log after
save I would use that instead, but it doesn't.

Executing a specified application should be a privilage, a user should not
be able to execute an application even if he has permissions to read it, in
*nix an application must be marked as executable before the OS will run it.
This in itself could prevent numerous inadvertant attacks from software
downloaded from internet and/or recieved via email (such coolpic.jpg
..exe). The one major complaint I have with the .NET security model was
granting FullTrust to the My Computer Zone by default allowing the user to
"elevate" the permissions by saving an internet application to
the desktop or a temp folder, a more secure policy would only grant
FullTrust to assemblies that have been "installed" by the user to the
program files directory, GAC or other secure locations, unfortunatly the xml
serializer generates temporary assemblies in the temp folder.

However, CONSTRAINING the user, with X privilege, to only using Y
application to USE that privilege, fits the model perfectly, while
accomplishing the same goal.


You may be correct, but it will be due to misconfigured applications, as
UAC
is designed to allow users with "extra" privileges to be able to use their
privileges, as long as applications utilize UAC correctly.

UAC has 3 states - requiresAdministrator, as much power as possible, and
no
admin permission at all.

It is up to the application to define the correct state it requires. You
are
absolutely correct that an application that is marked as requiring admin
will
not allow a user that may have the correct privileges from being able to
run
it. This is the application's fault for marking itself as requiring
administrator, however .

Applications or chunks of applications that use privileges that may or may
not be available to the user should be marked as "as much power as
possible".
In this case, if the user is an administrator, the system WILL prompt for
consent; however, if the user is not an admin, the system will NOT prompt
for
consent, but WILL allow the extra privileges to be used. Lastly, if a
program
is marked as never needing admin, the program will never be granted extra
privileges, even if they are available to the user.

This explains the behavior of the MMC you have noted in other posts. MMC
is
marked as "highest available". If the user is an admin, it prompts the
user
for consent to run the program, since it will be running with the
unfiltered
"admin" token that allows everything.

I should point out here that UAC not only filters an admin token, but also
normal user tokens. I don't think this is widely known. When a program is
marked as "highest available", and the user is NOT an administrator, the
program is ran with the user's unfiltered token (however much privileges
that
user has been assigned). However, if the program is marked as "never needs
admin", then it will receive a filtered user token, that removes any
additional privileges the user may hold (such as the debug privilege).

So, when running the MMC (marked highest available), it will receive the
user's unfiltered token, which allows MMC to use any special privileges
the
user has been assigned (and without prompting the user for consent).


I agree, another possible UAC solution would have been if the applications
could have defined exactly what privileges they need, and then let UAC
determine based on this information whether to prompt or not.

In fact, without thinking about in in depth, I think this would have been
a
better solution .

But, I should also point out, that this sort of model is still allowed
with
the 3-state UAC, but it is still a rather blunt instrument.

Applications that essentially use all the powers of an administrator
should
be marked requiresAdministrator. However, applications or chunks of
applications that only use certain privileges should be marked
highestAvailable or do other types of checks to ensure that it only
prompts
for admin elevation if the user does not have the privileges.

This is how the system clock works when the user is logged in as a
non-admin
- it checks to see if the user has the change time privilege. If they do,
then it just works ; if they don't, it requires an admin to log in to
change
the time.


The problem is not that SUID is prompting the user for permission; it's
that
they are being prompted for permission to do something that they do not
have
rights to do.

Sure they do, the right to "execute" the specified application, which must
be granted by the administrator.

UAC only prompts for permission when the user is taking action that they
HAVE permission to do, or asks for a user to log in who HAS the
permissions.


I completely agree with SUID-type behavior for LIMITING what privileges
the
user has. The part I disagree with is when using SUID to INCREASE
privileges,
even if the user has given consent, and even if an admin has pre-approved
it.

Now, the scenario I would support would be if the user has been given the
permission to do X, but the admin through some sort of policy has limited
the
user from using this privilege except thru Y application. This would fit
in
with the Windows security model, while at the same time reaching the same
outcome you are looking for .

Yes, exactly. SUID provides a method for the administrator to GRANT the user
a "custom privilage." The problem with windows to date is that the user
cannot be granted a privilage such as "member of administrators group"
without also granting the user every privilage that comes with it in any way
he feels fit to use it. If it were possible to constrain other applications
from using those permission then it would be effectively nullifed except for
the desired application.

We are essentially saying the same thing in different ways, I know ... but
I
think it is an important distinction to make.


I agree with you that one should be able to control what access
applications
can have to securable objects, as well as what privileges get filtered
down
to the application.

However, saying things like "the user shouldn't even have access to
.exe's"
is kind of crazy - the "user" is an abstract concept ... in actuality,
there
are ONLY applications with security tokens. That is why I say applications
get their privileges from the user, and that the applications are the
user's
agent - because, well, that's exactly what's going on .

LOL, took me a second, but good point.
Rather what I meant was that only the OS needs permission to read the file
into memory for execution (and backup software for recovery purposes); the
user should not be able to run a disassembler or even copy the program to
another location. Read and Execute are completely seperate permissions
IMHO.

How do you seperate the user from the application, at a technical level?
You
can't. How do you DISALLOW the USER from doing something, while ALLOWING
an
application to do that something? You can't.

The USER, as you just pointed out to me, doesn't do anything. The user is
not the one loading the program into memory, not even windows explorer
actually does that; windows explorer basically just instructs the windows
kernel to load and run the application. The kernel is the gatekeeper and
has access to all resources at all times no matter what user is logged in.
All applications ultimately have to go through the kernel, it is the kernel
that executed windows explorer and linked the users security token to the
application in the first place. So the kernel when requested to execute an
application can still access the necessary resources even if no other
application can, windows explorer included. The windows kernel only needs
to check if the user has execute permission if so can safely assume that
"reading" the program into memory is implied. Unix has long had this
capability so from a technical perspecive I don't think it is very hard to
seperate execute and read permissions.

As far as other resources are concerned it gets a bit more complicated, how
do you determine if the program has the ability to load other "application
owned resources." I have a technical solution to that as well. When the
kernel loads an application it links the users security token to the
application so that when it receives a request from the application to
perform such and such it can check that the associated user security token
has the necessary privilages. The kernel could instead link the application
to an "application security token" and link that to the user security token.
The application security token would basically fine tune the users security
token. Most often the application security token would be used to further
restrict the user security token basically granting the application the
intersection of the applications permissions and the users permissions,
application owned resources however would be the exception rather then the
rule in this case the application grant the additional permisisons to those
resources. The .net framework has a final attribute that basically ignores
what is specified at a lower level policy effectively turning off the
intersect behavior, the same sort of thing could be used in the application
security token to explicitly grant the application the necessary privilage
to the application resources overriding whatever is specified by the user
security token, this would of course need to be used only with extreme
caution, but on the plus side audit trails could easily include not only
what user performed the task but what application the user used to do so.
Normal behavior would be to check that both the applicaiton security token
and the user security token have the desired privilages to the specified
resource, as such there would need to a default applicaiton policy that
would grant applications access to all the necessary resources, just as .net
grants FullTrust to all applications in the My Computer Zone a simalar
security policy would need to grant a default policy (non-administrative) to
programs in the My Computer Zone (but this time only to those installed in
secure locations) and perhaps a internet zone like security policy to files
on the users desktop, etc.

Such a security model would practically eliminate the need for UAC as the
default security policy would be the same sandboxed environment, but the
differences may be small as two tokens are still needed, but in this case
instead of using a standard user token and linking that to the
administrative token I'm thinking that we should have "application security
tokens" which are linked to the users security token standard or
administrative. This would do away with the need for SUID too, rather then
changing running the application as another user you would grant the
privilage as "final" to the application which would also allow windows to
write the user running the app rather then suid user name to the audit logs.

Applications should also have an security token of their own that could
be
used to grant/deny permissions to other system resources. Some
resources
such as private application components might even be owned by the
application rather then the user and the user owns the application.
Windows
could then enforce that not only the user but the specific application(s)
has been granted permission to the specified resource, the current model
does not take into account that user may trust MS Office products more
then
they trust a cool game they found on the internet.

Well, Windows is STARTING to take this into account with UAC, but I agree
with you that it is just a start, and there is a LOT more that needs to be
done, as you have suggsested here.

.NET security team is
miles head, allowing individual applications to have varing degrees of
trust, the only way to do this for unmanaged applications is by
controlling
the user security token.
Agreed.

I have a feeling that IE Protected mode does just
using UAC split-token technologies to run IE as a less privilaged user,
an
"application" security token of sorts, its unfortunate that the user
can't
run other applications like MSN Messanger in the same protected mode.

UAC protected mode is accomplished using mandatory integrity control and
virtualization, and I won't be surprised if third party tools pop up
allowing
you to run other apps in this kind of mode.

Is there something else I'm missing here? I don't understand how
priviliage
elevation is always possible with a SUID application but the same is not
true of a service? I don't really see how a service is somehow
inherently
more secure or less vunerable just because its a service. [...]

I will respond to this later, after I come up with a better way to explain
it .

but I think either is better
then giving the user the administrator password to perform a couple of
administrative tasks (that you can't otherwise safely grant via group
policies).

You and I want the same thing, we are pretty much just debating
convention.

Perhaps, I think granting the user execute permission to an privilaged
application is in effect granting the user a "custom permission." It might
be possible to use a form of application security to nullify administrative
privilages the user does have but I don't think this would work well with
multiple user accounts, because it is the intersection of the user and
application permissions is important and if all users are admins the
usefulness of the user token is nullified. Although perhaps something like
the .net PrinipalPermisionDemand could be used to define application
security per user, maybe. But I don't think windows will ever be usable
without an administrator account and/or password; so perhaps the best thing
I can hope for is that a new model supersedes the existing one where
administrative accounts is assumed but otherwise meaningless.

 

[Guest]

If I (the admin) big the user the ability to execute to the application I

GRANT them the privilage, but I only grant them the privilage to perform
task using the specified application so that I can ensure the evetlog is
saved before it is cleared.

I am agreeing with you that this should be possible. I also agree that SUID
makes this possible. However, what I disagree with is the design of SUID, of
how this is implemented in the form of SUID.

SUID is a "hack" that allows this concept. Windows needs to be
re-architected to support this, and we have discussed several ways Windows
could be rearchitected. However, simply throwing on SUID as implemented in
*nix and saying "here it is folks run with it" is not the solution, because
it does not fit in with the architecture of the OS. You may be able to MAKE
IT WORK, but that doesn't mean it's a good solution . That is my position,
but I think I have gotten a little carried away trying to state it.

There is a person sitting at a screen running programs. Now, we both agree
that to the computer, there is no such thing as a user - there are only apps
with privileges. But regardless, SOMEONE is sitting out there, at an
interactive desktop, running programs.

This is precisely why programs SHOULD NOT have privileges in and of
themselves - because the person at the other end of the screen is the one
using the program, and is the one who receives the benefit of the privileges.

It is kind of rediculous, in fact, to think of a user application as having
privileges when it is being ran by, on the behalf of, or interacting with the
person on the other end of the screen - because regardless of the design or
implementation of the software, that person is the one in control of the
user-mode program, and thus the one who is using/receiving the privileges.

Windows defines this person as the abstract concept "user".

Now, this is the whole point I was making about privilege escalation and
breaking the Windows model. Because if you are running an application on one
user's desktop in the context of another user (SUID), this is privilege
esclatation BY DEFINITION. The person at the other end of the screen is now
BOTH USERS, the user that the person is logged in as AND the user account
that the program is running under, and the person using the computer does IN
FACT have all the privileges of both accounts - they just can't use them all
at once.

For applications 1-7, the user is ACCT1. For 8-9, the user is ACCT2. This
effectively accomplishes what YOU WANT - you want the person to have
different privileges while using different applications - but it is incorrect
because the person when logged in to a computer is a user - ONE user.
Pretending that he/she is two users doesn't make sense.

Also, as implemented in *nix, SUID applies privileges to the program
directly, without taking into consideration the user who is running the
program (except by who has permission to execute the .exe, which isn't ENOUGH
control, IMHO). This is incorrect, and a better solution would be as you have
previously discussed, an intersection between what privileges are assigned to
the user and how the user is allowed to use those privileges when using the
program. But I should add the program privs should always flow FROM the user
privs, as this is actually what happens, and any model that does not follow
this doesn't fit in with reality.

You can say that the user doesn't have priv B but can use app A which uses
priv B, but what you really MEAN is that the user DOES have priv B when using
app A. This is what I mean when I say we both want the same thing to happen
but are looking at it in different ways.

What you are really wanting from Windows is to have more control over the
user's privileges. SUID allows this, but muddies everything up in the
process, because it breaks the design of the system.

As an aside, this privileges flowing from the user is also the same thing I
was getting at with services vs. applications - If the user interacts with a
service directly through a UI or whatnot, the user is in essense granted all
the privileges of SYSTEM when working with that UI. This is incorrect design,
and why Windows makes it as difficult as possible to do. Services are
privileged so that they may provide services consumable by the user thru
applications, because services provide services and applications are the
means by which the user uses their privileges to consume services.

Trying to re-implement this built-in seperation of privilege (program vs.
operating system/service) is possible inside of an application (an
application that limits privilege to the user but runs internally at high
privilege, as in the case of one certain class of SUID apps), but why go
through all the trouble of breaking the windows architecutre in this way,
running the risk of introducing nasty security bugs/vulns, and
re-implementing something Windows has already done for you?

Executing a specified application should be a privilage

It IS a privilege. Having read access to a file does not give the user
execute access, this is a sperate privilege in Windows too. Windows actually
has a much richer privilege/security architecture than does *nix.

Sure they do, the right to "execute" the specified application, which must
be granted by the administrator.

You're right, I see what you are getting at now, and have addressed it above.

My point here was that the person using the computer is in the eyes of
Windows one user defined by their user account, and that technically its an
elevation of privilege when another app is run with higher privileges than
what the user account has access to, even though it works out the way you
want it to.

Yes, exactly. SUID provides a method for the administrator to GRANT the user
a "custom privilage." The problem with windows to date is that the user
cannot be granted a privilage such as "member of administrators group"
without also granting the user every privilage that comes with it in any way
he feels fit to use it. If it were possible to constrain other applications
from using those permission then it would be effectively nullifed except for
the desired application.

You're right, and I agree with you. But Windows deserves something better
than SUID .

LOL, took me a second, but good point.
Rather what I meant was that only the OS needs permission to read the file
into memory for execution (and backup software for recovery purposes); the
user should not be able to run a disassembler or even copy the program to
another location. Read and Execute are completely seperate permissions
IMHO.

Read and exec are seperate. I understand what you mean here, though - just
because a user can use a program to read/use certain files, doesn't mean the
user should be able to read/use those files from another program.

The USER, as you just pointed out to me, doesn't do anything. The user is
not the one loading the program into memory, not even windows explorer
actually does that; windows explorer basically just instructs the windows
kernel to load and run the application.

But the user is initiating the action - that is what I am getting at here;
the person at the other end of the screen in ACTUALITY is the one who has the
privileges that are assigned to the programs they run; to pretend as if this
were not so by assigning programs to run in a hodge-podge of different user
accounts is a poor solution.

As far as other resources are concerned it gets a bit more complicated, how
do you determine if the program has the ability to load other "application
owned resources." I have a technical solution to that as well. When the
kernel loads an application it links the users security token to the
application so that when it receives a request from the application to
perform such and such it can check that the associated user security token
has the necessary privilages. The kernel could instead link the application
to an "application security token" and link that to the user security token.
The application security token would basically fine tune the users security
token. Most often the application security token would be used to further
restrict the user security token basically granting the application the
intersection of the applications permissions and the users permissions,
application owned resources however would be the exception rather then the
rule in this case the application grant the additional permisisons to those
resources. The .net framework has a final attribute that basically ignores
what is specified at a lower level policy effectively turning off the
intersect behavior,

I agree, this functionality should be available. I have even suggested this
same thing in an earlier thread in this forum .

the same sort of thing could be used in the application
security token to explicitly grant the application the necessary privilage
to the application resources overriding whatever is specified by the user
security token,

This should never be necessary, as it doesn't make sense. How can an
application in the control of a user be able to do something that the user
can't do?

Such a security model would practically eliminate the need for UAC

Well, it would certaintly change the behavior of UAC. UAC allows the user to
choose how much privileges an application has. A user (or an admin on the
user's behalf) would still need to look at what privs an application is
requesting and approve/deny them; also, a user may still want the usage of
certain privs to prompt for consent, and there would be cases where an app
with lower-privs wants to start an app with higher-privs, this would require
consent.

- JB

 

[Kurt Harriger]

I am agreeing with you that this should be possible. I also agree that
SUID
makes this possible. However, what I disagree with is the design of SUID,
of
how this is implemented in the form of SUID.

SUID is a "hack" that allows this concept. Windows needs to be
re-architected to support this, and we have discussed several ways Windows
could be rearchitected. However, simply throwing on SUID as implemented in
*nix and saying "here it is folks run with it" is not the solution,
because
it does not fit in with the architecture of the OS. You may be able to
MAKE
IT WORK, but that doesn't mean it's a good solution . That is my
position,
but I think I have gotten a little carried away trying to state it.

There is a person sitting at a screen running programs. Now, we both agree
that to the computer, there is no such thing as a user - there are only
apps
with privileges. But regardless, SOMEONE is sitting out there, at an
interactive desktop, running programs.

This is precisely why programs SHOULD NOT have privileges in and of
themselves - because the person at the other end of the screen is the one
using the program, and is the one who receives the benefit of the
privileges.

It is kind of rediculous, in fact, to think of a user application as
having
privileges when it is being ran by, on the behalf of, or interacting with
the
person on the other end of the screen - because regardless of the design
or
implementation of the software, that person is the one in control of the
user-mode program, and thus the one who is using/receiving the privileges.

Windows defines this person as the abstract concept "user".

Now, this is the whole point I was making about privilege escalation and
breaking the Windows model. Because if you are running an application on
one
user's desktop in the context of another user (SUID), this is privilege
esclatation BY DEFINITION. The person at the other end of the screen is
now
BOTH USERS, the user that the person is logged in as AND the user account
that the program is running under, and the person using the computer does
IN
FACT have all the privileges of both accounts - they just can't use them
all
at once.

For applications 1-7, the user is ACCT1. For 8-9, the user is ACCT2. This
effectively accomplishes what YOU WANT - you want the person to have
different privileges while using different applications - but it is
incorrect
because the person when logged in to a computer is a user - ONE user.
Pretending that he/she is two users doesn't make sense.

Also, as implemented in *nix, SUID applies privileges to the program
directly, without taking into consideration the user who is running the
program (except by who has permission to execute the .exe, which isn't
ENOUGH
control, IMHO). This is incorrect, and a better solution would be as you
have
previously discussed, an intersection between what privileges are assigned
to
the user and how the user is allowed to use those privileges when using
the
program. But I should add the program privs should always flow FROM the
user
privs, as this is actually what happens, and any model that does not
follow
this doesn't fit in with reality.

You can say that the user doesn't have priv B but can use app A which uses
priv B, but what you really MEAN is that the user DOES have priv B when
using
app A. This is what I mean when I say we both want the same thing to
happen
but are looking at it in different ways.

Agreed. The physical user does not change via SUID. SUID is perhaps a hack
but it is one that has been used effectively for decades. The problem is I
have yet to see MS propose anything better... and the current windows
security model is BROKEN.

Windows is nearly impossible to use without an administrative user or
password, if you don't have a desired privilage... grant it to yourself,
don't have permission to access a file... take ownership of it. If a
corporation wants to ensure laptop users do not share "my documents" to the
world over an unsecure wireless network?... group policies are a start
perhaps but if you have the administrator password you can do whatever you
want. Vista does not change the "administrative password" requirement and
UAC's requiresAdministrator may even make an administrative password even
more necessary.

What you are really wanting from Windows is to have more control over the
user's privileges. SUID allows this, but muddies everything up in the
process, because it breaks the design of the system.

As an aside, this privileges flowing from the user is also the same thing
I
was getting at with services vs. applications - If the user interacts with
a
service directly through a UI or whatnot, the user is in essense granted
all
the privileges of SYSTEM when working with that UI. This is incorrect
design,
and why Windows makes it as difficult as possible to do. Services are
privileged so that they may provide services consumable by the user thru
applications, because services provide services and applications are the
means by which the user uses their privileges to consume services.

Trying to re-implement this built-in seperation of privilege (program vs.
operating system/service) is possible inside of an application (an
application that limits privilege to the user but runs internally at high
privilege, as in the case of one certain class of SUID apps), but why go
through all the trouble of breaking the windows architecutre in this way,
running the risk of introducing nasty security bugs/vulns, and
re-implementing something Windows has already done for you?



It IS a privilege. Having read access to a file does not give the user
execute access, this is a sperate privilege in Windows too. Windows
actually
has a much richer privilege/security architecture than does *nix.



You're right, I see what you are getting at now, and have addressed it
above.

My point here was that the person using the computer is in the eyes of
Windows one user defined by their user account, and that technically its
an
elevation of privilege when another app is run with higher privileges than
what the user account has access to, even though it works out the way you
want it to.


You're right, and I agree with you. But Windows deserves something better
than SUID .

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

Read and exec are seperate. I understand what you mean here, though - just
because a user can use a program to read/use certain files, doesn't mean
the
user should be able to read/use those files from another program.

They are seperate but (no longer) independent permissions. If you grant
"execute file" permissions you must grant "read data" permisison or execute
fails. This appears to be a change in Vista, I retested it on my XP64
machine and it works as expected.

But the user is initiating the action - that is what I am getting at here;
the person at the other end of the screen in ACTUALITY is the one who has
the
privileges that are assigned to the programs they run; to pretend as if
this
were not so by assigning programs to run in a hodge-podge of different
user
accounts is a poor solution.


I agree, this functionality should be available. I have even suggested
this
same thing in an earlier thread in this forum .

I am all for this kind of security model and would find SUID much less
necessary if such a model existed.
However my concern is that it is conciderably more complex and I don't think
it will happen anytime soon in any truely usable form. And if Vista is any
indication, I'm not going to hold my breath. SUID seems reasonably simple
to implement even if it is a hack. I think MS is simply in denial that ANY
security model could be effective when the user must know the administrative
password.

This should never be necessary, as it doesn't make sense. How can an
application in the control of a user be able to do something that the user
can't do?


Well, it would certaintly change the behavior of UAC. UAC allows the user
to
choose how much privileges an application has. A user (or an admin on the
user's behalf) would still need to look at what privs an application is
requesting and approve/deny them; also, a user may still want the usage of
certain privs to prompt for consent, and there would be cases where an app
with lower-privs wants to start an app with higher-privs, this would
require
consent.

UAC is borderline anoying in its current form, I would rather not be
prompted for 90% of what Vista prompts me for. Many administrative tasks
already prompt Are you sure? after pressing OK. I shouldn't even need to be
prompted if I haven't even done anything yet. UAC is only mildly useful
because MS can't otherwise prevent non-administrative applications from
having administrative privilages nor ensure the physical user actually
requested the action when an administrative application is run. A better
security model would prevent less privilaged applications from launching
privilaged applications in the first place. If each process had an
application token and that token did not provide a privilage required by the
process it is trying to create then prompt the user for concent. UAC is a
hack. Windows deserves better!

- Kurt

 

[Jimmy Brush]

Agreed. The physical user does not change via SUID. SUID is perhaps a

hack but it is one that has been used effectively for decades. The
problem is I have yet to see MS propose anything better... and the current
windows security model is BROKEN.

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!

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 .

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.

Windows is nearly impossible to use without an administrative user or
password, if you don't have a desired privilage...

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?

grant it to yourself, don't have permission to access a file... take
ownership of it.

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.

If a corporation wants to ensure laptop users do not share "my documents"
to the world over an unsecure wireless network?... group policies are a
start perhaps but if you have the administrator password you can do
whatever you want.

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

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.

They are seperate but (no longer) independent permissions. If you grant
"execute file" permissions you must grant "read data" permisison or
execute
fails. This appears to be a change in Vista, I retested it on my XP64
machine and it works as expected.

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

I am all for this kind of security model and would find SUID much less
necessary if such a model existed.
However my concern is that it is conciderably more complex and I don't
think it will happen anytime soon in any truely usable form.

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.

And if Vista is any indication, I'm not going to hold my breath. SUID
seems reasonably simple to implement even if it is a hack. I think MS is
simply in denial that ANY security model could be effective when the user
must know the administrative password.

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.

UAC is borderline anoying in its current form, I would rather not be
prompted for 90% of what Vista prompts me for. Many administrative tasks
already prompt Are you sure? after pressing OK.
Agreed.

I shouldn't even need to be prompted if I haven't even done anything yet.

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..

UAC is only mildly useful because MS can't otherwise prevent
non-administrative applications from having administrative privilages
Agreed.

nor ensure the physical user actually requested the action when an
administrative application is run.

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.

A better security model would prevent less privilaged applications from
launching privilaged applications in the first place. If each process had
an application token and that token did not provide a privilage required
by the process it is trying to create then prompt the user for concent.

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

UAC is a hack. Windows deserves better!

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