Built-in admin account

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

  1. I created a standard user account to use for my daily activities thinking I
    could just use run as administrator when necessary. I was thinking that
    this "best practice" might actually be more practical on Vista whereas on XP
    its not possible to "run as..." on control panel apps, active x installers,
    etc but in vista since these are marked as requires admin it should prompt
    me even when I am logged in as a standard user.

    I was doing okay for short while with uac enabled but then had issues
    accessing my usb drive. When I attempted access the files I recieved no
    prompt and an access denied error, and windows exporer does not provide a
    run as administrator to access files, so I grumble a bit and login as
    administator, but guess what... thanks to the UAC split token my
    administrator account is not really an administrator so when I attempt to
    access the drive I again recieve an access denied error and no elevation
    prompt. It took me a bit to discover that I had removed Everyone from the
    ACL on my USB drive when I was using XP as I use it for backups and I didn't
    want some application writing to it when I was logged in as a standard user,
    had I realized that was the problem I could have changed the ACL via
    elevation when logged in as my standard user but it brings up an interesting
    question....

    What exactly is the advantage (if you can call it that) of the split-token
    except the ability to elevate by pressing continue instead of typing in
    credentials, yea!, but at the expense of numerous application compatiblity
    issues. Why UAC decided best practice is to create administrative accounts
    that are actually standard user accounts with credential-less elevation is
    beyond me, instead they should have created a third type of user Standard
    User With Approved Admin group for credential-less elevation and leave the
    administrator account alone! Correct me if I'm wrong but with UAC enabled
    if I can't perform the task as a standard user then I won't be able to
    perform the task as an administrator either! And so, if I need to login as
    administrator I want every process I run to actually run as administrator
    even when (especially when) the application is not marked as requiring
    administrator privilages (if it was I could have performed the task via
    elevation from my standard user account), as far as I know the only way to
    do that is disable UAC because automatic elevation still requires the app to
    be marked as requires admin or the use of run as administrator.

    I thought the solution to this would be rather simple, just disable UAC.
    However once I disabled UAC I found my standard user account no longer
    prompts for credentials when I click run as administrator (just runs
    normally as my standard user) and IE Protected mode no longer works! So my
    question can I somehow login as the built-in adminstrator when I really want
    and/or need a real administrator token due to some compatibility issue with
    an app not marked as requires admin rather then disable UAC?

    - Kurt
     
    Kurt Harriger, Nov 24, 2006
    #1
    1. Advertisements

  2. Kurt Harriger

    Jimmy Brush Guest

    Hello,

    The majority of users operate their computer while logged in as an
    administrator. The benefit here is that the applications that need admin
    access can get it *easily* from the user (not requring a complete log-in),
    while the majority of programs that DON'T need admin access don't have it.

    Also, running "administrative" programs in the context of another user
    seperate from the main user on the same desktop introduces some pretty
    severe application compatability issues itself [think seperate registry
    hives and program storage locations] - the split-token solution is superior
    to this in my opinion.
    Essentially, what you have described is what was done.

    Built-in admin account: all programs run with admin permission. This account
    is disabled by default and is not intended to be used except in an emergency
    (i.e. no other admin accounts are available and the computer is in safe
    mode).

    Administrators group: "standard user" with on-demand approval required for
    admin permission usage

    Users group: "standard user", must log in as an admin user in order to run
    administrative programs
    "Run as administrator" is your friend in both scenarios. If you are trying
    to do something that won't work, and you suspect that it is because the
    application is not prompting for admin permission, then you must run the
    program explicitly with admin permission by right-clicking it and clicking
    run as administrator.

    It is the application's responsibility to automatically prompt you for admin
    rights usage, not Windows.

    Granted, there is no way to do Run As Administrators on files; instead, you
    have to use Run As Administrator on the program that is used to access those
    files.

    But, there is nothing that you can't do in a UAC-restricted admin account
    that you CAN do with UAC off. You may have to learn a new way to do it (run
    as administrator), but it is possible.
    This "run every process as admin" is disabled by default because of its
    inherent insecurity. All applications do not require admin permissions - it
    is kind of foolish to allow all of them to have such permision.
    The best solution is to mark the application as requiring admin permissions
    yourself. Right-click the program, click proeprties, click the compatability
    tab, and then check run this program as administrator. You can also do this
    on a shortcut: right-click it, properties, advanced button, check run as
    administrator.

    You can also enable the built-in administrator account, which is excluded
    from "admin approval mode", using local users and groups in computer
    management. However, note that while logged in as the built-in administrator
    you don't get the benefits of UAC either (i.e. protected mode in IE). If you
    decide to use this account, you should use it sparingly.
     
    Jimmy Brush, Nov 24, 2006
    #2
    1. Advertisements

  3. Hi,

    The way I see it, elevation should simply not be allowed at all.

    Since year 2000 we've been running all our apps with user rights and
    none of our users have Admin password so it's impossible for them to
    "Run as Administrator".

    The sheer complexity of Vista and UAC is demonstrated by the amount of
    text in this single NNTP thread!

    I may be wrong, but it's quite possible this level of complexity (and
    ability to elevate) will offer new and exciting opportunities for
    hackers and virus writers.

     
    Gerry Hickman, Nov 24, 2006
    #3
  4. Don't run QuickBooks, do you? :)

    If you've been running your users as "Power Users" there's no essential
    difference between that level of rights and Administrator rights in XP/2000.
    Power Users have only a very few limits on their rights compared to
    Administrators as far as the end-user box goes.

    As developers, programmers and corporations get their stuff in a bag, there
    will be less need for elevation than before. But for now, it's nearly
    essential.

    --
    Richard G. Harper [MVP Shell/User]
    * NEW! Catch my blog ... http://msmvps.com/blogs/rgharper/
    * PLEASE post all messages and replies in the newsgroups
    * The Website - http://rgharper.mvps.org/
    * HELP us help YOU ... http://www.dts-l.org/goodpost.htm
     
    Richard G. Harper, Nov 24, 2006
    #4
  5. Kurt Harriger

    Jimmy Brush Guest

    And it still is impossible with UAC. Of course, the "ideal" situation is not
    yet possible for the majority of people, primarily due to application and
    even system incompatibility with standard user mode. UAC is the means by
    which it will become possible.
    UAC is a very, very simple change to the core architecture of Windows. Don't
    mistake my attempt to explain it as a representation of its complexity :)
    If you consider trying to defeat a very well-implemented and challenging
    security model as "new and exciting", then I completely agree with you.
     
    Jimmy Brush, Nov 24, 2006
    #5
  6. Not really, there is no longer an administrative group. IMHO it creates a
    great deal of ambiguity, especially regarding remote administration. As an
    administrator I should be able to access administrative shares or use the
    computer management snapin from another computer, etc... yet at the same
    time I only want this permissions if I connect to the computer as an
    admistrator account. Since vista's best practice is to create
    pseudo-administrator accounts then users could perform these activities
    remotely with no-prompt. That doesn't seem that bad at first after all you
    might think that such activities require the user to open computer
    management right click computer and connect to another computer, surely they
    are doing it on purpose. However, this could leave the door open for
    exploits from software running running on an XP computer with their
    credentials even if that XP account is a non-administrator if the
    user/password is the same as their Vista pseudo-admin account, which is
    usually the case for laptop users like myself that want to be access shares
    without having a domain controller and without being prompted all the time.

    I will admit that if you make it to easy to login to the admin account users
    will create start creating real admin accounts again and vendors will feel
    less pressure to seperate standard user and admin functionality. But IMHO
    it was just the wrong approach entirely, I wish it worked more like the .NET
    CLR security where every application could be granted a permission set and
    the application would receive the intersection of the user permissions and
    the desired permissions, if it doesn't have enough permissions a user with
    the required permssions would grant the application permission to run as his
    user account and set the allowed permission set. Unfortunatly MS believes
    that SUID used by every other (more secure) OS is evil. But we see how well
    that worked out in XP because without SUID users were forced to use an admin
    account. Even with Vista users must either have an admin account or know
    the administrator password to perform any administrative task even if the
    administrator would be willing to grant the user permissions for that
    specific task or specific application they can't do so (at least not without
    having considerable development skills necessary to create a secure windows
    service or com+ application to perform the elevated task as a service user).
    Not nearly the same granularity provided by SUID. IMHO, until MS has the
    experience to become truely inovative they should stick with what works well
    on other platforms rather then bashing it as the most common cause of
    elevation attacks on other platforms, because the most common source of
    elevation attacks on windows is having users login as administrator, MS has
    a far worse problem and I think they need to reconsider.
    I suppose I could use another less friendly program like cmd shell to copy
    files, just not windows explorer - the most common windows application used
    to manage files and folders, I can change the permissions but I actually
    prefer that I can't access those files unless I login as administrator so
    that I or some other software doesn't accidently corrupt them, and changing
    permissions back after I'm done is going to be forgotten at some point.
    This worked so well in XP I don't know why have doubts that I'm going to be
    able to right click and run as administrator every time I need it - control
    panel apps, active x controls, shell extensions etc, were not possible to
    run as in XP. Control panel and active x issues have hopefully been
    resolved but still no run as for explorer so hopefully I wont need
    administrative shell extensions, as it is if it requires admin I'm assuming
    these aren't going to work until updated for vista.

    Mostly just windows explorer.
     
    Kurt Harriger, Nov 25, 2006
    #6
  7. Kurt Harriger

    Jimmy Brush Guest

    Actually, a member of the administrators group has been redefined as only a
    'local' administrator - his power is only good at the console (or when
    logged in via remote desktop) - he has no admin rights when authentciated
    via the network as you suggest.

    This behavior, of course, can be changed via group policy, and is discussed
    elsewhere.

    Basically, ANY TIME an administrator local to a computer tries to use his
    admin power, he/she must be able to authenticate with the computer thru UAC
    so that the computer knows that he is the one requesting that the action
    take place.

    If this authentication is not possible, than the action does not take place.

    Domain-level administrators are not constrained in this manner.
    Essentially, it does kind-of work like this beneath-the-covers, but not to
    the extent in .net, and certainly not to the extent of SUID.

    However, you have to realize the problem UAC is solving: it prevents
    privilege escalation without admin consent. Esentially, UAC enforces
    privilege barriers, and in order to transcend from one to the other, the
    user must consent to the transition, assuming the user has permission to
    access the higher privilege.

    In your scenario, sure the rights assigned to the program would fit the
    program like a glove and would thus provide maximum security with minimum
    loss of functionality; however, the problem of privilege escalation remains.
    A program could execute a program with more permissive privileges and then
    exploit this other programs behavior. Or, a program could request privileges
    that it does not need, and then abuse the power.

    In essense, the user/admin has control at installation time (choosing the
    permissions to be applied to the program), but after that, the user no
    longer has control, and the UAC model is broken.

    UAC is Windows' way of allowing a user to control the power programs have.
    This control only remains "pure" if it is asked EVERY time programs try to
    use this power. If a permission state is permanently applied to a program,
    then that program is no longer under the user's control, and other program
    can take advantage of that program to circumvent the security. This would
    introduce an architectural bug into UAC - its very design would allow itself
    to be circumvented.

    I am in agreement that something similar to SUID is needed; however, I don't
    think that this would replace the current UAC behavior, but rather augment
    it.
    It's not that it's evil. It's just that the security model MS is trying to
    enforce cannot be enforced with that behavior in place :)
    You're right, Windows doesn't allow for programs to run with admin power
    when launched by a standard user. Instead, an admin must provide
    over-the-shoulder credentials or launch this admin process his/herself. I
    don't see this behavior as ever changing, even if Windows does implement
    something like SUID. A user is granted X permissions - they should not be
    able to run programs with >X permissions.
    In earlier builds of Vista, you could run-as-administrator Windows Explorer.
    Unfortunately, I have yet to install Vista RTM, so I'm not sure what RTM
    behavior is.
    You're right - the scenarios you mention will require updated versions in
    order to work right "out of the box". As I said earlier, I am not 100% sure
    if Explorer can be run-as-administratored (I know it couldn't in XP, but in
    some Vista builds it could). If it can, then that would allow the scenarios
    you mentioned to work thru user intervention.
     
    Jimmy Brush, Nov 26, 2006
    #7
  8. Okay, that seems resonable to me, no open doors unless the user opens it
    via the group policy and domain admins can still do their job effectively.
    I don't really have a problem with the prompts for elevation, but rather the
    inability for an administrator to pre-approve a program to run with elevated
    permissions, without the user knowing the administrative password. To grant
    the user permission to run a single administrative task the administrator
    must grant him permission to run every administrative task.

    I was once a unix administrator and we had a support team that would perform
    various administrative tasks such as installing updates on the client
    systems which required root permissions. When we were rather small those
    tasks were performed as root user by someone with enough experience to
    perform the activities correctly. As we grew in size, and rather quickly,
    we often had to perform many of the same activities on dozens of systems
    which became too much of a burden on us and we began adding more support
    personel that would work from set of instructions. One of our support guys
    however was not so careful with his typing and thinking he had learned a few
    tricks attempted to remove a directory tree with rm -r * which accidentially
    became rm -r /* and I was on a plane by the end of the day. The problem was
    that these tasks required root permissions and our support staff therefore
    needed to login as root to perform these tasks. After that incident we
    developed shell scripts to perform all root tasks that would be performed by
    our support team, we marked these scripts to run as root and granted only
    the support users access to these scripts, the root passwords were changed
    and it never happened again.

    This is why I think SUID is so great, because of this experience I can see
    the need to grant a subset of the administrative tasks to specific user
    groups. It is not impossible on windows, but requires a develper to write a
    windows service or com+ application to perform the task as a service user on
    the users behalf, which is usually is not a task the average administrator
    can perform and if developed incorrectly could open the system up to other
    unintended exploits. However with SUID all that the administrator needed to
    do was to grant an application permissions to run as specified user and
    restrict the ACLs to the desired user groups. These type of SUID
    applications may not require any IPC, a simple command line application or
    gui with a few with the pre-approved task this user can perform.

    My concern with Vista is that we will see an explosion of applications that
    install windows services to perform administrative tasks later without
    prompts and self updating applications with apis like
    installupdate(filename), which because they are running in the background
    necessarily require some form of IPC to communicate with the client
    application and so they may also open the door to potential exploits that
    may have been avoided if IPC was not required.
    I could careless if the user was prompted before running a SUID application
    and Vista could easily prompt the user that this application runs as an
    elevated user... do you want to continue? But the windows alternatives do
    not really give Vista a chance to ask concent, when and how often do you ask
    for concent on a windows service? I have a feeling that the next major
    security issue in windows is going to poorly written services and microsoft
    is again going blame vendors, block services and com+ apps afrom installing
    without explicit concent prevent services from communicating with
    nonadministrative users, etc

    Vista will be difficult if not impossible for some users to use if they
    don't have an administrative password. Administrators are not going to want
    to come around to every workstation in the morning and type in his
    credentials so users can run a specific application without knowing the
    administrative password. Requiring the user to be an administrator or
    provide administrative credentials defeats the benefits of SUID. If all
    unix users always knew the root password there would have been no need for
    SUID.

    UAC may be a step in the right direction however as it does allow the user
    to have multiple security tokens to resolve registry and user specific path
    issues which may be necessary in a windows environment and having the
    ability to prompt for concent before running an SUID could be useful. But I
    don't see how SUID could possibly be useful if the user must first have the
    required permissions and/or aquire them before running the application.

    The purpose of SUID applications is not to elevate the users permissions but
    rather to take them away. SQL Server is a good example. In order to grant
    the user a subset of the ACLs on the database file, ie modify table data but
    not schema or database elements, you must first grant another user (SQL
    Service User) permissions to the necessary resources, develop an SUID
    application (SQL Server Service) to perform those activities on the users
    behalf, grant the user permissions to use this application, and then you can
    take away these permissions from the user. This is much more secure then an
    access database where the user can either access the database or he cannot,
    with SQL Server the user does not need to have permission to write directly
    to the database file to modify the contents of a table, in fact allowing the
    user to do so would allow also allow the user to bypass SQL security and
    modify not just the table contents, but truncate the entire database.
     
    Kurt Harriger, Nov 26, 2006
    #8
  9. Kurt Harriger

    Jimmy Brush Guest

    The problem here is that users are assigned rights to do certain things, and
    programs inherit these rights from the user - not the other way around. SUID
    violates this abstraction, resulting in potential privilege escalation. This
    is a conceptually flawed design.

    This is just as bad, perhaps even worse, as the example given where a
    programmer [incorrectly, I should add] creates a service to expose some
    admin functionality which is consumable by all applications, because in the
    case of SUID, not only can other programs take advantage of the rights given
    to the SUID program, but the user can DIRECTLY take advantage of this leaky
    privilege to escalate his/her privileges, without programming anything.
    You're trying to have your cake and eat it too. I agree it tastes good, but
    it comes with a price. You want your admins to be able to do X, but then
    again, you don't :). I understand what you are saying, but I don't think the
    SUID as implemented in *nix is a correct solution.

    The way I see it, you should be able to grant your admins/users rights to do
    whatever it is that they need to do via user permissions. Then, you should
    be able to further limit how much of those rights individual applications
    can use. In this way, the programs are able to use only the rights that it
    needs from the pool of rights the user is assigned.

    This does not violate the programs-inherit-permissions-from-users
    abstraction, but still gives you some benefits from SUID.
    I agree whole-heartedly with this statement; but, as I said before, this 'if
    developed incorrectly' clause applies to SUID apps as well, and perhaps is
    of even greater importance.

    Services are designed to provide abstract functionality that is to be
    consumed by applications. This abstract functionality, although it may be
    implemented using admin functionality, should not expose such admin
    functionality directly to the consumer (programs). Services are to extend
    the functionality of the operating system, not break the security model.

    In essense, SUID moves this concept up one abstraction layer - it allows a
    PROGRAM to implement some admin-type behavior, with the implicit
    understanding that the program will not allow privilege escalation, and the
    program is to be consumed directly by a USER. But this is incorrect design,
    because privilege escalation in this scenario is unavoidable :). I know this
    is a very fine distinction, but it is nonetheless very different and a very
    real security threat.

    I am ardently aware that many programmers will misuse the service
    abstraction to bypass security, and I am very concerned with and
    disappointed by this behavior as well (I hope I conveyed this well enough a
    few threads back ;). But the solution is not SUID - this is just breaking
    the security abstraction even more, in a way that fundamentally can never
    fit the security model.
    Again, if the user does not have direct permission to carry out this
    pre-approved task, then allowing both the user directly and other programs
    indirectly to perform this task through a specific program is still
    privilege escalation! Only allowing privileges to be carried out through
    certain programs is still allowing that user or programs that the user runs
    to misuse that task to his/her advantage.

    In the service vs. program analogy, IPC was how the lower-privileged app
    talked to the higher-privileged one. In the case of SUID, this communication
    channel exists, but not in the form of IPC - it exists in the form of
    executing and interacting with a program. In this case, any lower-privileged
    process (and the user directly) can execute a higher-privileged SUID
    process, and interact with it, either via the command line options or by
    other means.

    However, if the program was unable to exceed the rights of the user, and the
    program was limited as to what it could access/do based on the rights of the
    user, then this would indeed be a very useful security tool :).
    I am very, VERY concerned with this as well. :(
    IPC is conceptually the channel of communication between the non-privileged
    process and the privileged one. This channel must exist in some form
    whenever non-privileged meets privileged, so even though it would not be IPC
    in the case of SUID, it still exists.
    Even if the user is prompted, it would still be privilege escalation, if the
    user his/herself did not have the same rights as the rights assigned the
    program. Although, this would be much preferable to not being prompted :)
    Excellent point. However, the alternatives are NOT meant to do what you
    describe :)
    I agree, and I am curious (and not in a good way) as to how Microsoft will
    respond. Microsoft needs some way to enforce the service abstraction - that
    is, providing abstract functionality to applications that needs to be
    implemented with admin powers but does not expose direct admin power to
    applications.
    You're right in the fact that the user should be assigned ONLY the
    permissions they need to carry out their tasks. But, they MUST have
    permission to do what is expected of them. SUID is not needed to allow this
    to happen.

    Although, some of the SUID functionality could be implemented to lock-down
    applications so they only have the chunks of permission from the user that
    they specifically need to carry out their specific tasks.

    I think you do - and you say it yourself in your very next statement.
    The difference between the implementation of SQL server and the
    implementation of SUID is subtle, but very, VERY important.

    The part of SQL Server that runs as a service basically extends the features
    of the operating system - it exposes a new object, a database, and exposes
    the functionality to access databases to APPLICATIONS. Applications are then
    created the are COMPOSED of this functionality, which is then provided to
    the user. The APPLICATIONS that are composed of this functionality run with
    the rights of the user.

    This is "correct" because a SERVICE running at a higher privilege level
    exposes abstract things that PROGRAMS are COMPOSED of. This is the reason
    the service model exists at all - to allow for this. This is how the
    operating itself is set up - all unprivileged actions, once you get thru to
    the lower levels of the abstraction, are composed of privileged actions.
    This DOES NOT, however, create privilege escalation scenarios if implemented
    correctly.

    SUID is "incorrect" because it is an APPLICATION that is running at a higher
    privilege level that allows USERS and other programs to INTERACT with it.
    Notice here the difference - users are not COMPOSED of applications, users
    INTERACT with them. This conceptually creates the availability of privilege
    escalation that is by design - no matter HOW it is implemented, privilege
    escalation is possible, because that is the nature of the design.

    Now, I would be foolish to say that SUID is not useful - you yourself have
    used it very well with great results. And I'm not saying that the security
    issues it introduces can't be mitigated - this can be done, as is done in
    most *nix environments. But, the fact is, it is conceptually flawed by
    breaking the security abstraction - and no matter how this is mitigated, or
    implemented, this flaw will always be present, as it is a design flaw. I
    support Microsoft's decision not to implement it, but I would VERY MUCH like
    to see some of the ideas in SUID be introduced into the Windows Security
    Architecture in such a way as not to break the design.

    Wow, this is an excellent discussion, thank you for bringing it up!!! :)
     
    Jimmy Brush, Nov 26, 2006
    #9
  10. Kurt Harriger

    Jimmy Brush Guest

    People were forced to use admin accounts in XP due to application and system
    incompatibility due to programs not being designed to run correctly in a
    standard user environment. One of the results of UAC will be to fix this
    problem :).

    Sure, it was the intent of Windows XP that their idea of "privilege
    seperation" be implemented by users logging in as standard users and then
    only using admin accounts to administer the system. But, that didn't work;
    so, UAC now enforces privilege seration - and it is a much more secure model
    than the old way, since even when running as an administrator, the processes
    that don't need admin power don't have it, preventing them from being
    exploited or messing up and fluking the system.

    Windows has a very rich security model that allows privileges to be
    delegated to users; Just because there is an "Administrators" group that has
    full privileges by default doesn't mean this is the only class of user
    available - you are free to make your own groups with their own specific,
    constrained permissions however you like. Windows XP and Windows Vista both
    support this model.
    Users can be delegated specific permissions to do whatever is required of
    them. If they need to be able to change the system time, for example, they
    can be granted only this adminsitrative power and nothing else - and, when
    logged in under their user account, even though they are NOT an
    administrator, they will be able to change the system time WITHOUT using an
    administrator password, since their account has that privilege.

    Same thing when accessing objects such as files and registry keys - you can
    grant your users privileges however you want, without requring them to know
    the administrator account's password.
    When logged in as an administrator with UAC enabled, you should be able to
    run-as-administrator explorer. The split-token design should allow this to
    work correctly - using run as administrator when logged in as administrator
    starts the program with the full admin token instead of the filtered token,
    and does not do any other hocus pocus - it is a very simple operation and
    should work on all .exes.

    When logged in as a standard user, when you run-as-administrator a program,
    you are actually logging in with the user profile of the administrator
    account and running the program from that other user profile, not your
    standard user account, and for some reason explorer does not and has never
    supported this. This is indeed unfortunate, but as you mentioned, this is
    the behavior you want - you don't want to be able to do this from your
    standard user account, but you do from your administrator account.

    The standard user / admin user account methodology still works with UAC. It
    seems you have found something that you can't do under a standard user
    account that you can only do from an admin account :).

    The administrators group is STILL around and is just as powerful now as it
    was in Windows XP - the only difference is, it requires consent before
    running an app with the admin token, and some apps don't automatically ask
    for the token (but you can run ANY app with the elevated token using run as
    admin under an admin account). You can't directly run a non-app, such as an
    ActiveX control or shell extention as admin, because these are hosted inside
    of another app that you must elevate instead. Also, I should point out, that
    if an elevated app (i.e. cmd.exe) starts another app (i.e. you start an app
    from cmd), than that child app automatically is elevated, with no prompt.

    This "admin approval mode" from administrators is also more secure because
    UAC prevents "admin" apps from talking to "normal" apps in most ways,
    preventing most forms of shatter attacks, in the same way that IE protected
    mode prevents internet explorer from talking to the rest of the system.

    Vista standard user accounts still have the shortcommings of Windows XP
    standard user accounts, as you have found out, because they essentially work
    the same as they did in Windows XP (run as administrators works exactly like
    run as did in XP in this case), but they do take advantage of the app-compat
    features of UAC (such as virtualization) and the privilege seperation
    enforced by UAC (seperating higher-privileged processes from lower ones).
     
    Jimmy Brush, Nov 27, 2006
    #10
  11. Kurt Harriger

    Jimmy Brush Guest

    When logged in as an administrator with UAC enabled, you should be able to
    OK, I finally got RTM installed, and was very displeased to find out that
    you can't do this :(.

    This is a big step in the wrong direction for Microsoft. I can only read
    this as an artificial limitation for whatever reason, as this was working in
    earlier builds. How do they expect people to manage their computers when
    logged in as an administrator when Microsoft is breaking their own security
    model by refusing to allow elevation for certain programs?
     
    Jimmy Brush, Nov 28, 2006
    #11
  12. I agree with you to an extent. If I wanted to allow users to archive and
    clear the application event log I could very easily write a console
    application clearmyeventlog.exe that would do so and grant this application
    permission to clear the event log. Unfortunatly this would be application
    specific and another developer would not be able to come around later and
    create a windows form wizard application that could perform the same task,
    the best they could do is invoke my application when the user presses
    finish. A service would be more reusable but I'm not sure the added
    complexities of developing a privilage service are worth the risks.

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

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

    Jimmy Brush Guest

    I agree with you to an extent. If I wanted to allow users to archive and
    Privileges just aren't applied to programs - they are given to users, and
    then the applications inherit those privileges from the user.

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

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

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

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

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

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

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

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

    Allowing this just really rubs things in the wrong direction. However, I am
    starting to see what you are getting at, and it would be very handy for a
    lot of purposes... I just can't think of a good way to get it to fit in with
    the security model.
     
    Jimmy Brush, Nov 28, 2006
    #13
  14. I agree that you should set permissions at the lowest level possible, the
    resource itself when and if at all possible and if you don't need to use
    SUID then don't. The clearmyeventlog as is, is not the best example,
    however, if I revise the requirements slightly so that clearmyeventlog must
    first save the eventlog prior to clearing it then I can't grant the user
    permission to clear the event log as there is no way to guarentee the user
    will actually save the eventlog before clearing it. The only way I can
    enforce this rule is to require the user to use my application (or service)
    to do so.

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

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

    It should also be noted that SUID does not require the elevated user to be
    administrator it can be any user that has permissions to the necessary
    resources, just as you don't need to run SQL as System you don't need to run
    SUID applications as system/administrator either, a program the saves and
    then clears the event log should run as a user that has only those
    permissions. SUID might even be more useful to run as processes as more
    restricted user then an elevated user, one without network access or one
    with nework access but no file permissions.
    This is unfortunate, I think it should also be possible to grant/deny
    permissions to individual applications. Why should I grant any program
    except outlook access to my mailbox files, allow a program other then office
    to disable macro security by editing the registry, these resources and
    settings are private to the application unless of course I specifically
    grant access to those resources. I don't even see any reason that the user
    running the application even needs access to read a program exe, dlls,
    images, and other resources, these are private application components that
    should not be manipulated directly by the user, the only permission the user
    should need for an application is execute. Applications should have ACL
    lists of their own that specify who can execute, manage, update/patch,
    uninstall, and perhaps other application specific ACLs; applications should
    be treated as a system resources not just a set of files or "the user".

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

    Is there something else I'm missing here? I don't understand how priviliage
    elevation is always possible with a SUID application but the same is not
    true of a service? I don't really see how a service is somehow inherently
    more secure or less vunerable just because its a service. Granted the
    service could never launch another application on the users desktop but
    chances are if either were capable of spawing other processes you have a big
    problem regardless of which desktop the application runs on. I'm not saying
    SUID applications can't have bugs that could be exploited, but I don't think
    it really matters much if the user interacts with an application or an
    application interacts with it the service either one could be exploited.
    But I do think its easier to test the behavior of an application then that
    of a service. Additionaly, a service is usually running in the background
    at all times, giving crackers plenty of time and opportunity to try their
    best, whereas the application may only provide the elevation for a very
    short period of time, and it is much easier to automate an attack on a
    service then it is to automate an application by pumping windows messages
    into the application message queue. SUID has many of the same risks as
    services and if you don't need to use it don't, but I think either is better
    then giving the user the administrator password to perform a couple of
    administrative tasks (that you can't otherwise safely grant via group
    policies).
     
    Kurt Harriger, Nov 29, 2006
    #14
  15. I agree that you should set permissions at the lowest level possible, the
    resource itself when and if at all possible and if you don't need to use
    SUID then don't. The clearmyeventlog as is, is not the best example,
    however, if I revise the requirements slightly so that clearmyeventlog must
    first save the eventlog prior to clearing it then I can't grant the user
    permission to clear the event log as there is no way to guarentee the user
    will actually save the eventlog before clearing it. The only way I can
    enforce this rule is to require the user to use my application (or service)
    to do so.

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

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

    It should also be noted that SUID does not require the elevated user to be
    administrator it can be any user that has permissions to the necessary
    resources, just as you don't need to run SQL as System you don't need to run
    SUID applications as system/administrator either, a program the saves and
    then clears the event log should run as a user that has only those
    permissions. SUID might even be more useful to run as processes as more
    restricted user then an elevated user, one without network access or one
    with nework access but no file permissions.
    This is unfortunate, I think it should also be possible to grant/deny
    permissions to individual applications. Why should I grant any program
    except outlook access to my mailbox files, allow a program other then office
    to disable macro security by editing the registry, these resources and
    settings are private to the application unless of course I specifically
    grant access to those resources. I don't even see any reason that the user
    running the application even needs access to read a program exe, dlls,
    images, and other resources, these are private application components that
    should not be manipulated directly by the user, the only permission the user
    should need for an application is execute. Applications should have ACL
    lists of their own that specify who can execute, manage, update/patch,
    uninstall, and perhaps other application specific ACLs; applications should
    be treated as a system resources not just a set of files or "the user".

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

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

    Jimmy Brush Guest

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

    However, CONSTRAINING the user, with X privilege, to only using Y
    application to USE that privilege, fits the model perfectly, while
    accomplishing the same goal.
    You may be correct, but it will be due to misconfigured applications, as UAC
    is designed to allow users with "extra" privileges to be able to use their
    privileges, as long as applications utilize UAC correctly.

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

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

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

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

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

    So, when running the MMC (marked highest available), it will receive the
    user's unfiltered token, which allows MMC to use any special privileges the
    user has been assigned (and without prompting the user for consent).
    I agree, another possible UAC solution would have been if the applications
    could have defined exactly what privileges they need, and then let UAC
    determine based on this information whether to prompt or not.

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

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

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

    This is how the system clock works when the user is logged in as a non-admin
    - it checks to see if the user has the change time privilege. If they do,
    then it just works ; if they don't, it requires an admin to log in to change
    the time.
    The problem is not that SUID is prompting the user for permission; it's that
    they are being prompted for permission to do something that they do not have
    rights to do.

    UAC only prompts for permission when the user is taking action that they
    HAVE permission to do, or asks for a user to log in who HAS the permissions.
    I completely agree with SUID-type behavior for LIMITING what privileges the
    user has. The part I disagree with is when using SUID to INCREASE privileges,
    even if the user has given consent, and even if an admin has pre-approved it.

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

    We are essentially saying the same thing in different ways, I know ... but I
    think it is an important distinction to make.
    I agree with you that one should be able to control what access applications
    can have to securable objects, as well as what privileges get filtered down
    to the application.

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

    How do you seperate the user from the application, at a technical level? You
    can't. How do you DISALLOW the USER from doing something, while ALLOWING an
    application to do that something? You can't.
    Well, Windows is STARTING to take this into account with UAC, but I agree
    with you that it is just a start, and there is a LOT more that needs to be
    done, as you have suggsested here.
    UAC protected mode is accomplished using mandatory integrity control and
    virtualization, and I won't be surprised if third party tools pop up allowing
    you to run other apps in this kind of mode.
    I will respond to this later, after I come up with a better way to explain
    it :).
    You and I want the same thing, we are pretty much just debating convention.

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

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

    This is what you and I both ultimately want.

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

    I am all for an implementation using the CONSTRAIN method.

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

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

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

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

    Such a security model would practically eliminate the need for UAC as the
    default security policy would be the same sandboxed environment, but the
    differences may be small as two tokens are still needed, but in this case
    instead of using a standard user token and linking that to the
    administrative token I'm thinking that we should have "application security
    tokens" which are linked to the users security token standard or
    administrative. This would do away with the need for SUID too, rather then
    changing running the application as another user you would grant the
    privilage as "final" to the application which would also allow windows to
    write the user running the app rather then suid user name to the audit logs.
    Perhaps, I think granting the user execute permission to an privilaged
    application is in effect granting the user a "custom permission." It might
    be possible to use a form of application security to nullify administrative
    privilages the user does have but I don't think this would work well with
    multiple user accounts, because it is the intersection of the user and
    application permissions is important and if all users are admins the
    usefulness of the user token is nullified. Although perhaps something like
    the .net PrinipalPermisionDemand could be used to define application
    security per user, maybe. But I don't think windows will ever be usable
    without an administrator account and/or password; so perhaps the best thing
    I can hope for is that a new model supersedes the existing one where
    administrative accounts is assumed but otherwise meaningless.
     
    Kurt Harriger, Dec 1, 2006
    #17
  18. Kurt Harriger

    Jimmy Brush Guest

    If I (the admin) big the user the ability to execute to the application I
    I am agreeing with you that this should be possible. I also agree that SUID
    makes this possible. However, what I disagree with is the design of SUID, of
    how this is implemented in the form of SUID.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    My point here was that the person using the computer is in the eyes of
    Windows one user defined by their user account, and that technically its an
    elevation of privilege when another app is run with higher privileges than
    what the user account has access to, even though it works out the way you
    want it to.
    You're right, and I agree with you. But Windows deserves something better
    than SUID :).
    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.
    But the user is initiating the action - that is what I am getting at here;
    the person at the other end of the screen in ACTUALITY is the one who has the
    privileges that are assigned to the programs they run; to pretend as if this
    were not so by assigning programs to run in a hodge-podge of different user
    accounts is a poor solution.
    I agree, this functionality should be available. I have even suggested this
    same thing in an earlier thread in this forum :).
    This should never be necessary, as it doesn't make sense. How can an
    application in the control of a user be able to do something that the user
    can't do?
    Well, it would certaintly change the behavior of UAC. UAC allows the user to
    choose how much privileges an application has. A user (or an admin on the
    user's behalf) would still need to look at what privs an application is
    requesting and approve/deny them; also, a user may still want the usage of
    certain privs to prompt for consent, and there would be cases where an app
    with lower-privs wants to start an app with higher-privs, this would require
    consent.

    - JB
     
    Jimmy Brush, Dec 2, 2006
    #18
  19. 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.

    I'm open to alternative suggestions.... but SUID works and I haven't really
    heard any better ideas.
    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.
    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.
    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
     
    Kurt Harriger, Dec 3, 2006
    #19
  20. Kurt Harriger

    Jimmy Brush Guest

    Agreed. The physical user does not change via SUID. SUID is perhaps a
    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.
    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?
    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.
    True. That is why nobody should have the admin passwords in a corporate
    network except those people who are required to have the privileges.
    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.
    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.
    Wow, you're right ... I believe this is a bug. :(
    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.
    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.
    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..
    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.
    Agreed, however UAC already accomplishes this - only it is limited to two
    privilege levels, non-admin and Admin.
    LOL, it's not as bad as SUID, but due to the requiresAdministrators behavior
    I have to agree. :)
     
    Jimmy Brush, Dec 3, 2006
    #20
    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.