Comments

billswift • February 19, 2007 8:29 AM

From the description on zdnet this doesn’t look like a tradeoff so much as a sacrifice of security for ease of use. Or is that what you meant by a “bad decision in this regard”?

Andrew • February 19, 2007 9:04 AM

Is it bad? Installing software is an admin function and needs an admin password. I think allowing an unprivileged installer to “add a directory under program files and a few registry keys” would create a lot of vulnerabilities – particularly if you could identify one program that might be used by another if present.

There would be some value in having a kind of “sandbox” for installing programs that other applications would see as “unprivileged” and therefore know not to trust, but that would entail substantial extra complexity, and make for a great many support headaches.

Do any other operating systems have such a sandbox mechanism? All unix-like systems I am familiar with require root privileges for package installation, and also allow the installer to perform arbitrary system actions.

I’m all for bashing Microsoft whereever there is reasonable excuse, but unless I’m missing something this policy isn’t one.

Dave Page • February 19, 2007 9:04 AM

billswift – a sacrifice of one thing for another is what is meant by a “tradeoff”.

It’s a bad tradeoff in this instance since even if you want to run installer programs with higher-than-normal privileges (rather than doing the Windows equivalent of using $HOME/bin), you don’t want them running with the highest possible privileges, which is what UAC does. Windows 2000 (and I believe XP) supported a “Power User” set of privileges which allowed access to “C:\Program Files” and editing part of the registry tree.

Matt Palmer • February 19, 2007 9:25 AM

@Andrew,

yes, it’s pretty bad. Installing software should require higher privileges than a normal user account, but should not require permission to do anything at all on the system! Given that UAC was supposed to be about moving Windows to a Least-Privilege model, it’s somewhat ironic.

Right now, UAC appears to be about passing the buck, much like code-signing for ActiveX was “You clicked OK – it’s your responsibility”. The average (or even skilled) user has (a) no way of knowing who to trust really and (b) even if they do decide to trust it, why should that installer be able to do anything at all in the first place?

Just saying that it’s about as good as ~40 year old basic unix security isn’t terribly convincing for an operating system in the 21st century sold as being secure. Anyway, unix at least allows for more complex sandboxing of applications in general and does not require root access for many tasks (it’s quite configurable, if your distribution or sysadmin makes the effort).

Candide • February 19, 2007 10:13 AM

@Andrew:

Do any other operating systems have
such a sandbox mechanism? All
unix-like systems I am familiar with
require root privileges for package
installation, and also allow the
installer to perform arbitrary system
actions.

Most packages I’ve encountered can also be compiled into and run from subdirectories of ~user, provided there is the appropriate mangling of environment variables at compile-time. This means that I can have per-user installations of software: a common trick for testing updates. By not putting these programs into the path, they aren’t accessible by other programs unless the other programs are REALLY trying.

wm • February 19, 2007 10:17 AM

Drat — @Candide beat me to it. I was just in the middle of composing the following:

@Andrew: “All unix-like systems I am familiar with require root privileges for package installation”

Well, it depends on how the package has been built. If it’s going to insist on writing to /bin or somesuch, then yes, it’ll need to be root. However, some packages allow you to choose at install time where to install to. For example, I’ve installed the Java SDK and Adobe Acrobat into my home directory using only my unprivileged user account before now (this is on a GNU+Linux system).

You can do the install as root if you want, but if you don’t want to trust the installer (or don’t have the root password), you can install them without root privileges and it works just fine.

Terry Cloth • February 19, 2007 10:21 AM

@andrew: “All unix-like systems I am familiar with require root privileges for package installation….”

I’m not clear on what you’re saying. On Unix-ish systems, I can install anything I want in my home directory, from my own shell scripts to games and databases (mentioned by @Dave Page above), using my own privileges, and the danger is no more than that of any other exploit against my account. While not a great situation, it’s far better than a binary choice of root or nothing.

If, as it sounds, that’s not possible in Vista, it looks as if it has discarded a useful intermediate security choice. Am I missing something here?

Bob • February 19, 2007 10:27 AM

The zdnet article is missing the point a bit. This isn’t just about installers.

To quote the original researcher: “True, I also don’t like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but I can understand such a design decision (as being a compromise between usability and security)”.

