After years of security enhancements in Windows, is privilege separation _still_ impossible?

[Roof Fiddler]

Whenever I try to install a program, it requires administrative privileges.
How do I grant an installer permission to write its files into c:\program
files\whatever without also giving that installer permission to gather up
all of my private data files and send them over the internet to the
program's author?

 

[Jimmy Brush]

You can't easily do this. As you mentioned in a recent post, this would have
to be done by running the installer in the context of another user that is
locked down to your specifications.

I see this as a valid concern and I hope Microsoft will find ways to allow
you to discriminate access to objects and rights based on what program is
executing, not just on the user.

 

[Steve Riley [MSFT]]

This is actually an extremely difficult problem to solve. How do you distinguish between the actions of a user -- delete c:\*.* -- and the actions of a program -- File.Delete("c:\*.*")?

______________________________________________________
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


You can't easily do this. As you mentioned in a recent post, this would have
to be done by running the installer in the context of another user that is
locked down to your specifications.

I see this as a valid concern and I hope Microsoft will find ways to allow
you to discriminate access to objects and rights based on what program is
executing, not just on the user.

 

[Jimmy Brush]

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the actions
of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I see this
as what UAC (and MIC, and related technologies) fundamentally accomplish -
Windows is finally acknowledging that yes, applications ARE the user's agent
and receive their authority to perform actions from the permissions granted
to the user; but, ALL applications that the user runs do not need to be
granted ALL of these permissions, and it should be up to the user to decide
how their authority to do things is delegated.

I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a pretty
blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should have an
SID associated with it, and the user should be able to set grant/deny
privileges for programs to the securable objects that THAT USER has access
to. These program security permissions don't REPLACE user permissions; I see
them augmenting them. If a user has access to a securable object, they
should be able to choose which programs can use that access. I see these
permissions being assigned to an object on a per-user basis (i.e. how one
user decides to allow programs to access the securable objects they have
access to should not affect other user accounts).

