Microsoft Windows Vista Community Forums - Vistaheads
Recommended Download



Welcome to the Microsoft Windows Vista Community Forums - Vistaheads, YOUR Largest Resource for Windows Vista related information.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

Driver Scanner

Re: SUID

microsoft.public.windows.vista.security






Speedup My PC
Reply
  #1 (permalink)  
Old 12-03-2006
Kurt Harriger
 

Posts: n/a
Re: SUID

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:85E1DC21-9298-4DEA-A54E-367223D22CCF@microsoft.com...
>> 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.


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?
>
> <snip>
>> 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.
>
> <snip>
> (Talking about running SUID progs and the user not having the permission)
>
>> 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 .


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

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


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.

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


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.

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


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

>
> - JB


Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 12-03-2006
Jimmy Brush
 

Posts: n/a
Re: SUID
> 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.



--
- JB

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

Reply With Quote
  #3 (permalink)  
Old 12-04-2006
Kurt Harriger
 

Posts: n/a
Re: SUID

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:5749F68A-786B-483A-AD72-92AB74026EC2@microsoft.com...
>> 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!


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

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

>
> As for windows' security model being broken ... I would say the model
> itself is fine conceptually - it makes sense and is consistant with itself
> However, nobody wants to USE the security model (either users or
> programs) - that is the problem. And, it definately could be improved
> upon.
>
> Before Vista, Windows looked at securty strictly at the granularity of the
> user logon, even though under-the-coveres it is applied per-process. When
> a user was logged on, everything had that user's power. This is a problem
> when most of your desktops are running as administrator - because that
> effectively nullifies almost ALL of Windows security. Windows really has
> an amazing security infrastructure, but few utilize it .


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

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

>
> Now, Vista is looking at security at the granularity of the process (which
> is as granular as the current model supports). Microsoft is paving the
> road to allow for more control in this area, and I really hope they
> continue to do so.
>
> I imagine the day where ADMINISTRATORS (whether a fully-privileged
> superuser or some lower-level admin that only has a subset of full
> privileges) can log in with their privileged account, every-day, for EVERY
> TASK, and with NO application compatability problems, and find the idea of
> creating a seperate account for normal use for "security purposes" insane
> because it is not necessary.
>
> We are certainly getting there with Windows Vista ... I use my admin
> account today, every day, and feel very secure knowing I am getting the
> same benefits of running as a standard user, and there is no REASON to
> seperate my accounts.
>
> However, as you point out, most programs that I use that need admin
> permission get TOO MUCH admin permission. And there are still tons of app
> compat problems.
>
>> 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.
>


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


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

>
> Windows has never had an administrative password requirement. Third party
> apps, perhaps. But not Windows.
>
> You can't start limiting privilege usage for programs, or even change the
> Windows security model THAT MUCH, if the programs don't adhere to the
> security model to begin with and WON'T RUN if they don't have God-like
> superpowers.
>
> UAC should start to reverse this behavior, and once apps start to get in
> line, it should be much easier for Microsoft to further fine-tune the
> security model.
>
> However, after considering your statement about requiresAdministrator ...
> you are RIGHT! This kind of suggests a sharp seperation between ADMIN vs.
> NON-ADMIN that doesn't really exist.
>
> One of the aims of UAC, as I see it, is to loosen in the grip of assumed
> privileges made by programmers ... but this sort of REWARDS IT ... Two
> steps forward and one step back, I guess.
>
> Microsoft should have made programs define what privileges they need, and
> then if a user account didn't have those privileges, it should ask for the
> user/pass of a user with those privs that are needed to log in and approve
> the action.
>
> With UAC, an app has two easy choices - it can tell Windows that it needs
> ALL PRIVILEGES (requiresAdmin) *which SHOULD NEVER BE THE CASE and SHOULD
> NOT be an option at all!*, or that it needs NO PRIVILEGES, and Windows
> will then take care of everything for it - elevation, and all that jazz.
>
> For an app to be implemented correctly - using the UAC mode AsInvoker - an
> application is pretty much telling Windows that it will handle security
> itself, and then gets NO HELP from Windows whatsoever! It has to do a lot
> more work to determine if the user has only the privileges they need to
> perform the action, and if not, to manually ask the user for some other
> user with the correct privileges - In effect, an applications has to
> RE-IMPLEMENT UAC behavior itself if it wants it to work correctly outside
> of the two extremes, full privs and no privs!
>
> Luckily, however, programs that use requriesAdministrator will always
> throw up that consent prompt. Hopefully many programs will [correctly] use
> asInvoker instead and work within the bounds of what privileges the user
> has, as this will not throw a prompt unless the user is logged in as an
> administrator.
>
> Still, I'm sure that many programs will simply use requriesAdministrator
> when it is incorrect to do so!
>
> UAC in its current behavior is *STILL* letting apps get by with not
> working correctly unless they are being ran in a full-privileged
> administrator account, just in a different way! What a pity ...
>
> I can't believe I didn't catch that before .
>
> Man, you hit the nail on the head about increasing the need for admin
> passwords in Vista ... I hope MS changes this behavior in a future
> version of Windows.
>
>> I'm open to alternative suggestions.... but SUID works and I haven't
>> really heard any better ideas.

