Built-in admin account

"Jimmy Brush" <JimmyBrush RemoveThis @discussions.microsoft.com> wrote in message
news:85E1DC21-9298-4DEA-A54E-367223D22CCF@microsoft.com...
>> If I (the admin) big the user the ability to execute to the application I
>> GRANT them the privilage, but I only grant them the privilage to perform
>> task using the specified application so that I can ensure the evetlog is
>> saved before it is cleared.
>
> I am agreeing with you that this should be possible. I also agree that
> SUID
> makes this possible. However, what I disagree with is the design of SUID,
> of
> how this is implemented in the form of SUID.
>
> SUID is a "hack" that allows this concept. Windows needs to be
> re-architected to support this, and we have discussed several ways Windows
> could be rearchitected. However, simply throwing on SUID as implemented in
> *nix and saying "here it is folks run with it" is not the solution,
> because
> it does not fit in with the architecture of the OS. You may be able to
> MAKE
> IT WORK, but that doesn't mean it's a good solution . That is my
> position,
> but I think I have gotten a little carried away trying to state it.
>
> There is a person sitting at a screen running programs. Now, we both agree
> that to the computer, there is no such thing as a user - there are only
> apps
> with privileges. But regardless, SOMEONE is sitting out there, at an
> interactive desktop, running programs.
>
> This is precisely why programs SHOULD NOT have privileges in and of
> themselves - because the person at the other end of the screen is the one
> using the program, and is the one who receives the benefit of the
> privileges.
>
> It is kind of rediculous, in fact, to think of a user application as
> having
> privileges when it is being ran by, on the behalf of, or interacting with
> the
> person on the other end of the screen - because regardless of the design
> or
> implementation of the software, that person is the one in control of the
> user-mode program, and thus the one who is using/receiving the privileges.
>
> Windows defines this person as the abstract concept "user".
>
> Now, this is the whole point I was making about privilege escalation and
> breaking the Windows model. Because if you are running an application on
> one
> user's desktop in the context of another user (SUID), this is privilege
> esclatation BY DEFINITION. The person at the other end of the screen is
> now
> BOTH USERS, the user that the person is logged in as AND the user account
> that the program is running under, and the person using the computer does
> IN
> FACT have all the privileges of both accounts - they just can't use them
> all
> at once.
>
> For applications 1-7, the user is ACCT1. For 8-9, the user is ACCT2. This
> effectively accomplishes what YOU WANT - you want the person to have
> different privileges while using different applications - but it is
> incorrect
> because the person when logged in to a computer is a user - ONE user.
> Pretending that he/she is two users doesn't make sense.
>
> Also, as implemented in *nix, SUID applies privileges to the program
> directly, without taking into consideration the user who is running the
> program (except by who has permission to execute the .exe, which isn't
> ENOUGH
> control, IMHO). This is incorrect, and a better solution would be as you
> have
> previously discussed, an intersection between what privileges are assigned
> to
> the user and how the user is allowed to use those privileges when using
> the
> program. But I should add the program privs should always flow FROM the
> user
> privs, as this is actually what happens, and any model that does not
> follow
> this doesn't fit in with reality.
>
> You can say that the user doesn't have priv B but can use app A which uses
> priv B, but what you really MEAN is that the user DOES have priv B when
> using
> app A. This is what I mean when I say we both want the same thing to
> happen
> but are looking at it in different ways.

Agreed. The physical user does not change via SUID. SUID is perhaps a hack
but it is one that has been used effectively for decades. The problem is I
have yet to see MS propose anything better... and the current windows
security model is BROKEN.

Windows is nearly impossible to use without an administrative user or
password, if you don't have a desired privilage... grant it to yourself,
don't have permission to access a file... take ownership of it. If a
corporation wants to ensure laptop users do not share "my documents" to the
world over an unsecure wireless network?... group policies are a start
perhaps but if you have the administrator password you can do whatever you
want. Vista does not change the "administrative password" requirement and
UAC's requiresAdministrator may even make an administrative password even
more necessary.


>
> What you are really wanting from Windows is to have more control over the
> user's privileges. SUID allows this, but muddies everything up in the
> process, because it breaks the design of the system.
>
> As an aside, this privileges flowing from the user is also the same thing
> I
> was getting at with services vs. applications - If the user interacts with
> a
> service directly through a UI or whatnot, the user is in essense granted
> all
> the privileges of SYSTEM when working with that UI. This is incorrect
> design,
> and why Windows makes it as difficult as possible to do. Services are
> privileged so that they may provide services consumable by the user thru
> applications, because services provide services and applications are the
> means by which the user uses their privileges to consume services.
>
> Trying to re-implement this built-in seperation of privilege (program vs.
> operating system/service) is possible inside of an application (an
> application that limits privilege to the user but runs internally at high
> privilege, as in the case of one certain class of SUID apps), but why go
> through all the trouble of breaking the windows architecutre in this way,
> running the risk of introducing nasty security bugs/vulns, and
> re-implementing something Windows has already done for you?
>
> <snip>
>> Executing a specified application should be a privilage
>
> It IS a privilege. Having read access to a file does not give the user
> execute access, this is a sperate privilege in Windows too. Windows
> actually
> has a much richer privilege/security architecture than does *nix.
>
> <snip>
> (Talking about running SUID progs and the user not having the permission)
>
>> Sure they do, the right to "execute" the specified application, which
>> must
>> be granted by the administrator.
>
> You're right, I see what you are getting at now, and have addressed it
> above.
>
> My point here was that the person using the computer is in the eyes of
> Windows one user defined by their user account, and that technically its
> an
> elevation of privilege when another app is run with higher privileges than
> what the user account has access to, even though it works out the way you
> want it to.
>
>> Yes, exactly. SUID provides a method for the administrator to GRANT the
>> user
>> a "custom privilage." The problem with windows to date is that the user
>> cannot be granted a privilage such as "member of administrators group"
>> without also granting the user every privilage that comes with it in any
>> way
>> he feels fit to use it. If it were possible to constrain other
>> applications
>> from using those permission then it would be effectively nullifed except
>> for
>> the desired application.
>
> You're right, and I agree with you. But Windows deserves something better
> than SUID .

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

