> 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
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
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
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
> 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
> 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
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
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
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
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
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
> 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
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
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
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
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
- 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
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
> 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
> 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.
> 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
> 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.
Windows Vista Support Faq