The kerfuffle here, is that Mark Russinovich has said that “both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use” … “elevations and ILs don’t define a security boundary”.

i.e. UAC was never meant to be a security mechanism, as holes were permitted as part of a usability trade-off – obviously mechanisms with such trade-offs are not security mechanisms.

This kinda contradicts Vista marketing.

The truth is UAC is designed to make running as a limited user more practical, and to coerce software developers into writing apps that behave in a restricted environment.

UAC will stop current malware that doesn’t know to circumvent it, providing an initial illusion that UAC has fixed the malware problem.

Once everyone has adopted Vista and software is more friendly to running in a restricted environment, Microsoft will be able to implement real security boundaries without breaking too many things.

Greg • February 19, 2007 10:45 AM

OK a little OT but maybe not. read to the end.

Well the linux package system for all pratical considerations really needs root.

I man at work on a machine i do not have root on. Trust me its a real real pain. Since most rpm/whatever assumes a fixed install location and root privilages that what you need to use them.

Ok so now compile them…err need to install missing dev libarays. etc

Buy the time you jump through all the hoops you need a local gcc installation (almost) and it takes ages to configue some autoconf build tools to work with libs in nonstandard locations.

Over all the package system on linux works well if you have root and have a good internet connection.

This restricts usablility quite a lot. I can see MS losing a lot of customers if they needed to go thorugh the same fisasco that I do to install common apps in user space on linux. What do they want more? Reputaition of securty or lots of sales?

I was the admin back in NZ. Now I have no root access (and choose not to hack it) Linux can be quite a pain.

Note there are exceptions. Blenders binary tar ball , and autopackage (as used by Celestia) seem to work well.

JakeS • February 19, 2007 10:56 AM

I hope Bob is right that this UAC mechanism is a stepping stone to real security in the future.

I take only a remote interest in all this because I’ve no intention of even looking at Vista (for business or pleasure) for a year or more, probably until the first service pack is out.

But this story does sound as if MS still doesn’t get it. In a properly-designed operating system, there should be no reason for a user program’s installer to require privileges that enable it to overwrite the OS code. Yet this is routinely the case in every desktop Windows release up to XP, and apparently in Vista too.

Zwack • February 19, 2007 11:04 AM

Having worked with a “Compartmentalised Mode Workstation” running HP-UX 10.16 (Which was never officially released) there are systems where least privileges are required for installing software.

Software is installed in a CMW at the lowest possible security level. In addition it is assumed to have no privilieges. Then a user (the Security Officer if I remember correctly, it’s been ten years) has to go in and give that software the minimal privileges that it requires to do it’s job. The good thing about this is that as you can’t write down to a lower security level (unless you have the special privilege to do that) then anything running at a higher level (everything) can run those programs but can’t modify them.

Of course CMW can be a real pain in the butt to use productively, but it does have precisely the kind of administrative compartmentalism that Andrew was asking for.

Oh, and it’s not a “sandbox” it’s the OS.

Z.

sooth_sayer • February 19, 2007 11:11 AM

Can we put some of these guys in their sandbox?
And please stay away from talking linux too .. clearly folks like andrew and some of his critics are even more clueless.

Pat Cahalan • February 19, 2007 11:19 AM

@ bjimba

What I find most interesting here is that it looks like Russinovich drank
the kool-aid, after all.

Yeah, it’s too bad. This is the sort of thing I expected Mark to harp on when sysinternals was independent. Essentially he’s correct, this is a portability problem, and from a strict business standpoint I can see how Microsoft made the decision to default UAC this way.

But this: “Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs.”

That’s just not the old Mark.

Zwack • February 19, 2007 12:17 PM

@Matt Palmer

“Installing software should require higher privileges than a normal user account, but should not require permission to do anything at all on the system!”

Why?

A normal user should be able to create new files. so should an installer. A normal user should be able to create directories so should an installer.

A normal user should not be able to modify the operating system nor should an installer.

There are one or two functions that an installer might require on a given OS, but the OS should define a mechanism to safely grant those functions. On a windows system an installer might need to be able to write to the registry. For a normal user such writes should be limited to a section for that given user. For an installer they should be limited to a section for that given application. Assigning privileges to a program is the one place that the installation mechanism might need to have some special privileges, but do you want to assign privileges to a program or to a user?

