Built-in admin account

Discussion in 'Windows Vista Security' started by Kurt Harriger, Nov 24, 2006.

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

    I agree this model would be a significant improvement.
    So why didn't MS implement this instead?
    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.
    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.
    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
    We both agree a better model is needed. SUID may not be it, but I think it
    is better then using custom services.
    Kurt Harriger, Dec 3, 2006
    1. Advertisements

  2. Kurt Harriger

    Jimmy Brush Guest

    SUID should not just be some attribute that follows around and is granted
    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.
    Agreed - anything that can be done via an SUID app could also be done via a
    service. I used a bad example here.
    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

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

    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'
    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
    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.
    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.
    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.
    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.
    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 :).
    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.
    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 :).
    Jimmy Brush, Dec 4, 2006
    1. Advertisements

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

    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

    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).
    Agreed. But without applications windows itself doesn't do much more than
    move around files and play music (unless you live in the EU :)
    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 :).
    Perhaps not a problem with the security model itself but it can
    significantly limit its use.
    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.
    Kurt Harriger, Dec 8, 2006
  4. Kurt Harriger

    Jimmy Brush Guest

    You've said before elevation is always possible with SUID 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:


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

    MS needs to make doing things correctly the easier way - or at least the
    path of least painfulness.
    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.

    I hope so too. :)

    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.
    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.
    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.
    Jimmy Brush, Dec 12, 2006
  5. 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."
    Interesting, hadn't noticed that.
    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.
    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.
    Kurt Harriger, Dec 14, 2006
  6. Kurt Harriger

    Jimmy Brush Guest

    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.

    Agreed. :)
    Jimmy Brush, Dec 18, 2006
  7. I'm afraid I simply don't believe this. There are still programs
    (like QuickBooks) that require admin permissions on Win2K and WinXP,
    and Intuit has had since 1999 to fix that. They just refuse to do
    it. And that's far from the only such application.

    If you really think that software developers will adapt to UAC, then
    I wonder how you explain the fact that so many of them never adapted
    to *not* running as admin on older versions of Windows? This has
    been the bane of my existence as a system admin for small
    David W. Fenton, Dec 29, 2006
  8. Kurt Harriger

    Jimmy Brush Guest


    Reason's simple ... before, developers could assume the user had admin
    privileges with limited consequences - a few users (proportionally speaking,
    of course) who were in the minority would have problems, but most users out
    there would have no problems.

    Now, most users are running inside of a UAC enviornment - they are now the
    majority. Developers tend to program for the majority. Microsoft has
    essentially turned the tables, and is using this fact to force them to
    update their applications. Unless developers want to inconvienence their
    customers by forcing them to click on a prompt every time their applications
    starts (and they won't do this unless absolutely necessary), they will
    change their program.
    Jimmy Brush, Dec 30, 2006
  9. Why in the world would developers have assumed that? The only reason
    I know that anyone sets up users as admins is because of the fact
    that developers assume that users are set up as admins. If the
    software developers did their job properly, nobody would have to run
    as admins.

    - a few users (proportionally speaking,
    Depends on what software you're running.
    Huh? How in the world can most people be running in a UAC
    environment when Vista has just been released?
    Then they should design their programs to *run* LUA. Installation is
    a different matter, of course.
    Well, sure, but the locked down C: drive of Win2K didn't change
    their habits, so why will UAC change them now? To me, it seems like
    UAC just makes it *safe* to run as admin, rather than making it more
    attractive to engineer your apps to run LUA.
    David W. Fenton, Dec 31, 2006
  10. It is about time that developers finally created applications that do not
    require admin access. If the free software folks can do it and have been
    doing it for years, why does it take so long? Many Microsoft programs
    require admin access, though newer versions may be better. I do know that
    most of their developer tools needed it far too frequently. CD/DVD burning
    software is another application category that needs it. There used to be a
    fairly standard interface called ASPI but it hasn't been shipped with
    Windows for a long time. That allowed any application to obtain access to a
    device handle to CD & DVD drives while running in normal user mode. There
    were some bugs where access to hard drives could be had and that was a
    problem, but fixing it and publishing it would make it easier. Now almost
    all burning software has to have a driver that can provide access to the
    optical drives. Each one is unique and the API is not standard.

    Let us hope that the new push towards UAC and everyone running in user mode
    takes hold. I see far too many posts from those who just disable UAC and
    think that is a good thing. My only question for them is why not keep using
    XP. That would make sense. You can create a manifest for an existing
    program that will identify its admin requirements and just use UAC.
    Somewhat of a pain, but just like Linux when you run Yast it always requires
    the root password.
    David J. Craig, Dec 31, 2006
  11. Kurt Harriger

    Jimmy Brush Guest

    Reason's simple ... before, developers could assume the user had
    Because that was the truth - the majority of windows users operated their
    computer within an administrator account. I'm definately not saying that's
    the right way for the developer to look at things, but that was the cold,
    hard reality.
    Perhaps in a locked-down business world this is the case. However, things
    are different in the consumer world. From the point of view of a software
    developer, if they weren't specifically targeting customers using a
    least-privileged enviornment, I can easily see why they wouldn't care if
    their app didn't work 100% in a least-privilege environment [although I
    don't agree with this behavior].

    This is kind of a chicken-and-the-egg problem. Developers won't program
    software for non-admins until most people run as non-admins. People won't
    run as non-admins until developers program for non-admins. Deadlock!

    UAC solves this problem by making the majority of users run as both admin
    and non-admin, with non-admin being default, and the transition into admin
    mode undesirable from the viewpoint of the software developer.
    Well, actually the statement I made here depends on the market for a
    software applicaton. My point here was that if a developer knows that their
    user is running as an administrator [majority of cases for most markets
    pre-Vista] then they have less motivation for making sure their app works
    right in the minority case where their user is in a least-privileged
    I was speaking in abstract terms here. If a developer is writing an
    application for Vista, then they must assume that the user will be in a
    UAC-protected environment, since that is the default case.
    That's my point - thanks to UAC, they have a very strong motivation to do
    this :).
    In Vista, developers must either re-engineer the app to be LUA, or require
    the user to click a prompt every time the app is run. Before, there was no
    "down-side" to not engineering for a LUA environment for the general case
    [where the user is an admin]; now, there is.
    Jimmy Brush, Dec 31, 2006
  12. Perhaps I've misunderstood UAC, but I think what it does is allow
    people to run as admin more safely, by only handing out the admin
    credentials when the user has explicitly authorized it.
    David W. Fenton, Dec 31, 2006
  13. Kurt Harriger

    Jimmy Brush Guest

    I wasn't commenting here on whether one would have problems running as a
    standard user.
    Aha! My point! :)
    By "people" I am referring to the majority of windows users, not you or your
    clients :).
    Yeah, it seemed backwards to me at first as well... but the more I thought
    about it, the more it made sense to me. If I am really an administrator, why
    should I have to have a seperate limited user account for security reasons?
    Why shouldn't I be able to control the privileges of applications I run from
    a single account?
    Right ... this is the "minority" of users with problems that I was talking
    about. I imagine the justification would go something like "why should we
    spend resources making these 'niche' scenarios work correctly when we could
    be fixing bugs/refining/adding features that many more people will see and
    No, UAC does not handle anything for them [unless they decide to live with
    forcing the user to approve their application to run whenever it starts, and
    I just don't see any developer wanting that unless they are developing an
    administrative program where this would be normal and acceptable].

    UAC is just the means by which the system prompts the user if they want to
    run a program with admin privileges. It is NOT automatic - an application
    has to request this dialog to be shown WHEN IT STARTS. A process (or com
    component) either receives admin privileges or it doesn't. If an app/com
    component w/out admin privileges attempts to do an admin operation and it
    has not been elevated via UAC, the operation will fail.

    If a developer wants their program to run correctly without displaying a UAC
    prompt, it will have to be programmed to work correctly as a standard user -
    just like if they wanted it to work correctly in XP as a standard user.

    There are a few "hacks" that UAC does for legacy XP apps in order to get
    them to work, but they are not desirable as they can silently fail in some
    pretty nasty ways.
    No ... if an app wants to use admin power, they will have to get the user's
    permission when the program starts. If an app doesn't want to throw a
    permission prompt, it must be designed to work under a standard user
    account, otherwise it will fail.

    UAC is forcing them to make their apps work under a standard user account to
    avoid prompting the user every time their application starts.

    This will force developers to only use admin power when absolutely
    necessary, because they will not want their application prompting the user.

    I agree with you, but I see UAC as something better than the traditional
    "this is my standard user account and this is my admin account" approach.

    I see UAC as fleshing out answers to some more fundamental questions: Why do
    programs that don't need X privileges receive X privileges? My user account
    grants me X privileges ... why can't I (or my administrator) set policy
    describing which applications I can use my privileges with? Why must I have
    more than one user account in order to have a secure system, when I am
    really only a single user? Does that really make sense?

    Happy New Year! :)
    *throws confetti*
    Jimmy Brush, Dec 31, 2006
  14. I agree that UAC is good, but it's good points have virtually
    nothing to do with the problem of apps that are written to require
    full admin permissions.
    Absolutely. UAC allows those who really need to run as admin to be
    able to do it safely. For users who have no need for that (which
    ought to be MOST USERS), it really shouldn't be adding anything new.

    I have worked at a number of companies with domain controllers and
    all the users logged on with user-level permissions (with the
    exception of QuickBooks users!). I really think it's only home users
    and small businesses without proper system administration who are
    running as admins.

    If UAC forces software makers to fix what they've been doing wrong
    since 1999, then that's great. But I see that as only a side effect
    of the design of UAC, not its chief purpose.
    David W. Fenton, Jan 1, 2007
  15. Kurt Harriger

    Jimmy Brush Guest

    In the context of apps that *should not* need admin permission but require
    it anyway, I disagree - UAC is designed to deal with these apps, by both
    working around legacy apps that do this (virtualization) and making it much
    more painful for developers to create such programs.

    Granted, UAC does, in fact, allow programs to be written to require full
    admin permission, and so one can say that it doesn't "concretely" solve this
    problem; however, I think the reality of how an application runs with full
    admin under UAC cannot be ignored, and will indeed be a major motivation for
    devs to write software with least privilege.

    However, in the case of actual admin apps requiring "an administrator" to
    run them, you make an excellent point [and I have said this before]. UAC as
    it's currently implemented makes it too easy for developers who have a need
    to allow their program to have extra privileges to just mark their
    applications as "requiring an administrator", instead of doing it the
    correct way and testing to see if the user has the needed privileges and
    prompting for elevation only if necessary.

    This kind of sweeps the entire rich privilege model of Windows under the
    rug, replacing it with "administrator" or "not an administrator". If I have
    a certain privilege but am not an administrator, I should be able to run a
    program that needs the privilege I hold without having to be a part of the
    administrators group.

    As an example, take the system clock. Users must hold the change system time
    privilege in order to change the time. Windows does it at least
    semi-correctly - if the user has this privilege, they can change the system
    time, regardless of whether they are an administrator or not. However, if
    the user doesn't hold this privilege, the clock requests an administrator to
    log in. I'm sure this took a non-trivial amount of code to implement, when
    UAC should do this automatically for the application.

    As it stands, it is much easier for the developer to simply mark their app
    as 'require admin' than to implement the logic necessary to check for
    privileges and request elevation only if necessary. And this require admin
    behavior is now kind of "supported" by Microsoft, whereas before testing for
    admin and failing if not was considered hackish. This is going to set a
    dangerous precedent IMHO.

    If the system clock was implemented the way I see most developers
    implementing it, it would be marked 'require administrator' to run,
    resulting in all non-admins having to provide admin credentials to change
    the system time, even if they held the appropriate privilege.
    Well, I would add here that UAC implements virtualization and integrity
    concepts to the compatability and security architectures, which provide
    benefits to standard user accounts. Virtualization allows many legacy apps
    that wouldn't run in Windows XP as a standard user to run in Vista as a
    standard user. Integrity control provides privilege seperation between
    well-defined integrity levels (system vs. admin vs. non-admin vs.
    restricted), helping to prevent shatter attacks between levels as well as
    allowing each level to define a "sandbox" that controls which securable
    objects that level can write to, that takes precedence over the permission
    list on objects.

    The infrastructure required to support different privileged apps inside of a
    single user account can be useful for non-admin accounts as well :).
    You say tomato, I say tomato. :) Regardless of how we chose to classify it,
    I certainly hope (and expect) to see significant change in this area in the
    next few years, thanks primarily to UAC.

    - JB
    Microsoft MVP - Windows Shell/User

    Windows Vista Support Faq
    Jimmy Brush, Jan 11, 2007
  16. Hi Jimmy,
    But it's the wrong solution for the wrong problem.
    Again, it's the wrong solution. If Microsoft had wanted to make sure
    user apps would run without Admin rights (which 99% do) then the correct
    solution would be to change the default user accounts to user accounts
    and disable internet access on Adminintrators group. If they'd done this
    on XP, QuickBooks would already be fixed, they'd have gone out of
    business otherwise. What they did instead was crate a half-baked,
    farcical dialog box that merely causes inconvenience. There is never a
    case for filtering a token and there is never a case for privilege
    elevation. This is actually a flaw of XP, it was not an issue on NT4 or
    Windows 2000. What they did instead was try to appease Intuit and the
    idiot home user who logs in with Admin rights and that's the ONLY reason
    for the existence of UAC, it has no place in a corporate environment
    because they users are never Administrators.

    The case of virtualization is always wrong, and Microsoft state in the
    Vista docs that this is an INTERIM solution with no future. It's
    actually MUCH worse. If a home user wants to leave it on then fine, but
    if any business if thinking of leaving virtualization turned on they are
    fools - plain and simple. Look at the HKCU's if you don't believe me.
    But not as much as a motivation as if their app simply said "Access
    Denied", which is what it should say, but Microsoft were too half-baked
    to write a business class o/s (for the fifth year running).

    And Vista means this idiotic practice will continue for another five
    years because of UAC. It will still encourage bad practice.
    It's simple, users run as users, Administrators run as Administrators.
    Except on Vista, it's not simple, they all run as each other and it's a
    total mess.
    It's absurd if users can change the clock. They could end up wrecking a
    differential backup or cause all their program licenses to suddenly
    expire. They should be locked out of the clock, only Admins should be
    able to change it.
    I agree, this is the whole issue. Microsoft have done it completely back
    to front. It's the worst design you could possibly have, it breaks the
    fundamental best practice of users running as users and Admins running
    as Admins.
    Gerry Hickman, Jan 11, 2007
  17. Kurt Harriger

    Jimmy Brush Guest

    Hello Gerry :)

    * Virtualization - I agree with you that it is a temporary "hack" to get old
    apps to work; however, it is a fundamental part of UAC right now, as without
    it, this transition phase would have been impossible.

    You can't just change core OS functionality that breaks tons of programs and
    expect people to just deal with it - you have to have a transition phase
    that deals with most of the broken apps, while moving the market to a new
    direction. Again, this is a chicken and the egg problem: If you break
    compatability completely, you have a great new OS, but no apps will work
    with it. People won't install the OS until apps work with it, apps won't be
    created for the new OS until people use it. You have to walk the middle path

    I was pointing out here that although core UAC may not fundamentally address
    apps created that require admin, practically it DOES address a portion of
    these apps, and I hope it will DIRECTLY address ALL of these types of apps
    in the future :).

    The rest of the points you make in this post seem to be based on your view
    that there are two kinds of people in this world: users and administrators,
    and that this is a hard-drawn line in the sand that should not be violated
    in any way, shape, or form.

    Personally, I see things a bit differently, but it's all semantics really,
    so I will go with this way of thinking for a minute. I will define "user"
    here as someone with no special privileges, and "admin" as anyone who has
    any extended privilege(s).

    You have mentioned again and again the UAC is violating this
    user-role-seperation abstraction. Well, it's not at all! It's just taking it
    to the next level :).

    A "user" in your terms CANNOT perform "admin" tasks. They can start a
    program that asks for admin credentials, but the ADMIN is actually the one
    performing the task or delegating the task to the user if they chose to
    authenticate, even though it is running on the user's desktop. Why force the
    admin to log in to a completely seperate profile in order to accomplish
    something that he might as well be able to do from any account?

    You may think "well it makes it too easy for a user to get an admin password
    and use it improperly" - this is EXACTLY the case in the "old way" as well!
    The only thing that has changed is that it is now easier and quicker for
    admins to use and/or delegate their powers, as compared to Windows XP (as
    you pointed out XP can do this as well, but Vista makes this much easier).

    Similarly, an ADMIN is not limited in any way with UAC turned on; he has all
    the powers that his account is assigned. PROGRAMS are, however, limited.
    Some programs act as if they are run by a standard user; but the admin can
    override this. I mean really, WHY does the calculator need to have
    privileges to format the hard drive? Why should I be worry that if I press
    the "+" button in the wrong way it will fry my hard drive?

    Admins are still admins and users are still users. USER/ADMIN ACCOUNTS have
    a set amount of privileges, and they CANNOT VIOLATE THESE privileges. UAC
    adds an abstraction layer BELOW the account abstraction, that further allows
    privileges to be removed from application that run from within a user
    account. And, the system also allows a program to be run in the context of
    another user account (and all the privileges thereof) on any desktop, but
    since it requires the OTHER USER to authenticate, this does not violate the

    Things work differently now than they did in the past, but the abstraction
    is still pure. Just because it's different doesn't make it bad.

    - JB
    Microsoft MVP - Windows Shell/User

    Windows Vista Support Faq
    Jimmy Brush, Jan 13, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.