Also think files should be assigned two owners - one the user who created
it, and two the program that created it (wouldn't that be useful - even if
it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access privileges each
..exe can have based on the access privileges assigned the user (i.e. the
user has SeDebug privilege, but only visual studio can use the SeDebug
privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default application
security attributes on files (i.e. say for program files: All programs
read-only, installers create new directory and full access to created
folders).

This way, programs could specify the built-in group they want to belong to
in their manifest, and then the UAC prompt would be able to specify how much
access they are requesting, and the user would be able to say yes/no, or
even change that access level from the dialog box ("no, i dont want you to
be in the installers group, I want you to be in this custom security group
that I have defined...")

The way I see it, whenever a process is created, it receives the access
token of the user, and then filters that access to the specific access the
user wants it to be able to have (based on the SID assigned to its .exe
file, what program-group(s) it belongs to, even based on what access token
the process creating it has). When the process accesses a securable object,
if the user has the desired access to the object, it then checks to see if
the program has the desired access, and if not returns access denied.

To guard against privilege escalation, a process that spawns another process
that is in a different program-group or has less restrictive privileges
could throw UAC, but not the other way around (and/or, any program that
spawns another program that meets or exceeds certain privileges always
throws UAC, and does not meet/exceed never throws UAC).

You could also give the user the choice to not prompt with UAC when certain
programs/program groups spawns another process, but instead only allow the
spawned processes the least common denominator security privileges afforded
both processes (this way you don't bug the user but the spawned process has
no way of exceeding the privileges the spawning process has).

And, all of these UAC settings could be customized for each program group.
And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always spawns
UAC).

In any case, having multple privilege levels available via UAC and expanding
the amount of granular control these privilege levels have over the
programs, however implemented, should result in more security (no more
full-admin or no-admin, a true 'least privileged access' environment) and
better customization and saneness for the user (the ability to assign
programs to a wider range of privilege levels and then control when and how
UAC is prompted should create a nice way to reduce the amount of UAC prompts
without loosing much security).

 

[Steve Riley [MSFT]]

Lots of interesting ideas, Jimmy. Securely identifying applications, and making sure that such identification is valid and hasn't been spoofed in some way, is the root of the "hard problem." It's one of the things we're starting to work on.

______________________________________________________
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the actions
of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I see this
as what UAC (and MIC, and related technologies) fundamentally accomplish -
Windows is finally acknowledging that yes, applications ARE the user's agent
and receive their authority to perform actions from the permissions granted
to the user; but, ALL applications that the user runs do not need to be
granted ALL of these permissions, and it should be up to the user to decide
how their authority to do things is delegated.

I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a pretty
blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should have an
SID associated with it, and the user should be able to set grant/deny
privileges for programs to the securable objects that THAT USER has access
to. These program security permissions don't REPLACE user permissions; I see
them augmenting them. If a user has access to a securable object, they
should be able to choose which programs can use that access. I see these
permissions being assigned to an object on a per-user basis (i.e. how one
user decides to allow programs to access the securable objects they have
access to should not affect other user accounts).

Also think files should be assigned two owners - one the user who created
it, and two the program that created it (wouldn't that be useful - even if
it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access privileges each
.exe can have based on the access privileges assigned the user (i.e. the
user has SeDebug privilege, but only visual studio can use the SeDebug
privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default application
security attributes on files (i.e. say for program files: All programs
read-only, installers create new directory and full access to created
folders).

This way, programs could specify the built-in group they want to belong to
in their manifest, and then the UAC prompt would be able to specify how much
access they are requesting, and the user would be able to say yes/no, or
even change that access level from the dialog box ("no, i dont want you to
be in the installers group, I want you to be in this custom security group
that I have defined...")

The way I see it, whenever a process is created, it receives the access
token of the user, and then filters that access to the specific access the
user wants it to be able to have (based on the SID assigned to its ..exe
file, what program-group(s) it belongs to, even based on what access token
the process creating it has). When the process accesses a securable object,
if the user has the desired access to the object, it then checks to see if
the program has the desired access, and if not returns access denied.

To guard against privilege escalation, a process that spawns another process
that is in a different program-group or has less restrictive privileges
could throw UAC, but not the other way around (and/or, any program that
spawns another program that meets or exceeds certain privileges always
throws UAC, and does not meet/exceed never throws UAC).

You could also give the user the choice to not prompt with UAC when certain
programs/program groups spawns another process, but instead only allow the
spawned processes the least common denominator security privileges afforded
both processes (this way you don't bug the user but the spawned process has
no way of exceeding the privileges the spawning process has).

And, all of these UAC settings could be customized for each program group.
And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always spawns
UAC).

In any case, having multple privilege levels available via UAC and expanding
the amount of granular control these privilege levels have over the
programs, however implemented, should result in more security (no more
full-admin or no-admin, a true 'least privileged access' environment) and
better customization and saneness for the user (the ability to assign
programs to a wider range of privilege levels and then control when and how
UAC is prompted should create a nice way to reduce the amount of UAC prompts
without loosing much security).

 

[Jimmy Brush]

Lots of interesting ideas, Jimmy. Securely identifying applications, and

making sure that such identification is valid and hasn't been spoofed in
some way, is the root of the "hard problem." It's one of the things we're
starting to work on.

Awesome .

Keep up the good work.

 

[Jimmy Brush]

Thanks for comming here and listening, too ... it's good to see a friendly
MS face around

 

[David J. Craig]

Maybe a viewer of executables that can show the various permissions it needs to run would be nice. A disk editor program does not need access to the full registry to alter HKLM\Software\Microsoft or HKLM\System\CurrentControlSet & ControlSetnnn. Such a program does not need the debug priviledge. DLL injection is another item that should be a specific privilege owned by administrators, but can be granted to specific DLLs that are signed with a PIC or some other credential available from Microsoft.


Lots of interesting ideas, Jimmy. Securely identifying applications, and making sure that such identification is valid and hasn't been spoofed in some way, is the root of the "hard problem." It's one of the things we're starting to work on.

______________________________________________________
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the actions
of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I see this
as what UAC (and MIC, and related technologies) fundamentally accomplish -
Windows is finally acknowledging that yes, applications ARE the user's agent
and receive their authority to perform actions from the permissions granted
to the user; but, ALL applications that the user runs do not need to be
granted ALL of these permissions, and it should be up to the user to decide
how their authority to do things is delegated.

I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a pretty
blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should have an
SID associated with it, and the user should be able to set grant/deny
privileges for programs to the securable objects that THAT USER has access
to. These program security permissions don't REPLACE user permissions; I see
them augmenting them. If a user has access to a securable object, they
should be able to choose which programs can use that access. I see these
permissions being assigned to an object on a per-user basis (i.e. how one
user decides to allow programs to access the securable objects they have
access to should not affect other user accounts).

Also think files should be assigned two owners - one the user who created
it, and two the program that created it (wouldn't that be useful - even if
it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access privileges each
.exe can have based on the access privileges assigned the user (i.e. the
user has SeDebug privilege, but only visual studio can use the SeDebug
privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default application
security attributes on files (i.e. say for program files: All programs
read-only, installers create new directory and full access to created
folders).

This way, programs could specify the built-in group they want to belong to
in their manifest, and then the UAC prompt would be able to specify how much
access they are requesting, and the user would be able to say yes/no, or
even change that access level from the dialog box ("no, i dont want you to
be in the installers group, I want you to be in this custom security group
that I have defined...")

The way I see it, whenever a process is created, it receives the access
token of the user, and then filters that access to the specific access the
user wants it to be able to have (based on the SID assigned to its ..exe
file, what program-group(s) it belongs to, even based on what access token
the process creating it has). When the process accesses a securable object,
if the user has the desired access to the object, it then checks to see if
the program has the desired access, and if not returns access denied.

To guard against privilege escalation, a process that spawns another process
that is in a different program-group or has less restrictive privileges
could throw UAC, but not the other way around (and/or, any program that
spawns another program that meets or exceeds certain privileges always
throws UAC, and does not meet/exceed never throws UAC).

You could also give the user the choice to not prompt with UAC when certain
programs/program groups spawns another process, but instead only allow the
spawned processes the least common denominator security privileges afforded
both processes (this way you don't bug the user but the spawned process has
no way of exceeding the privileges the spawning process has).

And, all of these UAC settings could be customized for each program group.
And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always spawns
UAC).

In any case, having multple privilege levels available via UAC and expanding
the amount of granular control these privilege levels have over the
programs, however implemented, should result in more security (no more
full-admin or no-admin, a true 'least privileged access' environment) and
better customization and saneness for the user (the ability to assign
programs to a wider range of privilege levels and then control when and how
UAC is prompted should create a nice way to reduce the amount of UAC prompts
without loosing much security).

 

[David J. Craig]

Maybe for those who want it, UAC could be disabled if a computer is not
connected via any network. You probably can't do it just because you don't
see the internet, but any network connection would not permit this option.
It would require that 1394 be installable without any presence in the
network stack by default. I guess for the impaired even the presence of a
modem would be a problem. It would have to be dynamic in that a plug and
play detection of any prohibited device would revert the system to full UAC.

Just a thought for those who can't live with UAC. One good thing about UAC
is that it will make it easier, over time, to sell Unix/Linux as that is
normal behavior for them. Many won't permit using the root user ID in the
GUI interface but only via a command line/shell login. It is about time
considering Unix has had this for over twenty years. Mainframes even longer
but with several variations.

 

[Steve Riley [MSFT]]

Given my travel schedule, it can be challenging... but it is actually part of my job

______________________________________________________
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


Thanks for comming here and listening, too ... it's good to see a friendly
MS face around

 

[Kerry Brown]

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the
actions of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I
see this as what UAC (and MIC, and related technologies)
fundamentally accomplish - Windows is finally acknowledging that yes,
applications ARE the user's agent and receive their authority to
perform actions from the permissions granted to the user; but, ALL
applications that the user runs do not need to be granted ALL of
these permissions, and it should be up to the user to decide how
their authority to do things is delegated.
I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a
pretty blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should
have an SID associated with it, and the user should be able to set
grant/deny privileges for programs to the securable objects that THAT
USER has access to. These program security permissions don't REPLACE
user permissions; I see them augmenting them. If a user has access to
a securable object, they should be able to choose which programs can
use that access. I see these permissions being assigned to an object
on a per-user basis (i.e. how one user decides to allow programs to
access the securable objects they have access to should not affect
other user accounts).
Also think files should be assigned two owners - one the user who
created it, and two the program that created it (wouldn't that be
useful - even if it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access
privileges each .exe can have based on the access privileges assigned
the user (i.e. the user has SeDebug privilege, but only visual studio
can use the SeDebug privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default
application security attributes on files (i.e. say for program files:
All programs read-only, installers create new directory and full
access to created folders).

This way, programs could specify the built-in group they want to
belong to in their manifest, and then the UAC prompt would be able to
specify how much access they are requesting, and the user would be
able to say yes/no, or even change that access level from the dialog
box ("no, i dont want you to be in the installers group, I want you
to be in this custom security group that I have defined...")

The way I see it, whenever a process is created, it receives the
access token of the user, and then filters that access to the
specific access the user wants it to be able to have (based on the
SID assigned to its .exe file, what program-group(s) it belongs to,
even based on what access token the process creating it has). When
the process accesses a securable object, if the user has the desired
access to the object, it then checks to see if the program has the
desired access, and if not returns access denied.
To guard against privilege escalation, a process that spawns another
process that is in a different program-group or has less restrictive
privileges could throw UAC, but not the other way around (and/or, any
program that spawns another program that meets or exceeds certain
privileges always throws UAC, and does not meet/exceed never throws
UAC).
You could also give the user the choice to not prompt with UAC when
certain programs/program groups spawns another process, but instead
only allow the spawned processes the least common denominator
security privileges afforded both processes (this way you don't bug
the user but the spawned process has no way of exceeding the
privileges the spawning process has).
And, all of these UAC settings could be customized for each program
group. And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always
spawns UAC).

In any case, having multple privilege levels available via UAC and
expanding the amount of granular control these privilege levels have
over the programs, however implemented, should result in more
security (no more full-admin or no-admin, a true 'least privileged
access' environment) and better customization and saneness for the
user (the ability to assign programs to a wider range of privilege
levels and then control when and how UAC is prompted should create a
nice way to reduce the amount of UAC prompts without loosing much
security).

Some great ideas. I agree with Steve though. It is all based on somehow
having a program autheticate that it is indeed the right program and not an
impersonator. The signed drivers in x64 is a start in that direction. It may
also be that the hardware to do this is not available yet. It may require
some kind of hardware based encryption for programs, similar to bitlocker
and tpm.

 

[David J. Craig]

If you can guarantee internet access or for a corporate network, network
access to the domain controller, you can validate with signed files. I am
paranoid so I prefer that both MD5 and SHA1024 or higher be used because
even if someone discovers an attack on SHA I don't think the same attack
will work on both on the same file. The primary reason for the internet
access is to discover if a key has been repudiated because of theft or even
brute force reverse engineering. The domain controller can validate any
corporate software so you don't have to get a third party to sign the files.

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the
actions of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I
see this as what UAC (and MIC, and related technologies)
fundamentally accomplish - Windows is finally acknowledging that yes,
applications ARE the user's agent and receive their authority to
perform actions from the permissions granted to the user; but, ALL
applications that the user runs do not need to be granted ALL of
these permissions, and it should be up to the user to decide how
their authority to do things is delegated.
I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a
pretty blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should
have an SID associated with it, and the user should be able to set
grant/deny privileges for programs to the securable objects that THAT
USER has access to. These program security permissions don't REPLACE
user permissions; I see them augmenting them. If a user has access to
a securable object, they should be able to choose which programs can
use that access. I see these permissions being assigned to an object
on a per-user basis (i.e. how one user decides to allow programs to
access the securable objects they have access to should not affect
other user accounts).
Also think files should be assigned two owners - one the user who
created it, and two the program that created it (wouldn't that be
useful - even if it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access
privileges each .exe can have based on the access privileges assigned
the user (i.e. the user has SeDebug privilege, but only visual studio
can use the SeDebug privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default
application security attributes on files (i.e. say for program files:
All programs read-only, installers create new directory and full
access to created folders).

This way, programs could specify the built-in group they want to
belong to in their manifest, and then the UAC prompt would be able to
specify how much access they are requesting, and the user would be
able to say yes/no, or even change that access level from the dialog
box ("no, i dont want you to be in the installers group, I want you
to be in this custom security group that I have defined...")

The way I see it, whenever a process is created, it receives the
access token of the user, and then filters that access to the
specific access the user wants it to be able to have (based on the
SID assigned to its .exe file, what program-group(s) it belongs to,
even based on what access token the process creating it has). When
the process accesses a securable object, if the user has the desired
access to the object, it then checks to see if the program has the
desired access, and if not returns access denied.
To guard against privilege escalation, a process that spawns another
process that is in a different program-group or has less restrictive
privileges could throw UAC, but not the other way around (and/or, any
program that spawns another program that meets or exceeds certain
privileges always throws UAC, and does not meet/exceed never throws
UAC).
You could also give the user the choice to not prompt with UAC when
certain programs/program groups spawns another process, but instead
only allow the spawned processes the least common denominator
security privileges afforded both processes (this way you don't bug
the user but the spawned process has no way of exceeding the
privileges the spawning process has).
And, all of these UAC settings could be customized for each program
group. And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always
spawns UAC).

In any case, having multple privilege levels available via UAC and
expanding the amount of granular control these privilege levels have
over the programs, however implemented, should result in more
security (no more full-admin or no-admin, a true 'least privileged
access' environment) and better customization and saneness for the
user (the ability to assign programs to a wider range of privilege
levels and then control when and how UAC is prompted should create a
nice way to reduce the amount of UAC prompts without loosing much
security).

Some great ideas. I agree with Steve though. It is all based on somehow
having a program autheticate that it is indeed the right program and not
an impersonator. The signed drivers in x64 is a start in that direction.
It may also be that the hardware to do this is not available yet. It may
require some kind of hardware based encryption for programs, similar to
bitlocker and tpm.

 

[Steve Riley [MSFT]]

It's more than just validating the integrity of the image (.exe) when it loads. You also need to provide for integrity of the image for the entire time it remains in memory; this constitutes the hard part of the problem.

--
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


If you can guarantee internet access or for a corporate network, network
access to the domain controller, you can validate with signed files. I am
paranoid so I prefer that both MD5 and SHA1024 or higher be used because
even if someone discovers an attack on SHA I don't think the same attack
will work on both on the same file. The primary reason for the internet
access is to discover if a key has been repudiated because of theft or even
brute force reverse engineering. The domain controller can validate any
corporate software so you don't have to get a third party to sign the files.

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the
actions of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I
see this as what UAC (and MIC, and related technologies)
fundamentally accomplish - Windows is finally acknowledging that yes,
applications ARE the user's agent and receive their authority to
perform actions from the permissions granted to the user; but, ALL
applications that the user runs do not need to be granted ALL of
these permissions, and it should be up to the user to decide how
their authority to do things is delegated.
I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a
pretty blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should
have an SID associated with it, and the user should be able to set
grant/deny privileges for programs to the securable objects that THAT
USER has access to. These program security permissions don't REPLACE
user permissions; I see them augmenting them. If a user has access to
a securable object, they should be able to choose which programs can
use that access. I see these permissions being assigned to an object
on a per-user basis (i.e. how one user decides to allow programs to
access the securable objects they have access to should not affect
other user accounts).
Also think files should be assigned two owners - one the user who
created it, and two the program that created it (wouldn't that be
useful - even if it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access
privileges each .exe can have based on the access privileges assigned
the user (i.e. the user has SeDebug privilege, but only visual studio
can use the SeDebug privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default
application security attributes on files (i.e. say for program files:
All programs read-only, installers create new directory and full
access to created folders).

This way, programs could specify the built-in group they want to
belong to in their manifest, and then the UAC prompt would be able to
specify how much access they are requesting, and the user would be
able to say yes/no, or even change that access level from the dialog
box ("no, i dont want you to be in the installers group, I want you
to be in this custom security group that I have defined...")

The way I see it, whenever a process is created, it receives the
access token of the user, and then filters that access to the
specific access the user wants it to be able to have (based on the
SID assigned to its .exe file, what program-group(s) it belongs to,
even based on what access token the process creating it has). When
the process accesses a securable object, if the user has the desired
access to the object, it then checks to see if the program has the
desired access, and if not returns access denied.
To guard against privilege escalation, a process that spawns another
process that is in a different program-group or has less restrictive
privileges could throw UAC, but not the other way around (and/or, any
program that spawns another program that meets or exceeds certain
privileges always throws UAC, and does not meet/exceed never throws
UAC).
You could also give the user the choice to not prompt with UAC when
certain programs/program groups spawns another process, but instead
only allow the spawned processes the least common denominator
security privileges afforded both processes (this way you don't bug
the user but the spawned process has no way of exceeding the
privileges the spawning process has).
And, all of these UAC settings could be customized for each program
group. And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always
spawns UAC).

In any case, having multple privilege levels available via UAC and
expanding the amount of granular control these privilege levels have
over the programs, however implemented, should result in more
security (no more full-admin or no-admin, a true 'least privileged
access' environment) and better customization and saneness for the
user (the ability to assign programs to a wider range of privilege
levels and then control when and how UAC is prompted should create a
nice way to reduce the amount of UAC prompts without loosing much
security).

Some great ideas. I agree with Steve though. It is all based on somehow
having a program autheticate that it is indeed the right program and not
an impersonator. The signed drivers in x64 is a start in that direction.
It may also be that the hardware to do this is not available yet. It may
require some kind of hardware based encryption for programs, similar to
bitlocker and tpm.

 

[Kerry Brown]

That's what I meant when saying it may need hardware support. If the program
was encrypted in memory it couldn't be altered. It wouldn't matter if it was
paged out or whatever if it was encrypted. Unfortunately I think the
hardware to do this for all running processes in real time would increase
the cost of a computer quite a bit at the present time.

 

[David J. Craig]

When you accept the fact that you cannot protect a system from an administrator that wants to compromise its security, the only things you have to worry about is not allowing normal users to install drivers or inject code into other processes. I do include the ability to write to the pagefile and harddrive directly as you could modify the image on disk while it is executing. UAC does provide some help in that an admin will know when something occurs that requires access that may introduce a problem. It will help those of us who know what is expected, but it will be a difficult problem to educate most users.
It's more than just validating the integrity of the image (.exe) when it loads. You also need to provide for integrity of the image for the entire time it remains in memory; this constitutes the hard part of the problem.

--
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


If you can guarantee internet access or for a corporate network, network
access to the domain controller, you can validate with signed files. I am
paranoid so I prefer that both MD5 and SHA1024 or higher be used because
even if someone discovers an attack on SHA I don't think the same attack
will work on both on the same file. The primary reason for the internet
access is to discover if a key has been repudiated because of theft or even
brute force reverse engineering. The domain controller can validate any
corporate software so you don't have to get a third party to sign the files.

This is actually an extremely difficult problem to solve.

Agreed

How do you distinguish between the actions of a user [...] and the
actions of a program [...]

You can't.

However, you can constrain what actions a program can accomplish. I
see this as what UAC (and MIC, and related technologies)
fundamentally accomplish - Windows is finally acknowledging that yes,
applications ARE the user's agent and receive their authority to
perform actions from the permissions granted to the user; but, ALL
applications that the user runs do not need to be granted ALL of
these permissions, and it should be up to the user to decide how
their authority to do things is delegated.
I think that allowing the user to choose whether a program runs with
super-limited or super-elevated permissions is a good start, but is a
pretty blunt instrument where a precision instrument is needed.

I would like to see this support expanded. I think every .exe should
have an SID associated with it, and the user should be able to set
grant/deny privileges for programs to the securable objects that THAT
USER has access to. These program security permissions don't REPLACE
user permissions; I see them augmenting them. If a user has access to
a securable object, they should be able to choose which programs can
use that access. I see these permissions being assigned to an object
on a per-user basis (i.e. how one user decides to allow programs to
access the securable objects they have access to should not affect
other user accounts).
Also think files should be assigned two owners - one the user who
created it, and two the program that created it (wouldn't that be
useful - even if it wasn't used for anything security-wise!).

And, the user should be able to choose what specific access
privileges each .exe can have based on the access privileges assigned
the user (i.e. the user has SeDebug privilege, but only visual studio
can use the SeDebug privilege)

I also think you should be able to group programs into program groups
(similar to user groups), and then have appropriate default
application security attributes on files (i.e. say for program files:
All programs read-only, installers create new directory and full
access to created folders).

This way, programs could specify the built-in group they want to
belong to in their manifest, and then the UAC prompt would be able to
specify how much access they are requesting, and the user would be
able to say yes/no, or even change that access level from the dialog
box ("no, i dont want you to be in the installers group, I want you
to be in this custom security group that I have defined...")

The way I see it, whenever a process is created, it receives the
access token of the user, and then filters that access to the
specific access the user wants it to be able to have (based on the
SID assigned to its .exe file, what program-group(s) it belongs to,
even based on what access token the process creating it has). When
the process accesses a securable object, if the user has the desired
access to the object, it then checks to see if the program has the
desired access, and if not returns access denied.
To guard against privilege escalation, a process that spawns another
process that is in a different program-group or has less restrictive
privileges could throw UAC, but not the other way around (and/or, any
program that spawns another program that meets or exceeds certain
privileges always throws UAC, and does not meet/exceed never throws
UAC).
You could also give the user the choice to not prompt with UAC when
certain programs/program groups spawns another process, but instead
only allow the spawned processes the least common denominator
security privileges afforded both processes (this way you don't bug
the user but the spawned process has no way of exceeding the
privileges the spawning process has).
And, all of these UAC settings could be customized for each program
group. And, you might even allow for adding UAC-spawn metadata into
file/registry/object attributes (i.e. for program files, write always
spawns UAC).

In any case, having multple privilege levels available via UAC and
expanding the amount of granular control these privilege levels have
over the programs, however implemented, should result in more
security (no more full-admin or no-admin, a true 'least privileged
access' environment) and better customization and saneness for the
user (the ability to assign programs to a wider range of privilege
levels and then control when and how UAC is prompted should create a
nice way to reduce the amount of UAC prompts without loosing much
security).

Some great ideas. I agree with Steve though. It is all based on somehow
having a program autheticate that it is indeed the right program and not
an impersonator. The signed drivers in x64 is a start in that direction.
It may also be that the hardware to do this is not available yet. It may
require some kind of hardware based encryption for programs, similar to
bitlocker and tpm.

 

[Steve Riley [MSFT]]

Don't confuse encryption with integrity. They are separate security controls. Just because something's encrypted doesn't mean that an attacker can't modify it. This is the basis of how many attacks against WEP succeed. Even with encrypted data, it's possible to glean certain information about the contents.

Encryption here, in the context of application identity, isn't really all that important. It's strong integrity controls that will be the foundation. And yeah, it'll take some interaction with hardware as well. This hard problem can't be completely solved in software alone.

--
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com


That's what I meant when saying it may need hardware support. If the program
was encrypted in memory it couldn't be altered. It wouldn't matter if it was
paged out or whatever if it was encrypted. Unfortunately I think the
hardware to do this for all running processes in real time would increase
the cost of a computer quite a bit at the present time.

 

[Roof Fiddler]

Don't confuse encryption with integrity. They are separate security
controls. Just because something's encrypted doesn't mean that an attacker
can't modify it. This is the basis of how many attacks against WEP
succeed. Even with encrypted data, it's possible to glean certain
information about the contents.

For other readers: a good explanation of the type of attack which Steve
Riley is referring to here is available in Microsoft's "Bitlocker Drive
Encryption Algorithm" paper at
http://www.microsoft.com/downloads/...03-39ae-48be-a8d6-8b0034c92555&displaylang=en

 

[Roof Fiddler]

It's more than just validating the integrity of the image (.exe) when it
loads. You also need to provide for integrity of the image for the entire
time it remains in memory; this constitutes the hard part of the problem.

I don't understand why this is a hard problem. The kernel has the ability to
mark pages of memory as read-only, so if the .exe image's pages are marked
read-only, then nothing can modify those pages without the kernel's
permission, and the kernel can simply refuse to ever give permission.

I must be missing something obvious; can you briefly explain (or provide a
reference to a standard explanation) of why this is a hard problem? Is it
because the kernel must, for some reason which I don't know, necessarily
sometimes allow write access to the image's pages?

 

[Roof Fiddler]

This is actually an extremely difficult problem to solve. How do you
distinguish between the actions of a user -- delete c:\*.* -- and the
actions of a program -- File.Delete("c:\*.*")?

What's your antecedent to "This"? Is it my original goal ("grant an
installer permission to write its files into c:\program files\whatever
without also giving that installer permission to gather up all of my private
data files and send them over the internet to the program's author"), or
your next goal (distinguish between the actions of a user and the actions of
a program)?

Or if you mean that solving the former requires solving the latter, can you
explain why?