The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Big security hole in Vista?

Roman Werpachowski Send private email
Wednesday, February 14, 2007
 
 
Where do you draw the line though.

Tetris needs a new folder in Program files and a few reg keys. My program would not install with those rights.

The next program also needs an ODBC connection.

The next requires access to the all users folders.

How about shared components.

You can't ask users to differentiate all these levels. They complain enough about two levels.
Adrian
Wednesday, February 14, 2007
 
 
Man, are these people stupid?

In a corporate environment, users will not be able to raise their permissions to install software…plain and simple.

If a user is going to install software, then what much can you on in the realm of security? If you don’t know what that software does when you install it, how can there be any security?

This issue is rather silly. Vista simply asks users do you want to raise your permissions to install some software. If a user is going to install software on their computer…what much can you do at that point?

Like I said, for most corporate environments, users will not be able to raise their privileges to install stuff. I can’t see any operating system getting around this problem at all.

Further, users at least during REGULAR daily use of their software are NOT running as admin users. This users level has been a sore point for many people who complain that windows users are running as admins.

So, vista is clearly a step in the right direction.

This all centers around do you want to allow users to install software, or not. Vista could have forced users to log off, and then log on as admins every time they needed to install something, but that would have been a ROYAL PAIN.

So, the UAC simply makes running as a non admin during the day a “reasonable” setting on your computer.

To tell me that the fact that vista now *CONVENIENTLY* allows users to run as non admins during the day is not a step in the right direction is absolute stupid.

Once that software is installed, you don’t have admin privileges, you don’t have complete registry access, and communication is still fire walled in vista.

It is rather laughable to come back and tell me that after all these years of people complain that we should not run users as admins…now, we are being told it don’t matter?

These people are brain damaged….plain and simple…

The UAC does NOT herald in a new era of security, it is simple change (one of many) things that allows you to run a computer at a increased security level for most of the time without going crazy.

I am at a loss at to what system would ever prevent that problem?


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Wednesday, February 14, 2007
 
 
Agree with you there Albert, that entire piece read as Anti-Microsoft Anti-Vista.

Here is something interesting, found a user that had installed FireFox on their workstation.  Using their limited user account.  How, they just pointed the FireFox install directory to their own documents folder on the server and presto it installed.

So did I miss configure security on the network?  I don't think so because if I used the default c:\program files\ folders then it would not installed, since it needs admin rights to install files there.
Lee
Wednesday, February 14, 2007
 
 
Installation seems to me to be an inherently administrative task.  Unless they require installers to explicitly request a set of rights that get displayed to the user in the  UAC dialog (which they probably won't read or understand anyway), I don't see much way around this and still retain usability.

As mentioned above, in business environments, user accounts are going to be locked down so they can't elevate anyway.

It seems like it is sufficient enough to say "You are about to run a program that could do evil violent things to your system.  Shall we proceed?".
Dan Fleet Send private email
Wednesday, February 14, 2007
 
 
"Installation seems to me to be an inherently administrative task."

I think maybe you are not getting the point.

In Mac OS X I can install applications without administrator or elevated rights. I install it right in my own Applications folder in my home directory and the program gets to modify ABSOLUTELY NOTHING in the system, not a registry, not a system folder, not even a universal applications folder used by all users.

An administrator could move my application to the /Applications folder if all users should be able to use it.

"In a corporate environment, users will not be able to raise their permissions to install software…plain and simple."

No, plain and simple would be if the user doesn't jave to raise their permissions to install software.

"If a user is going to install software, then what much can you on in the realm of security? If you don’t know what that software does when you install it, how can there be any security?"

That's the point exactly. The security has nothing to do with what the applications wants to do, only with what it can do. The user has certain permissions, and they should not change depending on what software he wants to use. OTOH he should be able to use any software he wants and installation of such software should not require a change of permissions.

That is completely possible and if it still doesn't work in Vista, then Vista has a problem.
Andrew Brehm Send private email
Wednesday, February 14, 2007
 
 
Although I inhabit (infest?) the MS ecosystem, I'm no MS fanboy. But this was a deliberate design decision that has been known for many months - I first read it Oct 2006.

I didn't agree with the decision, but I can see why they did it (backward compatibility). So I think "red-pill" Joanna is jumping on some sort of bandwagon.
Mark Pearce Send private email
Wednesday, February 14, 2007
 
 
1)  I dont want users installing applications on their own!  This is company property, not a personal computer!

2) What about shared libraries the application might install?  Would you feel comfortable about letting a user of a unix system install libraries into /usr/lib?