For example, a web browser requires network access to be useful. But if you have a user that you don’t want accessing the network then would you want them to be able to get around that by running a web browser? An alternative approach might be for the user accounts to have capabilities and the programs to require the account running them to have a requirement for certain capabilities in order to run. The ideal approach would be a combination of privileges and capabilities. The web browser has the needed privilege to access the network, and the user running it has to have the capability. The solitaire game does not need the privilege to access the network so it doesn’t matter if the user has the capability or not.

The installation program could simply pass a request to the OS that explicitly asks for privileges. Depending on the system that request could be handled in two ways:

1) A pop-up that asks the user installing the software to confirm that the following capabilities make sense for the program (possibly incorporating an explanation from the programmer). This assumes that the user will make the right decision, but a user could be banned from granting any privileges that they don’t have matching capabilities for.

2) The request is noted and when a “security officer” is available they are asked to confirm the privileges. This assumes a more controlled environment.

As usual, balancing security and ease of use is a complicated issue.

Z.

LazyProgrammers • February 19, 2007 1:11 PM

@Bob
“Once everyone has adopted Vista and software is more friendly to running in a restricted environment, Microsoft will be able to implement real security boundaries without breaking too many things.”

I agree with your point, and I hope this is the track Microsoft is taking. I suspect Microsoft made this “tradeoff” in response to too many problems with poorly written applications/installers.

There are numerous articles (i.e. Raymond Chen and others) about how Microsoft has to “bend over backward” with every new OS release just to ensure compatibilty with existing, poorly written applications (aka lazy programmers).

I have to think this tradeoff was the result of having to again “bend over backward” to ensure certain installers written by lazy programmers would still work in Vista. For example, programs like QuickBooks have, for no understandable reason other than lazy programmers, needed full admin rights on protected areas like the registry root, for many of its most recent revisions.

JakeS • February 19, 2007 1:23 PM

@ LazyProgrammers:
I’m sure you’re right, but shouldn’t MS then have shouted out loud, long in advance, that they were not going to bend Vista over backwards, and that lazy programmers would have to adapt or die? It took them long enough to produce Vista, after all.

Z • February 19, 2007 1:34 PM

@JakeS
Well, they’re already breaking a lot of apps with UAC as it is. It’s just that the virtualization resucues the apps right now.

I’m all for Microsoft shouting at developers to adapt or die because people are usually lazy and re-working old code can be messy depending on the application.

/side rant
Exhibit 1 in laziness: Device drivers for Vista
/end rant

Timm Murray • February 19, 2007 1:50 PM

Does the registry have any sort of internal security model?

In Unix, with enough effort, you should be able to make sure installers have access only to what their most likely to need. For instance, they can have write access to /etc, but not to /etc/inittab.

In theory, Microsoft could build an internal security model for the registry that’s superior to the Unix model, since the Unix model is a general filesystem security system, and the registry model would be just for the registry.

However, to my knowledge, that system doesn’t exist. An installer that has access to write to its own registry keys also has access to every other registry key on the system.

Aaron • February 19, 2007 2:37 PM

@Zwack

It sounds like you’re asking for exactly what linux already requires. If I’m an average user on a system who wants to install something – I can’t, unless I get someone with root access (presumably aware of security implications) to do it for me. If the people with root access aren’t trained to make these decisions, that’s a social and organizational problem well outside the purview of the OS itself.

Lourens Veen • February 19, 2007 2:46 PM

Wasn’t the XO (the OLPC laptop) that was linked to a little while ago supposed to have such a sandbox system for external applications?

Woody • February 19, 2007 3:00 PM

@Timm Murray

“Does the registry have any sort of internal security model?”

My experieces are with NT/2K/XP, and they use same kinds of ACLs as the filesystem does.

Different parts of the registry have different privs. It’s very much like the /sbin, /bin, /usr/bin, /usr/local/bin setup in ‘nix.

I’m amazed that they think that all programs need to be installed by root/admin. I primarily run OSX. I don’t have to be admin to install anything, but a “standard” OSX app is just a directory of executables and resources plopped into a folder. If I don’t have permissions to do anything, when I run it, neither can it.

Worst case I can see is that I can install something, and then later with admin privs execute the app, which elevates it’s privs.

And that seems like what they were trying to stop from happening with this, that a low-privelege app couldn’t ever execute with elevated privs.

