Coffeehouse Thread

11 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Should Windows have "root"?

Back to Forum: Coffeehouse
  • User profile image
    W3bbo

    Okay... it has "Administrator"

    But should the Administrator account have the same rights as SYSTEM but at the same time make "Administrators" the equivalent of "Power Users".

    Perhaps the kernel in NT6 should reflect this, and not allow ANY thing or anyone to modify a "safe list" of files unless:

    a) It's done by SYSTEM
    b) The program modifying the files is "AuthentiCode signed" and the kernel checks this with some central server
    c) "Longhorn Home Edition"'s "SYSTEM/Administrator" has a GUID-as-a-password assigned by the OEM (to prevent misuse by spywares and overly curious 12 yearolds)

    Comments?

  • User profile image
    Maurits

    Two problems I see with this:

    1) It's too hard to get AuthentiCode
    If I'm just starting out as a developer I might not want to pay for a central-server-approved AuthentiCode certificate

    2) It's too easy to get AuthentiCode
    What's to stop a hacker from stealing an innocent third party's identity and getting an AuthentiCode certificate under an assumed name?  Sure, once found out, the certificate could be revoked - but the hacker can just rinse and repeat

  • User profile image
    Sven Groot

    The kernel having to check authenticode signatures would also be a problem with systems not connected to the net.

  • User profile image
    msemack

    What does this gain you?

    All I see is that it will escalate the "arms race" between developers and users.

  • User profile image
    AndyC

    Absolutely and most definately not. No one account should have "special" powers. root is one of the worst features of Unix based OS (closely followed by the 9-bit permissions system)

    What really needs to happen is:

    a) Administrators lose the Well Known Sid (a Legacy Admins group can be created with that SID for compatability with old programs.) By default User accounts would be members of the Legacy Admins group (which doesn't actually have Admin rights) but not the real Administrators group. This would force developers to stop checking for Administrators rather than checking for permissions/rights whilst minimizing breakage for old programs.

    b) All admin powers should be defined as User Rights or default security permissions - nothing should be implied. It should be possible to completely duplicate the functionality of Administrators by assigning appropriate rights to another group.

    c) Areas of the system such as the Windows directory should only be writable by the OS or digitally signed Windows patches - except in Safe Mode/Recovery Console. Shadowing of the filesystem/registry should be used for compatability when necessary - I believe this is what AIM will do.
     

  • User profile image
    rhm

    The problem isn't that some accounts are more privileged than others and splitting up privileges between accounts only makes management more complex.

    The real problem is the simplistic security model that started with unix god knows how many years ago whereby programs, by default, run with the privileges of the user running them. That was fine when the OS only had to defend users from each other. Now we live in a world of malware and non-expert users who can't be expected to know what programs are harmful or not. The OS is being asked (or should be anyway) to protect users from the programs they themsleves run.

  • User profile image
    Maurits

    UNIX has setuid for just this reason

  • User profile image
    rhm

    Again, setuid is a very simple-minded approach. It's really designed to elevate privs for apps that are trusted to do stuff users aren't normally allowed to. I'm talking about downgrading a program's privs so it can't do stuff I'm allowed to. Your email app or browser, or even the shell by default could run programs with reduced prvis, but when user would it change to? Would each real user have a corresponding less privileged user account to switch to or would you just set it to nobody? If you set it to nobody how would it gain access to the X server? If you pass it the cookie it needs to access X, how do you then stop it messing with other windows on the display? Do you throw the program in a "chroot jail", if so what files do you let it access? Even user nobody can access enough files on most systems to give away vital data if the program is allowed network access.

    You see it's all very complicated. Protecting clueless people from malware is difficult and it's something the unix world has never dealt with yet they feel smug because the promblem is endemic on Windows. The reason it's such a problem on Windows by comparison is because Windows machines are treated as appliances by most people. They don't give a toss about updates and ACLs and different user acounts and privilege levels etc.

    I talked about this in the Jim Alchin video tread and I hope Microsoft are doing some real innovation for Longhorn along these lines. Sure Avalon is nice and pretty and all that but a core security model that doesn't ape an OS from the 1970s would be more useful.

  • User profile image
    rhm

    I don't think you understand X. A program doesn't need any particular user or group membership to access a given X display - that much in necessary for it to be accessed across networks from different machines. You can give an X application a cookie (although how you do that is left up to the administrator and usually involves horrible shell scipts) that allows it to access a given display.

  • User profile image
    prog_dotnet

    System is a special group and membership is granted automatically to accounts as a result of their activity on a machine or the network as lagre.

    ( you have other special groups also like the Network Service and service for example).
    The specal groups are used to manage rights based on the session context of the security token wich is made when users is authenticated. 
     

  • User profile image
    prog_dotnet

    By the way, Longhorn uses LUA and code access security and will reduce the attack surfice for the windows plattform. ANd the power user group are gone. (only to levels of access, lua or admin )

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/leastprivlh.asp

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.