Managing computers isn't simple.  Going the mac route and letting users install stuff on their own creates far more complexity than requiring a clear rule that you must be running as "root" first.

Maybe Microsoft should start calling the Administrator account the "root" account instead.  Root is an account you dont mess with.  Look around the room and ask if you'd grant anybody in it root access to your computer...  If you were running Windows XP, odds were good you did.
Cory R. King
Wednesday, February 14, 2007
 
 
But here's something that DOES look rather nasty to me. If you're creating a setup program designed to be run on Vista by a Standard (non-elevated) User, you're supposed to install your app in LocalAppDataFolder, not ProgramFilesFolder. 

See point 3 here:
http://blogs.msdn.com/rflaming/archive/2006/09/30/778690.aspx

And here:
http://msdn2.microsoft.com/en-us/library/aa370813.aspx

In effect, this means that your Vista setup program should be different to your XP/2000 setup program.
Mark Pearce Send private email
Wednesday, February 14, 2007
 
 
What account does synaptic package manager run in Ubuntu? CALL 911!
Grant Send private email
Wednesday, February 14, 2007
 
 
Grant, you're missing the point that Synaptic, by default, only permits you to install signed packages from the official Ubuntu repositories.  You can't install trojans that way because there simply aren't any available.  If you know enough about the system to start adding third-party repositories to the sources list, you know enough to be able to assess whether or not you trust them.

Windows and Mac users, on the other hand, are used to downloading random applications from the net and installing them in an ad hoc way.  Mac users can do this relatively safely, without risking more than their personal data.  Windows users have to give the untrusted application's installer full access to everything on their computer.

Can you really not see a difference here?
Iago
Wednesday, February 14, 2007
 
 
"In Mac OS X I can install applications without administrator or elevated rights. I install it right in my own Applications folder in my home directory and the program gets to modify ABSOLUTELY NOTHING in the system, not a registry, not a system folder, not even a universal applications folder used by all users."

This sounds like the difference between Unix based OSes, which are inherently a multi-user, and Windows, which happens to have multi-user capability but looks like a single-user OS from the perspective of most users. 


Besides, I enter my password to elevate myself to install various application updates on Ubuntu, and trust that pkg-foo-flubble-v1.0 doesn't tromp on my shared system folders.  How is that different?

While you could write a Windows app and your own installer variant that does nothing but lays down its binaries in the user's own folders.  The difference is, currently, most applications for Windows aren't written that way, and Vista has to account for that fact.

Not that I find Vista particularly compelling yet, but starting to enforce certain rules seems like a step in the right direction, security wise.  The design decision may be a bit off from theoretical perfection, but there are usability concerns and legacy applications to deal with.  It's not easy to shift an entire customer and developer mindset in one rev of your OS.
Dan Fleet Send private email
Wednesday, February 14, 2007
 
 
"...and the program gets to modify ABSOLUTELY NOTHING in the system, not a registry..."

Does OS X have a registry?
Bluebeard
Wednesday, February 14, 2007
 
 
Iago, I hear you, but I still think 98 out of 100 people are just going to run the

./configure
make
sudo make install

on those untrusted packages.  My beef with this 'security hole' is that it's based on drastically different definitions of what 'installing' means on each OS.

Also, there are security risks with allowing users to install 'per user' apps.  Extra paranoid security guys will mount the /home partition noexec.  I'm not sure, but does OS X do anything to prevent say fork bombs? Or filling up the /tmp partition?  Or a cool game without source that secretly turns your computer into a spam zombie while you play?  I'm sure I could throw out a bunch of other potential 'security holes' with per user apps if I wanted to get attention, but this decision was a conscious trade off on OS X, just like Vista's installation decisions were a conscious trade-offs.
Grant Send private email
Wednesday, February 14, 2007
 
 
> In Mac OS X I can install applications without administrator or elevated rights. I install it right in my own Applications folder in my home directory and the program gets to modify ABSOLUTELY NOTHING in the system, not a registry, not a system folder, not even a universal applications folder used by all users.

Isn't this really just how the installer and application is designed though? The same thing could be done on Windows. It's not the way most authors design things, but it could be. 

Actually that's not true. A LOT of software for Windows in Japan is written this way (pretty much the same as the Mac there). So to start blaming Windows for the decisions of developers just doesn't really seem to cut it. 

Oh - I found another security hole in Vista... There's nothing in the OS to prevent people from dropping their computer in the bath tub! How silly is that? People would not only lose all their data, but their computers would be fried! Bad MS! Bad MS! ;)
Ryan Smyth Send private email
Wednesday, February 14, 2007
 
 
About OS X vs. Windows - I have found way too many programs that don't work properly if you install ANYWHERE but the default directory.

