Slashdot Mirror
MS Suggests Using Shims For XP-To-Win7 Transition
eldavojohn writes "Windows XP (and a lot of MS OS code before that) had a fundamental security flaw whereby the default setting made the ordinary user run as the superuser. Vista & Windows 7 have fixed that and implemented The Correct Paradigm. But what about the pre-Vista applications written to utilize superuser privileges? How do you migrate them forward? Well, running a virtualized instance of XP in Windows 7 is an option we've talked about. But Microsoft is pushing the idea of using 'shims,' which are a way to bypass or trick the code into thinking it's still running as user/superuser mode in Windows XP. This is an old trick that Microsoft has often employed, and it has brought the Windows kernel a long ways, in a duct-tape sort of fashion. At the TechEd conference in LA, Microsoft associate software architect Chris Jackson joked, 'If you walk too loudly down the hall near the [Windows] kernel developers, you'll break 20 to 30 apps.' So for you enterprise developers fretting about transitioning to Windows 7, shims are your suggested solution."
But MS's support for backwards compatibility is THE REASON they own the desktop.
You can slam all you want, but they will continue to own the desktop because they run all the apps you want.
You might as well virtualize XP on Linux.
At the TechEd conference in LA, Microsoft associate software architect Chris Jackson joked, 'If you walk too loudly down the hall near the [Windows] kernel developers, you'll break 20 to 30 apps.'
Yeah, real funny. Our software is fragile as fuck, HA-ha
Who's laughing at that goddamn joke? Oh, right, Microsoft is -- all the way to the bank.
By that logic WINE is just as good an option. Its transparent to the application and provides compatibility prior versions of Windows. If you have load additional software on windows or develop compatibility layers on your own then there is no value in the backward compatibility any longer. You might as well pour the same efforts into getting your app running on WINE.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Shims work.
It reminds me of the part in "Zen & the Art of Motorcycle Maintenance" where he suggests to John that beer can aluminum would be the perfect shim to keep his handlebars from slipping. John rejects the idea of using a beercan on his beemer, and so goes to buy "quality shimstock" which is probably made from beercans.
We shim many things, and I had no clue till I took off the siding of my house, and redid a few doors. Shims are how we make construction look good, and still get it done in a timely manner.
Surely it applies to programming as well?
How much is your data worth? Back it up now.
Yeah but how many of those apps are SUDO or SUID? Oh and we run all but one of our apps on locked down Citrix servers where they users are just that users with fairly severe restrictions beyond even MS standard user rights, you just need an admin that knows what they are doing. (The one app isn't run on Citrix because of a graphics library problem not a permissions one, it doesn't run correctly on widescreen aspect systems either!)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
For a single-user system (the majority of Windows desktops), it doesn't matter whether or not the user is an Administrator, at least from a security perspective. What threats are you protecting against by subjecting users to extra authentication buttons when installing apps? The only thing the single user really cares about is his own data! Malware running with his (non-administratior) access can destroy his data just as well as malware running as administrator. With either permission, the malware can spread via sockets, file infections, or web access.
This obsession with UAC on single-user desktop systems is simply misguided. Yes, some existing malware may break if it runs with non-admin privileges. But once non-admin becomes common, malware authors will just stop presupposing admin access when coding.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Since at least Windows 2000, Microsoft has provided guidelines about how to write code so the applications do not require administrative privileges. Most developers have either been ignorant of the practices, don't care about the practices, or don't know how to implement the practices. A lot of it has to do with where the DLL files get stored, and where the application writes its files to. In the *nix world, everything is pretty self contained within its own directory. For the most part, all of the files that an application needs are right there with the application. If they aren't in the same directory, symbolic links (something that Windows lacks) provides the application access to the necessary libraries.
I think you're blowing things out of proportion to say that it is unheard of it in the Windows world for users to be able to run as a something less than a super user. At my current job, we only have one app on the network that requires admin privileges. When I was consulting, most of our clients were all running as regular users.
The "problem" with Microsoft is that they have always catered to the lowest common denominator. When it comes to developers, they provide the developers with a powerful IDE and don't encourage them to think about how it works behind the scenes. That ease of use has come at the cost of security. Sure, devs have been able to come up with the applications that they need to meet the business requirements laid out for them. Unfortunately, those applications often times aren't properly hardened and crack when put on hostile networks.
I see the computer world working from two different ends. The Microsoft part of the world has provided the functionality and is backing into security. The *nix world has provided the security and the stable foundation, and now they are building the functionality.
You can't always stay away from legacy apps. Legacy apps are made to fill a need that a particular company has in a particular situation. This usually means that when their app is finally put up against the wall, their choices are either stick with the entire old ecosystem, OS and all, or rewrite from scratch.
Given finite budgets and a culture that values returns *this* quarter at the expense of every future quarter, guess which option gets picked most often.
I hate printers.
What should Microsoft be doing? The community is up in arms over their less than stellar security record. They introduce progressively better security with each iteration of the OS, but often times those security improvements crap all over previously accepted programming practices. What do they do? Pull an Apple and tell everyone to go out and buy the newest version of all of the software that was working just fine on the previous version of the OS? It seems to me like shims are a good solution. Older shops get to continue extracting value from their legacy code without having to invest money in rewriting the apps.
I suppose you check the design schematics for your car and watched your house being built to make sure there're no bugs planted in the wall...
You have to draw the trust line somewhere. So a business wants to check the code's all alrighty, they have to pay someone to do it... except then you're relying on the trustworthiness and skill of that person. They may as well just be paying MS.
Don't get me wrong, my line of work's all open source stuff, and where people require windows servers they always go in a virtual machine, never on bare metal. But I'm not everyone, other people and other businesses have other priorities. Ignoring that helps no one.
The revolution will not be televised... but it will have a page on Wikipedia
This seems to be aimed at applications which insist on running with administrator rights but don't actually use them. If the app actually tries to do something that needs administrator rights, it's going to fail anyway.
If applications without administrator rights can put files in administrator directories, especially ones that have OS components, then turning off administrator privileges is sort of pointless.
Next you'll be telling me you can't switch to another virtual console if your GUI crashes
If your GUI is crashing, you should consider using a different OS entirely. GUI crashes seem to be an acceptable event among Linux users, but most other users would not tolerate such occurrences. In Windows, there is a chance the "explorer" file manager might crash. For example, due to a 3rd party extension behaving badly. However, since XP and onward, a crashed explorer will restart automatically. Since explorer is only part of the GUI, none of your applications are disturbed.
Crashes of the underlying GUI are almost unheard of unless there is a serious flaw with the graphics driver. Since Vista and onward, the WDDM (Windows Display Driver Model) can restart the graphics system if such a problem should occur.
or review the OS code to satisfy yourself it's not malicious.
I would suggest that if you are paranoid enough to warrant reviewing the entire source code to the OS you wish to choose, you should probably consider some type of therapy. Using computers will only exacerbate your underlying problems.
"When you see a unixer brainwashed beyond saving, kick him out of the door." - Xah Lee
Well, maybe it is. But it's the large number of other apps that are at risk of breaking. Even if every one were written correctly, it'd be tough to maintain 100% compatibility. Add in the fact that many are written massively incorrectly (i.e. fragile) and you have a really tough road ahead of you.
Also, breaking 30 apps is peanuts, there has to be well over a million apps for Windows.
http://lkml.org/lkml/2005/8/20/95
Well, since what you described looks something like what chroot+setuid do on a Unix system, 25 apps in 2 days by 3 people is *extremely* slow.
Those are exactly the reasons why you'd want to write a shim. Often it's just easier found out the part of a PE that's causing a problem and then write a hack for it. MS does exactly that for massive numbers of popular applications, it's how the Windows Application Compatibility Layer works.
That might sound crazy but it's actually the least bad choice. It means they can keep compatibility cruft out of mainline development meaning apps written and tested for Vista / Win7 will work because they're written The Right Way.
Nick
This requires Windows source code so that you can hook the API's. Who the heck has that for any applications they run? Instead, this is a fix being presented to ISV's... however, if an ISV hasn't fixed their code yet, they probably aren't going to bother now.
----- obSig
Its these crap-tastic applications that caused problems in XP let alone the horrendous issues they will cause in Vista\7. To this day it baffles me that Developers assume end users are administrators of their computers, despite countless security experts explaining this is a bad idea. Aside from a few small (5-10 users) companies, no one gives administrator rights to their end users unless they are completely incompetent or just overburdened by political nonsense then it just creates more issues down the line. So just write it correctly the first time and your shims will vanish!
Yes, training is almost always more expensive than the change.
Let's take a small company using enterprise class software... say 15,000 employees. And let's pretend you pay them squat, $10/hr. Means it costs you $15/hr at least to have them.
So every hour you spend training costs $225,000 ... windows -> linux would likely be a 4 hour afternoon session, so you're knocking at a million dollars just for your employees time. You haven't even paid the trainers yet, and this won't be one massive webinar, you're doing at least a dozen or two sessions.
Tack on the ramped up support costs at the start of the deployment cycle, and the fact that skilled linux personnel command a higher salary than skilled windows personnel.
Then add in the fact that you bought the enterprise class software in the first place because it does what you want. Odds are OS was a minor concern when you purchased it to start.
So yes, it's a big difference.
Sure, it costs money to switch. The problem is that MBA's don't understand (or don't care) how much just supporting the current system costs. How much do you spend on Windows licenses? How much on individual software licenses? Software maintenance and ongoing training (every time a virus hits...)? Doing one side of the costs of switching is necessary, but don't forget to calculate the costs of NOT switching.
My blog. Good stuff (when I remember to update it). Read it.
Since when does a small company have 15,000 employees?
- It's not the Macs I hate. It's Digg users. -
That's not just people being stupid. The assumption is the cost to support one is close enough to the cost of supporting the other to disregard any differences.
The obvious issue bandied about for Linux - additional support cost (pricier personnel, fewer contracts/vendors, etc.) vs. the MS licensing cost.
Mind you I'm not agreeing or disagreeing on this particular example, but there is a why.