>
>> LOL, took me a second, but good point.
>> Rather what I meant was that only the OS needs permission to read the
>> file
>> into memory for execution (and backup software for recovery purposes);
>> the
>> user should not be able to run a disassembler or even copy the program to
>> another location. Read and Execute are completely seperate permissions
>> IMHO.
>
> Read and exec are seperate. I understand what you mean here, though - just
> because a user can use a program to read/use certain files, doesn't mean
> the
> user should be able to read/use those files from another program.

They are seperate but (no longer) independent permissions. If you grant
"execute file" permissions you must grant "read data" permisison or execute
fails. This appears to be a change in Vista, I retested it on my XP64
machine and it works as expected.

>
>> The USER, as you just pointed out to me, doesn't do anything. The user
>> is
>> not the one loading the program into memory, not even windows explorer
>> actually does that; windows explorer basically just instructs the windows
>> kernel to load and run the application.
>
> But the user is initiating the action - that is what I am getting at here;
> the person at the other end of the screen in ACTUALITY is the one who has
> the
> privileges that are assigned to the programs they run; to pretend as if
> this
> were not so by assigning programs to run in a hodge-podge of different
> user
> accounts is a poor solution.
>
>> As far as other resources are concerned it gets a bit more complicated,
>> how
>> do you determine if the program has the ability to load other
>> "application
>> owned resources." I have a technical solution to that as well. When the
>> kernel loads an application it links the users security token to the
>> application so that when it receives a request from the application to
>> perform such and such it can check that the associated user security
>> token
>> has the necessary privilages. The kernel could instead link the
>> application
>> to an "application security token" and link that to the user security
>> token.
>> The application security token would basically fine tune the users
>> security
>> token. Most often the application security token would be used to
>> further
>> restrict the user security token basically granting the application the
>> intersection of the applications permissions and the users permissions,
>> application owned resources however would be the exception rather then
>> the
>> rule in this case the application grant the additional permisisons to
>> those
>> resources. The .net framework has a final attribute that basically
>> ignores
>> what is specified at a lower level policy effectively turning off the
>> intersect behavior,
>
> I agree, this functionality should be available. I have even suggested
> this
> same thing in an earlier thread in this forum .

I am all for this kind of security model and would find SUID much less
necessary if such a model existed.
However my concern is that it is conciderably more complex and I don't think
it will happen anytime soon in any truely usable form. And if Vista is any
indication, I'm not going to hold my breath. SUID seems reasonably simple
to implement even if it is a hack. I think MS is simply in denial that ANY
security model could be effective when the user must know the administrative
password.

>
>> the same sort of thing could be used in the application
>> security token to explicitly grant the application the necessary
>> privilage
>> to the application resources overriding whatever is specified by the user
>> security token,
>
> This should never be necessary, as it doesn't make sense. How can an
> application in the control of a user be able to do something that the user
> can't do?
>
>> Such a security model would practically eliminate the need for UAC
>
> Well, it would certaintly change the behavior of UAC. UAC allows the user
> to
> choose how much privileges an application has. A user (or an admin on the
> user's behalf) would still need to look at what privs an application is
> requesting and approve/deny them; also, a user may still want the usage of
> certain privs to prompt for consent, and there would be cases where an app
> with lower-privs wants to start an app with higher-privs, this would
> require
> consent.

UAC is borderline anoying in its current form, I would rather not be
prompted for 90% of what Vista prompts me for. Many administrative tasks
already prompt Are you sure? after pressing OK. I shouldn't even need to be
prompted if I haven't even done anything yet. UAC is only mildly useful
because MS can't otherwise prevent non-administrative applications from
having administrative privilages nor ensure the physical user actually
requested the action when an administrative application is run. A better
security model would prevent less privilaged applications from launching
privilaged applications in the first place. If each process had an
application token and that token did not provide a privilage required by the
process it is trying to create then prompt the user for concent. UAC is a
hack. Windows deserves better!

- Kurt

>
> - JB

Hi Jimmy,

> In the context of apps that *should not* need admin permission but
> require it anyway, I disagree - UAC is designed to deal with these apps,
> by both working around legacy apps that do this (virtualization)

But it's the wrong solution for the wrong problem.

> and
> making it much more painful for developers to create such programs.

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

The case of virtualization is always wrong, and Microsoft state in the
Vista docs that this is an INTERIM solution with no future. It's
actually MUCH worse. If a home user wants to leave it on then fine, but
if any business if thinking of leaving virtualization turned on they are
fools - plain and simple. Look at the HKCU's if you don't believe me.

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

But not as much as a motivation as if their app simply said "Access
Denied", which is what it should say, but Microsoft were too half-baked
to write a business class o/s (for the fifth year running).

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

Exactly.

And Vista means this idiotic practice will continue for another five
years because of UAC. It will still encourage bad practice.

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

It's simple, users run as users, Administrators run as Administrators.
Except on Vista, it's not simple, they all run as each other and it's a
total mess.

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

It's absurd if users can change the clock. They could end up wrecking a
differential backup or cause all their program licenses to suddenly
expire. They should be locked out of the clock, only Admins should be
able to change it.

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

I agree, this is the whole issue. Microsoft have done it completely back
to front. It's the worst design you could possibly have, it breaks the
fundamental best practice of users running as users and Admins running
as Admins.

--
Gerry Hickman (London UK)