All you need is one place in the entire app where somebody used the default dir instead of looking it up. You have a failure.

Compare with Linux open source software. I have installed dozens of programs to non-standard directories as a non-privileged user, and, unless they explicitly require root privileges for an operation, have had zero problems.

I hesitate to say that Windows developers are sloppier, but rather that the *nix apps are designed from the bottom up to have their installation directory specified at the time of installation.
dot for this one
Wednesday, February 14, 2007
 
 
"Isn't this really just how the installer and application is designed though? The same thing could be done on Windows. It's not the way most authors design things, but it could be.  "

Yes. You can still install programs without admin rights in Vista. But only if your installer is home grown and isn't called something like "setup.exe". A program is a program but not if it fits Vista's set of heuristic requirements for a setup program.

Personally, I have mixed feelings about this "hole". I didn't really like it when they first announced it. I like things simple and consistent. Why put a bunch of special code out there to treat a specific program differently simply because it has a different file name? It doesn't make sense.... until of course you imagine all of those new Vista users running their legacy setup.exe program and having it crash because it requires specific admin rights and the user isn't capable of figuring out which one's it needs or even understanding how to run as an admin.

So I don't know if I like this "feature" or not. I certainly don't consider it to be a security hole. After all, for most commercial software I would advocate that people change to an admin account anyway to install it. Anything less and it is a crap shoot as to whether or not it will actually work.
dood mcdoogle
Thursday, February 15, 2007
 
 
>1)  I dont want users installing applications on their own!  This is company property, not a personal computer!

Well it *still* is a personal computer you know -- aka a PC. It is meant to be configured to the specific job needs and requirements of the person using it, not for the vision of some self-important, bottleneck IT department placeholder.

Perhaps you meant that while it's a PC, it should only be used for company purposes, yet that doesn't discount self-installs at all: Many users need disparate tools to do their job, and presuming that the host operating system has appropriate controls, there should be no reason why they can't install and use whatever they want (presuming that licensing issues are taken care of) to get their job done.
Dennis Forbes
Thursday, February 15, 2007
 
 
"Perhaps you meant that while it's a PC, it should only be used for company purposes, yet that doesn't discount self-installs at all: Many users need disparate tools to do their job, "

Spoken like a true developer who can't stand someone else controlling what they can and can't put on a PC. Bah!

What makes you so much more special than the cute receptionist who sits at the front desk all day? Both of you need your computer to do your job. But YOU claim to know what you are doing. If I had a dime for every programmer who claimed to know what they were doing yet was still running as an administrator all the time I'd be rich! Besides, she is much cuter than you are anyway.

AS LONG AS THERE IS A SIMPLE PROCESS IN PLACE TO ALLOW DEVELOPERS THE ABILITY TO GET PROGRAMS EASILY APPROVED FOR INSTALLATION, then there is no reason for a programmer to be able to do self installs (sorry for the emphasis/shouting). But alas, there rarely is a simple process in place for this. If there was, there'd be no real reason for programmers to complain would there?
dood mcdoogle
Thursday, February 15, 2007
 
 
>> If I had a dime for every programmer who claimed to know what they were doing yet was still running as an administrator all the time I'd be rich! <<

Spoken like a true bureaucrat who can't stand end-users being able to control their own machines.
Mark Pearce Send private email
Thursday, February 15, 2007
 
 
>Spoken like a true developer who can't stand someone else controlling what they can and can't put on a PC.

I've directed an IT department (aside from being the enterprise system architect), my friend. I have seen firsthand that many constraints are 95%+ empire building and work-assurance tactics by IT groups, desperately trying to manufacture their own importance by acting a bit like the troll under the bridge wherever possible.

"ANSWER ME THIS RIDDLE BEFORE YOU SHALL PASS!"

>But YOU claim to know what you are doing.

Asinine on so many levels.

The one-size fits all approach is *exactly* what is wrong with most IT departments. It's usually the result of IT groups that are largely clueless about the systems they administer ("sub-domain for a particular group and delegate authority appropriately to ensure each group is assigned appropriate tools and privileges applicable for their training and position? WTF is a sub-domain?").
Dennis Forbes
Thursday, February 15, 2007
 
 
So I take it you missed the point of my SHOUTING....

It doesn't HAVE to be that way. I certainly understand why developers get angry at IT departments who simply want to make things difficult to keep their job. It is very similar to DBA's who don't want you touching their "precious database". But I'm here to tell you that it can be done well and the result is a much more secure and happy environment. Maybe you've never seen it but that is beside the point.