But the installer path is a massive hole…. Having previously written installers for win32, you can do some really nasty things in an installer (to the system).

The movement of the installer away from a coded system (the old installshield method) to a more database driven setup (msi) is a big step forward for security, as you can do a static analysis of the msi to determine if it will need elevated priviledges for install, and if so, what it’s trying to do.

Then they could something akin to the OSX model for security. “Application Foo is asking permission to read your key, type in your admin password to allow this: don’t allow, allow once, allow always”

wumpus • February 19, 2007 5:40 PM

I’m pretty sure SELinuix (and Fedora should be a pretty big name in Linux) can avoid this issue. Normally, linux either requires a sudo apt-get, sudo rpm -i, or su-./configure-make-./install.

I have no idea how windows could get around this issue (thus they won’t see any problem with users giving programs admin powers to see “nakedbritany.exe” run or other such foolishness. As long as you give a program arbitrary powers to modify the registry and spew files, replace dlls, and all the other things considered necessary for a windows install, you are going to require admin privleges.

I just want to see a linux system work without this wide open hole. Its one of those things were desktop security issues are completely different from server models. The biggest security hole is between the keyboard and the monitor – even for the case at home were the user has root.

Wumpus

Thomas • February 19, 2007 8:55 PM

“””How Vista recognizes installer executables? It has a compatibility database as well as uses several heuristics to do that, …”””

So a process guaranteed to have errors will be used to underpin a major security ‘feature’.

  1. UAC becomes inoperative (either becuase it’s disabled or because everyone just clicks OK)
  2. program is misidentified as an installer.
  3. program is automatically upgraded to superuser
  4. hilarity ensues

Lawrence D'Oliveiro • February 19, 2007 9:41 PM

The basic difference with Linux is that you don’t usually run proprietary installers put together by Tom, Dick and Harry. Instead, the distro maintainers take the source code and build it into the appropriate package format for the distro, and the users just invoke the standard distro package tools to download and install that package. This gives a lot less chance for trouble.

Of course, this can’t be done for closed-source software. Too bad.

Frank Bough • February 20, 2007 1:53 AM

…what suprises me is the recent and continuing anti-microsoft sentiment on this blog — has someone turned in to Slashdot wihtout telling me?

Student • February 20, 2007 2:47 AM

If we look beyond obviously malicious installers there are also the installers that are simply badly written and can still take down systems. Writing a good installer is not easy, and there have been some very nasty bugs in them. I remember being burned by the installer to a game (It might have been Myth 2) many years back. It installed fine, but when uninstalling it deleted the directory the application was installed in. Now imagine that you happen to install in Program Files and then remove the game…

I don’t think it would be exceptionally hard to make sure applications can be installed without administrator rights. Very few applications needs to do more than create a directory (in program files), get write access to it, create a registry folder, get write access to it and insert a few dll files. All of this could be done in a secure manner. If Microsoft wanted they could also bind the application so it does not get write access outside its home directory unless it goes through a special API/is installed by the administrator.

The main problem is that they build Windows to be compatible with a huge amount of old and badly written applications. If they ever are to actually get it secure I imagine they will have to go the same path as apple did: Create an emulator for old software and start over with a completely new OS where they can design things after modern security demands.

Matt Palmer • February 20, 2007 4:28 AM

@zwack:

I don’t dispute pretty much anything you say, but I stand by the fact that a normal user does not need permissions to install software. The fact that they can install software locally to their home folder without needing any kind of permission would be a weakness of the model or its implementation.

My argument is simply that in a least-privilege model, when I’m creating documents, spreadsheets, browsing the net and sending email, I don’t need to be able to install software. I certainly shouldn’t be able to run files I’ve downloaded into my home directory without having a permission to execute assigned to them (an installer could do this, but why would a normal user account need to do this).

I am also interested in capabilities as another access control mechanism – security by reachability. Also a least privilege model where programs need to be authorised as much as user accounts do. Thus, even if malware breaks in, there’s not much it can do by default. Whether a particular model would allow a user to do “more” than their user account allows seems a bit moot. If you have rights to execute the browser, you have (by proxy) attained the rights of the browser while you are using it – but there’s no need to give a user all the permissions that a browser requires, and vice-versa. I can also see circumstances where both principals would have to have a right in order for it to be exercised. Depends on what the requirements of the security model is.

Matt Palmer • February 20, 2007 4:30 AM

Ooops – that should have read “a normal user does not need to hold permissions to install software” – meaning that the act of installing software should be controlled (or the ability to execute arbitrary files that are created), and that they don’t need them in normal operation.

Jojo • February 20, 2007 4:42 AM

I don’t understand M$’s belief that only admin’s should be able to install software. What value is this premise? Surely M$ doesn’t think that everyone running admin knows what they are doing? And even if you do run admin, you really don’t know what an install program is doing unless it tells you. If a rouge program wanted to “forget” to tell you about something it is installing, 95% of the people running admin wouldn’t know how or don’t have the tools to tell them what actually got installed! (and probably shouldn’t have to know).

The real problem is M$’s poor design of Windows. It is criminal to let ANY user program install into system folders or the registry uncontrolled. User code should execute in its own locked space and should not be able to (or need to) get system level rights.

JakeS • February 20, 2007 6:09 AM

@Frank Bough “…what suprises me is the recent and continuing anti-microsoft sentiment on this blog”

I don’t see a big proportion of anti-Microsoft sentiment here, unless you have fallen for the political spin that says that any criticism of anything that Microsoft (in this case) does is “anti-Microsoft”. Of course there are ideologues here who seem to hate everything that Microsoft is or stands for – apparently simply because it’s so successful. I think they are fools (they probably think I’m a fool). I’ve spent a lifetime in computing, and used more operating systems than I can remember. I use Windows every day. It’s precisely because of my experience that I can pause every now and then and admire what Microsoft have achieved in Windows. I think it does what it does pretty well on the whole (and so do OSX, Linux, and others, but this isn’t the place to go into why I prefer to use Windows). But it’s also precisely because of my experience that I can see that, despite Windows being a good thing in general, some of the basic design decisions were not clever. If pointing that out is “anti-Microsoft”, then so be it.

C Gomez • February 20, 2007 12:18 PM

I can see the “hacker’s” point.

It’s actually good to get this knowledge out there. The thing is, some installers DO need a high level of privilege to get things done that a user might want them to do.

Others don’t.

I think what I would want to know is how sound is this “detection” mechanism for installers.

I could, with a little work but not herculean effort, write a piece of software with no installer whatsoever (and really, most software can do this if you are purely just a piece of software, not a printer installation or something). When I run, I can check for application settings and upon not finding them create a set of default ones and run the app. This can be done for a simple Tetris like game that is brought up in the example.

Now, here’s the question. Write the app in this fashion, then test it out… does it trip this “heuristic”? If yes, then that is too bad. If it doesn’t, then there’s no problem.

Before Vista, .NET security gurus like Keith Brown said “strive for a power user install”. I agreed and did try for that. Sometimes, however, you just gotta write to Program Files or HKEY_LOCAL_MACHINE. And I may only want those privileges.

Even the simple Tetris game has this issue. I might want to put the software in Program Files so all users can run it (even if I have to detect they have no local user data and create it). Can’t do that by default without an elevated privilege (unless Vista has changed this from XP).

MSFT clearly made a tradeoff here, and they seem to have erred on the side of grandma being able to install an application without wondering what she just got asked. In the end, this is still better than the “current world”, where most users (home, work, business, whatever) run as admin and you are already letting every program on your system run as admin.

We have to get users of all kinds to stop running as admin. Hard to do and requiring lots of careful coordination. After all, H&R Block’s TaxCut 2006 software just told me it REQUIRES admin privileges to run. I have complained and will strongly consider not using them next year. They need to do their part and the only way they’ll listen is to lose sales because of it.

LazyProgrammers • February 20, 2007 12:41 PM

@C Gomez
“…H&R Block’s TaxCut 2006 software just told me it REQUIRES admin privileges to run.”

Argh. More Lazy Programmers. There is no reason that tax software would ever need to run with admin privileges.

This is just another case of lazy programmers, like those responsible for the QuickBooks fiasco. Although, I understand that Intuit finally figured out how to write software with their latest revision of QuickBooks… it only took them about 7 years to figure it out!!

Pat Cahalan • February 20, 2007 3:21 PM

@Frank Bough

Role-based access control is something that we should all agree is severely lacking in operating system design.

Everybody talks about it, but it is difficult to implement for any number of reasons, most of which are business-process related.

This thread illustrates a specific example of a general problem.

X the Unknown • February 21, 2007 10:07 AM

@JakeS: “…shouldn’t MS then have shouted out loud, long in advance, that they were not going to bend Vista over backwards, and that lazy programmers would have to adapt or die?”

As I recall, Apple once did just that, in the distant past, as it was upgrading one of its versions of MacIntosh’s “Finder”. Not only were many (perhaps most) of the problems that ensued caused by their own programs, but the whole affair was such a disaster that the burgeoning popularity of the platform was severely tarnished for a few years.

Given a concrete historical example, if MS executives made the same decision and didn’t manage to pull it off smoothly, heads would surely roll. The personal risk is just too great for most decision-makers to take – especially given MS’ longstanding tradition and reputation for backwards compatibility.

I don’t know about you, but the vast majority of my software investment is NOT the O/S. I have spent mucho dinero on the various applications I use daily. If shifting to a new O/S means I can’t migrate my existing applications easily (and some are no longer supported – such as Office’97, which otherwise works just fine, thank-you), then the effective cost and barrier to entry for that O/S becomes that much larger.

X the Unknown • February 21, 2007 10:29 AM

One of the nice things about the UNIX $PATH variable (and, to a lesser extent, its Windows derivative) is that it is configurable on a per-user basis. Way back on UNIX v6 – and ever since (and probably earlier) – we put different types and classes of executables in different directories. Since each directory can have its own set of permissions, it’s no big deal to give different “group” permissions to different directories. Allowing users to install in some directories, but not others, creates an automatic “hierarchy” of trust-levels.

If you don’t trust programs that have been or can be installed/modified by other users (or even yourself), then just don’t include that directory in your path – and definitely put it lower in precedence than the canonical directories such as “/bin”, to avoid masquerading by executables with similar names. Of course, the big problem with this already-existing mechanism is that “joe user” needs to know too much about general system functionality and organization to easily/safely make use of it. Thus, “installers” and “packages” developed – which tend to expect a rigid filesystem hierarchy and appropriate access rights (often requiring running as a privileged user). sigh

Windows claims to differentiate between the permission to Create and the permission to Modify. As an old UNIX fan, I never saw the need for the distinction, until recently. But, it is obvious that this distinction is ideally suited towards giving installation permission, without allowing modification of other existing files. I suspect that one reason it hasn’t been aggressively used this way in Windows, is that it doesn’t work very well for uninstalls (but an ACL created at install-time that recognizes the uninstaller would solve this), nor for the ever-requisite updates.

Zwack • February 22, 2007 7:57 AM

@MattPalmer

I’m still not sure why you think that installing software is somehow different from any normal task that a user might need to do. The one point I hadn’t thought about is specific to certain security models, but is not a general point.

So, an installer needs to be able to create files and directories. A user also needs these capabilities.

An installer should not need the ability to overwrite pre-existing OS files. Neither should a user.

The other tasks an installer might need to undertake are specific to given OS and security models and those could be protected against. Writing into some kind of system registry and making files executable are the two general things that I can think of. There are specific users who might need these capabilities, but a generic “user” shouldn’t. But these tasks are specific to particular security models, a basic installer unpacks, copies or creates some files, and it’s done.

Z.

LazyProgramerII • March 4, 2007 8:42 PM

Some of the concerns elevating setup programs to Administraor is ameliorated by WRP. eg program will change OS bits.

But the main reason Microsoft elevated Installers to Administrator was becasue many of its own applications break on Vista. Look at the number of programs they had to update so it would work on Vista – including office, VS, msde… Think Microsoft has more than its own share of lazy and bad programming practices to be pointing to rest of the programming community.

How tough would it have been for Microsoft to create a InstallerUser Account and providing it with just the needed permission to install programs and Elevating Setup to that account. If it tried to do more – then provide a warning to user that setup needs to run as administraotr – let the user know that now he is on his own and should only do this if he trusts the source completely.

Then atleast people have a choice – if they are installing something cool from internet but its setup wants more access than InstallerUser – at least then they can weigh risk – do I really want this cool thing badly enough and risk opening my system to it. Or I can pass on it. Atleast XP allowed me the capability to configure my system in a way that I can achieve the above.

On another but related note – I am more worried about my data being stolen than destroyed – cause I keep backup. XP allowed me to run IE under another very limited user account using RunAs so that I could protect my valuable data from being stolen and sent to some oversee’s location. Now you cannot use IE with RunAs on Vista.

Forcing things on end-users is not a good idea – give choices. Including AV vendors. There are smart people outside Microsoft who know a thing or two about security too and how to protect system.

There are security features in Vista that was not fully baked thinking. Definately people are going to see better security on average for the current set of threats but there are people who are looking at next generation of exploits. And by introducing things that tie other security professionals hands – its a disaster waiting to happen.

C Gomez • March 6, 2007 3:32 PM

“But the main reason Microsoft elevated Installers to Administrator was becasue many of its own applications break on Vista. Look at the number of programs they had to update so it would work on Vista – including office, VS, msde”

Very true… and there is no excuse. Many installers do not need special privileges. They might need access to C:\Program Files and that’s about it. I know that’s what I strive for. I try not to create user settings until first-use, so that they can go into per-user safe areas.

It was once said, strive for a Power User install and a Guest run. Power User is gone in Vista (and I can’t comment on it as I have not installed it, yet), and that may have been an unnecessary abstraction anyways.

Sometimes, an installer does need advanced privileges. The simplest examples I can think of is that installers might need the ability to write to C:\Windows\System32, C:\Program Files or HKEY_LOCAL_MACHINE (make all reasonable assumptions for that statement to be true, please).

However, once installed, per-user data can be stored in the appropriate areas, and you don’t need elevated privileges for those.

What I am most concerned about is how MSFT determines what is an installer. It sounds like magic. Still, if we’re warning the user an install is taking place, it should be obvious to the user “Hey, that’s weird. I didn’t think I was installing anything,” and stop.

The problem here is that users click Yes at all costs if they think it helps them get their work done. So it’s a little damned if you do, damned if you don’t.

Users don’t want to (or don’t know how to) run as non-admin. Competent professional programmer friends of mine say ‘it’s too hard’. I think it’s not hard at all and has kept me malware free for many many years. But I will also admit it is NOT easy or trivial for “Grandma” to do.

So I credit the article for pointing things out, but if a user really wants to run something, no security procedure in the world can stop them. And the alternative is be so obstructive to running said process that I get frustrated and blame Windows. “Arrgh, Vista sucks! Why did they make this so hard, it used to just work!”

I do think I should be allowed to run a process with the privileges I want it to have… meaning… if I want to run an installer with Guest privileges and watch it not work, that’s my choice, too. It’s my computer.

Anonymous • April 12, 2007 6:16 AM

It’s usually the ones who know little so willing to give opinions. Nothing is perfect, different people demands different things.

Ron • May 11, 2008 12:59 AM

UAC in Vista is a joke, information is power and with the UAC you do not get enough information. Look at a commom UAC prompt “An unidentified program wants to access your computer” and the name of the program. You click on “Details” and all you get is the path and executable name. To begin with with so few details why even have the “Details” button, why not show the details all the time? Second of all Windows should know when the user double clicks on a link to start a program, so why ask if I want to run the program, if I didn’t I wouldn’t have clicked on the icon. The UAC is just an illusion of security.

What the UAC should do is tell you things like a program is setting itself to start automatically at startup, but it doesn’t do that, once you say it is alright for a setup program to run the setup can do whatever it likes without any UAC prompt.

For an example I recently installed Nero 8 on Vista with UAC on. It prompted for the setup to run, during setup Nero set 3 program to auto start with Windows, without the setup telling me or UAC. After unistalling Nero the 3 programs set to suto start were still there, I had to remove them manually through registry.

Stuff like that is what causes winrott and malware. All the UAC does is ask when you double click on something are you sure you wanted to, not much else.

The UAC I guess could be called a start but barely a start, there has been better security software on the market for years such as ZoneAlarm which monitors additions to startup section of registry and keyloggers.

Viruses can be spread with UAC just as easy as without, simply use an installer, the user gets prompted is it OK, they don’t know its a virus so they click yes, and the installer installs the virus, sets it to start automatically along with 20 other viruses and malware. UAC is an ilusion and a waste of all of our time.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.