>
> SUID conceptually really doesn't need to be changed that much. The Windows
> architecture would need to be changed, but not much at the lowest levels.
> The big thing that would need to be changed is applications and the way
> applications are installed - they would need to describe to the OS exactly
> what privs they need to run, and what securable objects they need access
> to.
>
> I imagine MS could make a tool that would help automate the process of
> defining what privileges a program needs, and make it very easy for a
> program to set this up using Windows Installer.
>
>
> Step 1 -> Define the privileges of the user
>
> Windows already does this.
>
> Step 2 -> Define the privileges the application needs
>
> I would do this using the same low-level privilege/permission structure
> Windows already utilizes for user permissions, with some differences
> higher up the abstraction layer to enforce the correct security model.
>
> Every .EXE (or anything else that translates into a process, such as a com
> component) would be assigned a unique security identifier (takes the place
> of a user account in SUID), and these security ID's would then be assigned
> into logical groups that represent applications (for example, there could
> be a MICROSOFT ACCESS application group that is linked to the .exe's / com
> component security ID's installed with MS ACCESS, which could itself
> further be a member of the MICROSOFT OFFICE application group).
>
> It should be mandatory that the installer create at least one root
> application group, in the name of the application (or app suite), and that
> all further applications groups and .exe security identifiers be children
> of this mandatory group.
>
> An application cannot make its application groups or its .EXE's a member
> of another application group, unless another application has pre-approved
> this process using digital signatures to uniquely identify another setup
> program that has such access.
>
> As an example, you install Microsoft Access by itself, and the Access
> installer sets up the Microsoft Office program-security heirarchy, but
> only installs Access. If you then install Excel, Excel should be able to
> install it's EXE's and application groups into the Microsoft Office
> application-security group, and can prove this by using digital
> signatures: when Access is installed, it can tell the OS that any program
> with digital signature X has permission to add itself to the Microsoft
> Office application group, and then all the MS Office app installers will
> have digital signature X.
>
> Also, every file should have two owners - a user owner and an .EXE owner.
> During installation of an application, all files created by that installer
> should be program-owned by either the application group of the app, or an
> .EXE file that is installed.
>
> Also, any file created will be program-owned by the .EXE associated with
> the process that creates the file.
>
> In this way, Windows and admins knows WHICH USER created files on the
> computer AND which application created/owns a file.
>
> In essense, security-wise, an application (an abstract concept) consists
> of executable things that turn into processes that have defined the
> privileges they need, and applications may further be a part of
> application suites.
>
> Durring application installation, setup would create this application
> group / .exe security hierarchy, and then perform the following actions
> for every .exe/com component it creates:
>
> 1) Create the securtiy identifier for the .exe/com component. The .EXE /
> COM object won't run without one of these.
>
> 2) Define what privileges are needed by assigning them to the security
> identifier (SeDebug, etc)
>
> 3) Define what access the security identifier must have to securable
> objects (registry, files, etc) by adding ACLs onto those securable objects
> granting the desired permission to the specific .exe's / com components
> security identifier
>
> This must be done per EXE, not per application group. Application groups
> are to be used by the system administrator - they ONLY contain EXE's / Com
> components and they are for administration purposes only.
>
> So, Windows now knows what privileges specific EXE's / com components need
> to run, but even better, Windows also knows what the abstract thing
> "Application" consists of (what privileges it needs OVERALL, and exactly
> what files, registry keys, etc it consists of or were created using it),
> which is what we need to know as administrators.
>
> Step 3 -> Allow constrainment of user privs and perms
>
> The user token should be modified so that it can contain per-application
> constrainments on the privileges assigned the user. For example, the user
> token can say "SeDebug for <application security ID for Vistual Studio>".
>
> Also, permissions assigned to securable objects can be constrained in this
> manner ... i.e. permission could be applied to the HOSTS file for user
> John to have write access only from the program security ID for notepad
>
> Step 4 -> Security subsystem modifications
>
> Now, let's talk about how this beast works when running.
>
> 1) When a process is created, it contains two security tokens - one for
> the user, one for the .EXE/com component.
>
> The constrainment of the user token also happens at this time - any
> privileges inside the user token that aren't applicable for this program
> are ignored.
>
> If the .EXE contains more privs than the user token, UAC can either prompt
> for credentials, access is denied, or continue to let the program run and
> deny it or prompt for UAC authentication to the privileges when requested.
> The .EXE should dictate how it wants to proceed in these cases.
>
> Also, privileges may be marked in group policy as ALWAYS require consent -
> in this case, whenever an app is about to be granted privileges on this
> list, UAC is prompted for consent.
>
> 2) When code running inside of a process attempts to access a securable
> object (registry key, file, etc), the security subsystem looks at both
> what the user can access and what the program can access to determine what
> action to take.
>
> Permissions on the object that don't apply due to constrainment are
> ignored. For example, if the process is Notepad (which is we'll say a
> member of the application group Windows Utilities), and there is a
> permission that only applies to the user when running Microsoft Office,
> then that permission is ignored.
>
> - If the user *or* the program is denied access, access is denied.
> - If the user *and* the program are granted access, access is granted.
> - If the user is GRANTED access, but the program is NOT GRANTED (and not
> denied) access, UAC might pop up for consent or return access denied,
> depending on system configuration.
> - If the user *and* the program are NOT GRANTED (and not denied) access,
> UAC might prompt for credentials or return access denied.
> - Otherwise, access is denied.
>
> Also, an action on a securable object should be able to be marked "Always
> require consent". In this case, if both a user and an app have permission
> to the file, consent is still requested before it is authorized.
>
> Step 5 -> Administration
>
> I can invision a nice administration UI that would be like a super
> permission and privilege editor. You would be able to view and edit
> privileges and permissions applied to a user or user group.
>
> In privilege editor mode, the privileges applied to the user/user group
> would be visible, both overall and the constrained privileges per
> application (or even .exe).
>
> In permission mode, you would be able to select the User (or user group)
> and see every file/folder/registry key the entity has access to overall,
> with the files they have access to but are constrained to a certain
> application displayed differently, and the files they do NOT have access
> to again displayed differently, with the option to show/hide each type.
>
> You would also be able to narrow down permission mode to view/modify only
> the selected user/user group's permissions when using certain applications
> (or even individual .exe's) - this allows you to easily create constrained
> permissions. In this mode, the UI would only show the files that the
> selected application group/exe needs access to (as defined when the app
> was created), all other files would be hidden. The files the user has
> access to when using that application would be showed differently than the
> files the user has no access to when using that app, and the UI would
> easily allow the administrator to modify how the selected user/group has
> access to those files.
>
> You should also be able to move the focal point from the viewpoint of user
> to the viewpoint of the application - i.e. show what privileges all users
> in the system have when using a specific app or exe, as well as show all
> the files/folders that an app has access to and what users can access
> those files when running the app.


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

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


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

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


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

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


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

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


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

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


Reply With Quote
  #4 (permalink)  
Old 12-04-2006
Jimmy Brush
 

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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


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

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

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

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


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

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

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

>> (Suggested change in Windows to implement SUID behavior)


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


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

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


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

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


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

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

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

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


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

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

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

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

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


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

--
- JB

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

Reply With Quote
  #5 (permalink)  
Old 12-08-2006
Kurt Harriger
 

Posts: n/a
Re: SUID

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:AD269821-788A-4519-AFAC-9F8F47568E4B@microsoft.com...
>> SUID should not just be some attribute that follows around and is granted
>> simply by copying it to the machine. Perhaps a trusted install location
>> where execute file permission is not "inherited from parent" and a
>> management tool like services that allows administrators to enable suid
>> specify the user to run as AND who can access it.

>
> Agreed, there are many ways to mitigate the problem. But SUID simply can't
> exist inside Windows as-is; Windows must be re-architected to support the
> model, and it will look differently than SUID does in *nix. Not knowing
> enough about the *nix architecture I can't really make a comment as to how
> well SUID fits in with it - but I have serious doubts about this.
>
>> Malware could also install a windows service that is accessible to all
>> users and as a bonous windows will even start the services automatically.

>
> Agreed - anything that can be done via an SUID app could also be done via
> a service. I used a bad example here.
>
>> Unless the service (such as SQL) provides some sort of security
>> configuration tool the only control the administrator has is what user
>> the service runs as not which users can access it.
>> Services are IMHO SUID applications that require custom security
>> configuration tools to manage access.

>
> Well, I was waiting for you to point this out . Yes, services in Windows
> ARE an implementation of the SUID model. But services *ARE NOT* SUID apps,
> and Windows HAS NO equivalent to SUID, which is why you would have a hard
> time managing services thinking they are SUID.
>
> The difference between services and SUID apps is the layer at which they
> run and what they are for. Services ARE the operating system, they
> implement functionality in a privileged environment that is exposed to
> applications [the user]. Applications ARE the user, they run with the
> privs of the user to consume OS services. This seperation of privilege is
> enforced by Windows at a very low level, and it is safe to say that only
> maldesigned services or the OS can leak privileges unexpectedly to the
> user.
>
> SUID is for constraining how the user can utilize a privilege, but it
> doesn't fit with the Windows architecture as implemented in *nix. You can
> have SUID-like behavior using services, but as you point out, that's not
> PRECISELY what services are for. If you want to do so using services, you
> have to be a programmer - you can't modify a pre-existing service or
> application to do this.
>
> Windows does not have SUID because it was not designed to. Tacking it on
> to Windows without molding it into the Windows architecture is simply an
> unthinkable act that, although could be useful, ends up destroying the
> seperation of privilege created by the current Windows architecture,
> resulting in a big security-flawed mess.
>
> A service running in the context of a user account is technically "OK"
> (albiet this is certainly a stretch of the imagination) because the user
> accounts are always constraining the full privileges of the OS. Services
> ARE the OS, and if it wants to artificially limit the access it has to
> itself, the more the merrier.
>
> SUID apps essentially are Windows Services in an application form. Since
> users ARE the applications they run, the user essentially becomes the OS
> when running the SUID app. Although the power of an SUID app may be
> constrained in some fashion via the user account it runs under, just like
> services can, they still inherit their "power" from the OS, not the user,
> which is what breaks things.
>
> The intent of SUID is to give the user privileges constrained only to a
> certain app. And it APPEARS to do so in a windows environment - but this
> is not so. Until Vista, Windows has *NOT* seperated privileges between
> applications ran by the user. Although this model has changed in the Vista
> timeframe, there are still incongruencies between the SUID model and the
> Windows model that must be worked out to ensure a bulletproof SUID
> implementation.
>
> This is why I say privilege escalation is unavoidable in this scenario.
> Windows views all the applications that a user is running AS THE USER,
> because this IS the Windows model. Before Vista, there was very limited
> seperation of privileges between apps on the user's desktop, because this
> simply wasn't necessary. Remember, back then, all apps had the same privs
> (whatever was assigned to the user) - no reason to enforce any sort of
> seperation. The primary seperation of privilege line is drawn between
> applications and services/OS, NOT between applications running on a user's
> desktop, and even in Vista where lines do exist here, they are not quite
> what is needed for SUID-like behavior.
>
> If a user were to run an app with higher privileges on their desktop
> (which was the case where services show UI's onto the screen, which Vista
> now prevents), it was pretty trivial for the user through applications (or
> applications of their own volition) to use those higher privileges that
> have presented themselves on their desktop in any way they wanted. Once a
> higher-privileged app appeared on their desktop, the user could use those
> higher privileges outside of the constrainment intended by the
> application.
>
> This is why I say that whenever you break the security model privilege
> escalation is ALWAYS possible - because the entire system depends on this
> model, and when you break it, things no longer fit, and privilege
> escalation is the end result..
>
> This is why I say SUID is conceptually flawed in the context of the
> Windows model, precisely because it doesn't follow the Windows model, and
> that the Windows model has to change to make this happen .
>
> It is only NOW, in Vista, that the notion of different privilege levels is
> starting to be enforced inside of a user account, thru UAC. The Windows
> architecture is slowly being adapted in such a way that SUID-type behavior
> won't break it - it's not quite there yet, but it is getting there, and
> that is why I am hopeful that in the future we will have this wonderful
> feature, in a nice and secure manner .


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


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

>
> If you want users to be able to perform an administrative task, then give
> them the privileges to do so. That IS the windows security model. You
> assign users privileges, and then they can use programs to use those
> privileges.
>
> If a user does not have permission to perform an action, then they MUST
> get an administrator to perform the action or delegate to them permission.
>
> SUID only affects HOW a user uses their privilege - not whether they HAVE
> the privilege. SUID has no effect on the situation you describe.
>
>> However many smaller companies cannot afford the overhead and even if
>> they would like to run users as standard users it is just not practical.

>
> Not practical because WHY? They can't afford to pay administrators? That's
> not the fault of the security model. Windows allows admins to delegate
> whatever privileges users need to the users so they can get whatever work
> they need to do without bother admins.
>
> The only break here is application refusing to comply with the security
> model.
>
> If admins have it set up so that users cannot do their work without an
> admin hovering over their workstation, THAT IS THE ADMIN'S FAULT, not
> Windows' fault.
>
>> Likewise with laptop users where an administrator cannot follow the user
>> around to be there when the user needs to perform some administrative
>> task it just isn't practical.

>
> You seem to be making the case that all users should be administrators
> because it is impractical to limit what standard users can do?
>
> Admins can grant users privileges to do things REMOTELY or through remote
> desktop or remote management the admins THEMSELVES can do the task - or
> they can edit the user's permissions and privileges directly, delegating
> to them the privilege to carry out whatever task they need to do. In the
> later case, the user would just have to logoff and log back in to get
> their new privileges.


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

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

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

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


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

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


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

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

>
> Remote desktop into his laptop and install it myself. Or, grant the user
> the privilege to install the ActiveX control or MSI-based installation
> program.
>
> Granted, you may run into scenarios where due to applications checking for
> admin or whatnot and artificially refusing to run/install even if the user
> has been delegated permission - but this is the fault of third-party apps,
> and not a limitation of the windows security model.


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

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

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

>
> I think they are getting there. The windows architecture is evolving to
> make something like this possible; what I proposed here changes many
> things and depends on answering many tough problems before it could work,
> problems that are already being addressed in Vista.
>
>> I think it will take a few iterations to get right, .NET CAS is very
>> powerful but is too complex for the average user to understand or manage.
>> .NET 1.1 simply denied ability for internet applications that required
>> more permission to then the default zone to execute so rather then allow
>> the user to change the permissions to fit the desired application they
>> came up with ClickOnce which allows the user to install the application
>> granting it fulltrust instead, despite its flexibilty very few .NET
>> applications actually use CAS and many .NET developers don't even know it
>> exists, I think the security config was actually moved into the SDK
>> because no one uses it.

>
> Applications define what privileges they must have to work. If those
> privileges are unavailable, the application cannot run. You're right, the
> problem in that instance was the user could not [easily] give the program
> the privileges it needed to run. In the model I suggested, the user would
> be able to easily give programs permission to run through consent (if
> required) as long as the user themselves had the privileges necessary.
>
>> Except in tightly controlled environmetns many users do have
>> administrative rights on their local machine. The poll I mentioned above
>> shows nearly 80% of users have administrative user accounts. Even
>> without administrative accounts user's machines are concidered to be
>> insecure, secure resources are placed on servers locked up in secured
>> rooms, protected by firewalls, users are only allowed to talk to the
>> application server and the application server will perhaps go through yet
>> another firewall to update an SQL server to prevent users from directly
>> accessing these services. Users don't talk directly to services they
>> talk to application servers, even file servers now days have increasingly
>> become SharePoint sites instead.

>
> Well, my opinion is that the reason users would have to be local admin is
> primarily caused by application incompatability. I think MS found that
> about half of the apps they tested with vista would not run correctly when
> not ran inside of an admin account - but I can't recall the source.
> Through vista's app compat features, I think they got 80-90 percent to
> work - so I do think this will help companies that wish to un-adminize
> their users on a per-machine basis to do so.
>
> As to securing secure resources in the manner you described - this just
> kind of makes sense. Why would you run an SQL server on a user's machine
> and/or let them talk directly to it, when they are only meant to use it
> from a certain app? Essentially, this is the same thing SUID does on a
> local-machine basis - and it is a good idea, which is why I support the
> concept .
>
>>>> 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.

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

>
> Windows Explorer does NOT have SeDebug privilege. The user double-clicks
> Visual Studio, which DOES have the SeDebug privilege. UAC is needed to
> determine if the user intended to launch Visual Studio with elevated
> privileges, because the Application (Explorer) is the one that determines
> what action the UI input takes, NOT Windows.
>
> To put it another way: An application (SaveLotsOfMoney.exe) shows the user
> a message saying they won a zillion dollar and to CLICK HERE to collect
> thier prize. They click the button, and another process,
> TakeOverComputer.exe is executed that requests some nasty privileges. UAC
> is needed here to determine if the user INTENDED to launch a
> higher-privileged app, because it cannot make that determination itself.
>
> If no lower-privileged apps can start higher-privileged apps, your user is
> going to be very, very upset, because this situation will come up a lot,
> where the user wants to start a higher-privileged app from within a
> lower-privileged one (the shell, for example).


True.

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


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


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

>
> The purpose of SUID I agree with; I disagree with the way it is designed
> and implemented. Custom services can be used to implement SUID-like
> behavior, but that is really not their purpose. Neither as-is are a good
> solution for limiting the user's privileges only to certain applications
> .
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/


Reply With Quote
  #6 (permalink)  
Old 12-12-2006
Jimmy Brush
 

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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


I hope so too.

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

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


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

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

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


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

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


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

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


--
- JB

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

Reply With Quote
  #7 (permalink)  
Old 12-14-2006
Kurt Harriger
 

Posts: n/a
Re: SUID

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

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


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

>
> This "attack" is made possible because Windows assumes that every program
> running on the user's desktop has the same privileges, and that those
> privileges are that of the user. This isn't really a bug in Windows - this
> is the way Windows was designed. Different-privileged applications were
> not meant to be operated inside of a user's desktop.
>
> In Vista, Windows seperates different "privilege levels" of applications
> away from each other, so that this kind of attack is not possible except
> inside privilege boundaries, by preventing applications of different
> privileges levels from interacting with each other (this is why you can't
> drag-and-drop from a lower-privileged application to a higher one).


Interesting, hadn't noticed that.

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

>
> I believe Applications have always been allowed to be installed to a
> per-user location inside of the user's profile folder (without needing
> admin). If not before, than they can now. Installing a program that can be
> accessed by any user should require special privileges. And, it has always
> been possible to delegate the ability to install programs to another
> user - the power users group did this. Of course, applications that check
> for membership in the administrors group and then failing if this was not
> the case would not work in this case.
>
> That aside, admins can bless MSI's to be installed without admin privs on
> a machine, and can now do the same thing with ActiveX controls.
>
> However, the problem here is mostly app compatability, not a design flaw
> in the security architecture. SUID would not fix this problem - in both
> scenarios, you, the administrator, would have to assign the user special
> privileges in order to allow them to do what they want BEFOREHAND.


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

>
> In the Windows Model, you would have had to have granted them privileges
> to install the ActiveX control beforehand. In the SUID model, you would
> have created a program with extra privileges that they could use to
> install certain ActiveX controls.
>
> Let me reverse the scenario - lets say you were administering a linux
> machine and the user needed immediate access to a security-restricted
> file, but you had no access to that file from your present location. How
> would you allow them access? Unless you had planned on allowing them
> access to that file beforehand and created an SUID program that gives them
> access (the same as pre-blessing an ActiveX control in the Windows
> example), you still cannot solve the user's problem without using your
> admin powers to do it.
>
> As for MS setting a poor lead ... I'm afraid I can't disagree with you
> there . The "correct" way of doing things has always seemed to be a
> "footnote" in the documentation, and from the developers point of view, it
> has always been easier to do it another way than the "correct" way - even
> for MS developers.
>
> MS needs to make doing things correctly the easier way - or at least the
> path of least painfulness.
>
>> I've already uninstalled Vista from my computer because of application
>> compat issues... many of which are MS apps. SQL developer requires
>> installation of SP2 which is still a CTP, OWA required a patch to be
>> installed on the exchange server, VS 2005 reported app compat issues, the
>> right click context menus do not work in WinRar (using slightly older
>> licensed version, the new version does work) and my printer/scanner
>> doesn't work which I use nearly every week (no vista drivers, I didn't
>> have 64 bit drivers either but I was able to run an XP 32 VM for
>> printing/scanning using XP 64 as a host since VMWare allows mapping USB
>> devices, anoying but it works, no such luck on Vista. I wasn't able to
>> connect the usb device to the VM without first installing the drivers
>> otherwise I would just use VMWare to solve my app compat issues).

>
> Yeah, there are a ton of app compat issues. Windows Vista is certainly not
> Windows XP, and a lot of stuff has changed. This will require updates from
> application vendors, inclusing Microsoft. I think this is a big reason why
> things were not changed more drastically - Vista really has made a lot of
> changes, and is paving the road for even more changes ... but if they had
> gone much farther, the state of app compat would have been much, much
> worse.
>
> <snip>
>>> UAC will help change this behavior, and one of the benfits is that thru
>>> virtualization many of the problem applications will magically start to
>>> work when ran from a privilege-limited account, which should allow many
>>> companies to begin implementing security in their organization.

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

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

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

>
> Agreed. Hopefully thing will reverse such that developers can easily
> create programs that "fall in line" with the Windows model, and have a
> much more difficult time "breaking" the model.
>
>>> The challenge here is finding a way for Windows to KNOW that a user is
>>> intending for this privileged action to take place without asking the
>>> user.

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

>
> This could be possible - however, Windows still doesn't know the INTENT of
> the user. Explorer itself (an untrusted third party in the eyes of the
> Windows) decides how to act on user input - it determines how to react on
> the UI. Windows receives the UI from the user and sends it to the
> application. Windows doesn't know 1) What the app is going to do with the
> UI or 2) What the user was intending to do by performing the UI action in
> the first place. Windows needs to know the answer to both of these
> questions in order to make an intelligent decision.
>
>> But there would still need to be some way for accesiblity applications
>> like an on-screen keyboard to work, and explorer shouldn't run with
>> trusted permissions either so if non-privilaged apps were prevented from
>> starting privilaged ones the shell would be affected also. There are
>> definately some technical challenges but I'm confident they can/will be
>> solved it just going to take some time.

>
> Agreed. But I also think this is a conceptual/design challenge as well -
> how do you get Windows to know what the intent of the user is? Windows can
> know what the user is doing, but it can't know what the user intends to do
> by his/her actions.
>
> The solution will definately involve more metadata about UI and resulting
> actions to be made available from the application to windows. For example,
> if an application wants to start a program when the user clicks a button,
> Windows needs to know this, and Windows also needs to be 100% certain that
> the user also knows if they click on that button a program will be
> launched.


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

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

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


Reply With Quote
  #8 (permalink)  
Old 12-18-2006
Jimmy Brush
 

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


Agreed.

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


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

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

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

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

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

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

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


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


Agreed.



--
- JB

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

Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




All times are GMT +1. The time now is 05:34.




Driver Scanner - Free Scan Now

Vistaheads.com is part of the Heads Network. See also XPHeads.com , Win7Heads.com and Win8Heads.com.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.6.0 RC 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120