Just remember that just because YOU are capable of controlling your own computer doesn't mean that every developer is. So where do you  draw the line? In my experience, the one's who calim to be able to handle it are the very one's you don't want to trust. People willing to work with a well administered process for installing sofrware are typically the one's who understand the security implications and end up being the one's you can trust.

YMMV. I just can't stand to listen to developers yammering on and on about their NEED to administer their own machines. Especially when 99% of them would run as an administrator if you let them (even though they don't really need to).
dood mcdoogle
Thursday, February 15, 2007
 
 
dood is right, you just need a rational way to handle exceptions.

My PC is managed according to corporate standards.  I can't install anything without an administrator signing on an authorizing it.  I asked if I could install the software to link to my cell phone and load my contacts into it.  Otherwise I'd be spending a couple of hours over the next week manually entering them all in via the keypad.

The day after I put the ticket in, someone called up and asked where the software was.  I told him I had it on a CD.  The local support guy came up the next morning, saw that it was an OEM disk and not some random thing I'd burned, and logged in as administrator so I could install it.

Sure, it was two days before I got what I needed, but it wasn't a compelling gotta-have-it-today issue.

Everything else on here is available as a network install, and is set up in my profile.  When I get a new PC -- I'm due to be refreshed in the next month or so -- I'll go to a single application, check the boxes for everything I need, and go to lunch.  When I come back, everything will be installed.

Every application that I install myself I'd have to reinstall when I get a new PC.  How many hours would that take?  Multiply that by the number of users in my office, which just relocated earlier this year.  Most of us didn't take the hardware from the old location, we just came to blank systems at our new desks and kicked off the install process.

If I'm paying for it, it is not worth my time to install software.  If my alternatives are to load all my apps on a new PC I've just bought, or to work a billable hour and pay someone else to do the installs, I'll pay the Geek Squad to click OK and reboot 14 times.  Why should I expect the company I work for, who owns the PC I'm working on, to make a different decision?
Drew K
Thursday, February 15, 2007
 
 
dood,

I think we're saying the same thing, only you're arguing for an ideal arrangement with a qualified, serviced-focused IT department, while I'm describing the way the majority of shops unfortunately work.

"People willing to work with a well administered process for installing software are typically the one's who understand the security implications and end up being the one's you can trust."

Presuming that such a system was well administered -- which it seldom is -- more often than not it is nothing more than the illusion of security. Take Drew's example -- if you want to own an entire organization, simply make a nice OEM looking CD and they'll come and do it with what is likely a domain account.

This harkens to when I was developing a system for a bank, and to have it deployed I had to get it audited and approved by the security department. Here I have visions of ultra-competent, security focused guys who were going to really open my eyes to things I might not have thought of -- On paper it sounds brilliant! Only then they arrive and it's a couple of jokers who ascending to become gatekeepers by everything but actual knowledge or skill. The "security" process comprised filling out a ridiculous array of bogus forms, waiting a period of time, and then getting their "Ay" (or ridiculously obvious questions like whether it encrypted passwords). This illusion of security, much like the IT guy installing Drew's software, was -vastly- more dangerous than alternatives, but it has a facade of being safer.

And to Drew -- the difficulty you describe, where user software installation and migration is a problem, is *entirely* the fault of Microsoft. Not all applications work like this, however, and many simply require you to copy the Windows equivalent of /usr/bin and you're good.

http://www.yafla.com/dforbes/2006/02/23.html
Dennis Forbes
Thursday, February 15, 2007
 
 
>> dood is right, you just need a rational way to handle exceptions. <<

I'm going to side with Dennis on this. In 28 years, I have NEVER found an central department able to do this competently.

So while the theory is great, in practice it's always FUBARed beyond recognition, and gives only the illusion of security.

In one instance where the central department insisted on wrapping my app before it could be deployed to the desktop, they took a week to do this, but were totally unable to get their wrapper to work properly. I was forced to come in at the weekend to help them, except they didn't even bother to turn up!

So I spend several hours debugging their work on my own, to find that the domain account they were using for deployment didn't have the right permissions. When I showed them what they had done wrong, they reacted by spending another whole week getting it to work properly.
Mark Pearce Send private email
Thursday, February 15, 2007
 
 
>> FUBARed beyond recognition <<

Sorry about the dupe.
Mark Pearce Send private email
Thursday, February 15, 2007
 
 
"I had to get it audited and approved by the security department."

This has been my experience with "security reviews". The value-added process is to wrap the code in some ancient version of Wise Installer, and sit on it for a few weeks. Color me arrogant when it comes to "professional" IT drones managing the configuration of the PC I work with.
Financial programmer
Friday, February 16, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz