If you are running a 64 bit Windows, and you are aren't you, you are actually running two operating systems, one 64 bit, and one 32 bit. While this is an extreme simplification, it is for all intents and purposes true enough, while at the same time maybe not true at all. But it is.
Anyway, an Intel processor runs 16, 32 or 64 bit code in different modes, thus a process can only run in either mode, not several. If I designed a CPU I would make sure future modes could run current code, but I don't design CPUs, probably because I don't have a clue. To Intels defense, the x86 range of CPUs are backwards compatible back into a different century. Hilariously it was AMD, not Intel, who designed the 64 bit mode and thus it is sometimes called AMD64.
The consequence of these modes is that 32 bit binaries and 64 bit binaries are pretty incompatible. 32 bit processes cannot load 64 bit binaries and vise versa. To run both kind of programs, Windows therefor has an almost full set of both 32 and 64 bit components.
The system files of Windows have since Windows 95 been stored in the "System32" folder. In 32-bit Windows, which can natively run 16 bit code, there is also a "System" folder, pretty much containing a Windows 3.11 set of 16 bit files. But 64 bit Windows dropped the 16 bit support, so the "System" folder is no longer present. Well, it's there, but pretty much empty.
For stupid reasons Microsoft decided to keep the name of the system folder as "System32" even on a 64 bit Windows.
The System32 folder contains the 64 bit system files.
I can see why, but I believe it's stupid because we are going to run 64 bit for much longer than the 20 years we used 32 bit operating systems. Then again, the future plans for Windows executables are uncertain.
But as you've figured out, 32 bit programs can't use these 64 bit system files, how does that work? Misdirection! Or rather, redirection. Or virtualization, if you prefer.
A 32 bit program trying to access System32 will be redirected to the "SysWOW64" folder. The program believes it loads from System32, but it isn't. It's running a 32 bit System Windows On Windows 64. SysWOW64.
The SysWOW64 contains the 32 bit system files.
There are ways to get around this if your program needs to for some reason, but this is the default behaviour. You can access the true System32 folder from a 32 bit process by the alias C:\Windows\Sysnative.
The registry is divided in much the same way. 32 bit programs accessing HKLM\Software are redirected to HKLM\Software\Wow6432Node. They couldn't choose a consistent name such as RegWOW64, because why would they. Also note that HKEY_CLASSES_ROOT is actually a mirror of HKLM\Software\Classes and HKCU\Software\Classes, therefor 32 bit and 64 bit class registrations can exist at the same time, the 32 bit under HKLM\Software\Wow6432Node\Classes.
The Program Files folders are not redirected, you can install a 64 bit program in Program Files (x86) and a 32 bit program in Program Files without much trouble. However, the environment variables are different for each architecture, the %ProgramFiles% points to a different folder depending on the process.
You can try all this by launching one 64 bit CMD from C:\Windows\System32 and one 32 bit CMD from C:\Windows\SysWOW64.
I made a tool, CheckArch, that shows the architecture of a file, sometimes needed for troubleshooting. How you managed so far without it, I don't know.
Download CheckArch.exe
fredag 20 oktober 2017
måndag 16 oktober 2017
Virtual or virtual
-"I wan't a virtual app", my client says. "I wan't my app to be virtual!".
-"Fine", I reply not feeling like arguing about why and such, and I deploy his stupid program as an AppV.
-"How do I start this on my paddle?" he comes back asking.
-"Your paddle?"
-"Yes, my iPaddle!". His face is getting red.
-"You didn't say you wanted to have your program published to your tablet. I can do that, but it'll be a cost associated with it, licenses and stuff".
-"What do you mean? It's my program and it's my paddle!"
-"Yes, but it doesn't run your program, a program you have developed in Visual Basic, now does it?"
-"No, but I told you I wan't you to make it virtual!". The shade of my clients cheeks are now turning into a blueish color and his forehead is sweating. "Virtualize it!"
-"I did. But I now understand what you really want is a published remote application. I can do that too, but as I said, it needs an infrastructure that costs money. I can still do it, but I need one or a few servers and software that costs more or less money, depending on how many people are going to run the program among other things".
-"It's just me, on my paddle! And I don't care how you do it, I don't know the mumbo jumbo, that's YOUR job!"
-"If you don't know the jargon, why did you specifically order a virtual application, instead of just telling me what you want?"
True story.
-"Fine", I reply not feeling like arguing about why and such, and I deploy his stupid program as an AppV.
-"How do I start this on my paddle?" he comes back asking.
-"Your paddle?"
-"Yes, my iPaddle!". His face is getting red.
-"You didn't say you wanted to have your program published to your tablet. I can do that, but it'll be a cost associated with it, licenses and stuff".
-"What do you mean? It's my program and it's my paddle!"
-"Yes, but it doesn't run your program, a program you have developed in Visual Basic, now does it?"
-"No, but I told you I wan't you to make it virtual!". The shade of my clients cheeks are now turning into a blueish color and his forehead is sweating. "Virtualize it!"
-"I did. But I now understand what you really want is a published remote application. I can do that too, but as I said, it needs an infrastructure that costs money. I can still do it, but I need one or a few servers and software that costs more or less money, depending on how many people are going to run the program among other things".
-"It's just me, on my paddle! And I don't care how you do it, I don't know the mumbo jumbo, that's YOUR job!"
-"If you don't know the jargon, why did you specifically order a virtual application, instead of just telling me what you want?"
True story.
onsdag 11 oktober 2017
Self Repair
There are things that probably had good intentions early in its developement but eventually didn't turn out as great as one had hoped. Communism. The DeLorean DMC-12. MSI Self Repair.
An msi normaly register itself into the system during the end of the installation, running actions such as "PublishFeatures". With an msi you don't actually have to install the program, you only need to "publish" it. Some files and registry entries in the msi is set as keys, and if one of those is missing when the program needs it, Windows Installer will perform a Self Repair.
I don't know anyone who has ever published a program instead of installing it. But then again, I don't know that many people.
However, Self Repair has effect even when a program is fully installed, because the keys always have to be present. An msi usually applies source resiliency. In the rare case of an install that becomes corrupt it will try to reinstall the broken feature, but the more common scenario is that a user is launching the program for the first time and files and registry keys that are supposed to be in the user space are missing. When this works, it is ok. Not great, but ok.
This brings us to when it doesn't work, which is probably where a vast majority of people encounter Self Repair:
This was a very common problem during the days of removable media, but thankfully most computers don't even have a CD reader anymore. It's still a problem though, because users don't always have access to the company network, or the cache that used to contain the install has been purged. The latter is typical of an environment running the later versions of Microsoft System Center.
Some deployers seem to think Self Repair is the greatest thing since sliced bread, but it isn't. A proper program does NOT rely on Windows Installer for user files and a proper configured computer does NOT need to constantly repair broken installs.
Worse, many badly authored msi triggers unnecessary and sometimes repeating Self Repairs not only for itself but for features belonging to other, completely unrelated, programs. And for the love of God, don't set key paths to any startup locations! Do you hear me, Citrix?
There are a couple of work-arounds if you want to avoid actually solving the problem. The first and easiest is to create a new shortcut to the offending program and see if it launches correctly. Normally, the repair is triggered when the program is called by its advertised shortcut, a special lnk that goes to a launcher i C:\Windows\Installer. Repair is triggered by more events than launching the advertised shortcut though, so this might not always work.
The cause of the Self Repair should be noted in the Event Viewer in the Application Event log with an ID of 1004, and a quick fix could be to create a dummy file or registry key in place of the one missing.
The most brutal one is to use MsiZap to simply clean all the installer metadata, leaving only the program itself, completely unaware about any published features or components. This is a last resort solution that might cause new problems that are hard to troubleshoot further down the road, try to avoid it!
How to deploy an application that needs data in the user space will be covered, I promise.
An msi normaly register itself into the system during the end of the installation, running actions such as "PublishFeatures". With an msi you don't actually have to install the program, you only need to "publish" it. Some files and registry entries in the msi is set as keys, and if one of those is missing when the program needs it, Windows Installer will perform a Self Repair.
I don't know anyone who has ever published a program instead of installing it. But then again, I don't know that many people.
However, Self Repair has effect even when a program is fully installed, because the keys always have to be present. An msi usually applies source resiliency. In the rare case of an install that becomes corrupt it will try to reinstall the broken feature, but the more common scenario is that a user is launching the program for the first time and files and registry keys that are supposed to be in the user space are missing. When this works, it is ok. Not great, but ok.
This brings us to when it doesn't work, which is probably where a vast majority of people encounter Self Repair:
This was a very common problem during the days of removable media, but thankfully most computers don't even have a CD reader anymore. It's still a problem though, because users don't always have access to the company network, or the cache that used to contain the install has been purged. The latter is typical of an environment running the later versions of Microsoft System Center.
Some deployers seem to think Self Repair is the greatest thing since sliced bread, but it isn't. A proper program does NOT rely on Windows Installer for user files and a proper configured computer does NOT need to constantly repair broken installs.
Worse, many badly authored msi triggers unnecessary and sometimes repeating Self Repairs not only for itself but for features belonging to other, completely unrelated, programs. And for the love of God, don't set key paths to any startup locations! Do you hear me, Citrix?
There are a couple of work-arounds if you want to avoid actually solving the problem. The first and easiest is to create a new shortcut to the offending program and see if it launches correctly. Normally, the repair is triggered when the program is called by its advertised shortcut, a special lnk that goes to a launcher i C:\Windows\Installer. Repair is triggered by more events than launching the advertised shortcut though, so this might not always work.
The cause of the Self Repair should be noted in the Event Viewer in the Application Event log with an ID of 1004, and a quick fix could be to create a dummy file or registry key in place of the one missing.
How to deploy an application that needs data in the user space will be covered, I promise.
tisdag 10 oktober 2017
The requested execution level require administrator!
Executables that make changes to the system requires higher privilegies. Users will normally be asked to give admin credentials, and even members of the local administrator group will be asked for consent before elevating to a higher level of privilegies.
This is great!
However, some applikations require administrative privilegies even though they do NOT make or need to make any system changes.
That is retarded!
It actually lowers the overall security because if you don't know how to handle it users will have to be given, or some users might even have the balls to demand, administration rights.
An hilariously ironic example is InstallShield, one of the most common msi-editors. I can imagine some tools like the Response Transform Wizard might need admin rights, but otherwise there is no need. Another trouble maker is mmc.exe even though the snap-in you wan't does not. This makes it difficult to save a folder view and give to users to administer groups, for instance. Add to this various third party programs that only need to run as admin because the developer is lazy. Nothing wrong with laziness, unless it gives ME more work.
A program might ask for elevation for various reasons, where the correct and common reason is requestedExecutionLevel in the programs manifest is set to Level=requireAdministrator.
There are other reasons, some of which you can force. You can make a shortcut where you specify Advanced - Run As Administrator. This setting is in the lnk-file and will remain if copied. You can set the executable compability mode to Run As Administrator. This is stored in HKCU or HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and includes the full path. Therefor it will break if the file is renamed or copied.
If the file lacks a manifest you can just rename the file as setup.exe and Windows will force consent on you. That didn't come out right.
The other way around, running a program that requires admin rights without admin rights, is slightly more convoluted.
There are a couple of ways to do it, where the easiest way is to set the environment variable __COMPAT_LAYER = RunAsInvoker. Note the initial double underscore.
Using a script or by coding it is trivial to make a launcher. In AutoIt:
#NoTrayIcon
#AutoIt3Wrapper_Icon=Some icon preferably same icon as the program this is supposed to launch.ico
$RunAsInvoker_command = 'set __COMPAT_LAYER=RunAsInvoker'
Run(@ComSpec & ' /c ' & $RunAsInvoker_command & ' & start "" /D "' & @ScriptDir & '" ' & $cmdlineraw, @ScriptDir, @SW_HIDE)
Another way to more permanently change the application is to edit its manifest and simply replace level="requireAdministrator" with level="asInvoker" using your preferred manifest editor that works. They don't always work. If the file is signed, not even a hex-editor works.
That is the easy part. Then you need to make sure the program actually works running with only user rights. For this task, you'll need Procmon, the greatest tool ever made. I said that already.
UAC and Admin Approval Mode can be turned off in various ways. DO NOT DO THIS. On the contrary, if it was up to me (it isn't) I would enable Prompt for credentials for ConsentPromptBehaviorAdmin, so that even admins have to enter a password before elevating.
This is great!
However, some applikations require administrative privilegies even though they do NOT make or need to make any system changes.
That is retarded!
It actually lowers the overall security because if you don't know how to handle it users will have to be given, or some users might even have the balls to demand, administration rights.
An hilariously ironic example is InstallShield, one of the most common msi-editors. I can imagine some tools like the Response Transform Wizard might need admin rights, but otherwise there is no need. Another trouble maker is mmc.exe even though the snap-in you wan't does not. This makes it difficult to save a folder view and give to users to administer groups, for instance. Add to this various third party programs that only need to run as admin because the developer is lazy. Nothing wrong with laziness, unless it gives ME more work.
A program might ask for elevation for various reasons, where the correct and common reason is requestedExecutionLevel in the programs manifest is set to Level=requireAdministrator.
There are other reasons, some of which you can force. You can make a shortcut where you specify Advanced - Run As Administrator. This setting is in the lnk-file and will remain if copied. You can set the executable compability mode to Run As Administrator. This is stored in HKCU or HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and includes the full path. Therefor it will break if the file is renamed or copied.
If the file lacks a manifest you can just rename the file as setup.exe and Windows will force consent on you. That didn't come out right.
The other way around, running a program that requires admin rights without admin rights, is slightly more convoluted.
There are a couple of ways to do it, where the easiest way is to set the environment variable __COMPAT_LAYER = RunAsInvoker. Note the initial double underscore.
Using a script or by coding it is trivial to make a launcher. In AutoIt:
#NoTrayIcon
#AutoIt3Wrapper_Icon=Some icon preferably same icon as the program this is supposed to launch.ico
$RunAsInvoker_command = 'set __COMPAT_LAYER=RunAsInvoker'
Run(@ComSpec & ' /c ' & $RunAsInvoker_command & ' & start "" /D "' & @ScriptDir & '" ' & $cmdlineraw, @ScriptDir, @SW_HIDE)
Another way to more permanently change the application is to edit its manifest and simply replace level="requireAdministrator" with level="asInvoker" using your preferred manifest editor that works. They don't always work. If the file is signed, not even a hex-editor works.
That is the easy part. Then you need to make sure the program actually works running with only user rights. For this task, you'll need Procmon, the greatest tool ever made. I said that already.
UAC and Admin Approval Mode can be turned off in various ways. DO NOT DO THIS. On the contrary, if it was up to me (it isn't) I would enable Prompt for credentials for ConsentPromptBehaviorAdmin, so that even admins have to enter a password before elevating.
Procmon, the greatest tool of all time
If you don't use Procmon, you're not an IT professional. If you're not an expert at quickly sifting through the Procmon output you are definitely not a deployer!
Procmon is the greatest trouble shooting tool for PC ever made and you should be using it.
My work day is 25% Procmon and 25% other work.
Procmon is the greatest trouble shooting tool for PC ever made and you should be using it.
My work day is 25% Procmon and 25% other work.
måndag 9 oktober 2017
The system corrupts
An update is due again, as it always is. This time it is the digital signage program Dise. Previously deployed version is 1.6 and when I try on my lab computer both uninstalling this version and installing the new one works beautiful with just a /S switch. A good five minutes of work that I can charge $500 for. I can lean back, take a sip of coffee and browse the internet for "news".
I deploy the application but curiously I don't get any statistics in System Center, nothing seems to happen. Suddenly I hear screaming. The staff at the call center seem distressed. I find that after a restart the computers don't boot anymore, all thats left of our entire environment is this:
It turns out that uninstalling Dise 1.6 with the SYSTEM accound wipes the boot sector for no reason. The computer is now a brick.
Fortunately the above scenario didn't play out, because I actually spent more than five minutes and caught this before deploying.
Many installs behave differently when installing as SYSTEM as opposed to an ordinary administrator account. Every install MUST be tested with this account before being deployed sitewide. I recommend at least having a CMD shortcut on the desktop that uses psexec.exe to launch as SYSTEM.
Some old issetup.dll, a component in Installshield built setups, had a bug that launched the install as the currently logged on user, which of course failed with tons of access denied. Some installs deploy settings only to the running users profile, which in this case is C:\Windows\System32\config\systemprofile or might fail to write user settings altogether. Some installs get confused for other reasons when the environment is different from a standard user.
Few installs are as awful as Dise, but there are more ways to completely destroy a computer. More about that in a later post.
I deploy the application but curiously I don't get any statistics in System Center, nothing seems to happen. Suddenly I hear screaming. The staff at the call center seem distressed. I find that after a restart the computers don't boot anymore, all thats left of our entire environment is this:
It turns out that uninstalling Dise 1.6 with the SYSTEM accound wipes the boot sector for no reason. The computer is now a brick.
Fortunately the above scenario didn't play out, because I actually spent more than five minutes and caught this before deploying.
Many installs behave differently when installing as SYSTEM as opposed to an ordinary administrator account. Every install MUST be tested with this account before being deployed sitewide. I recommend at least having a CMD shortcut on the desktop that uses psexec.exe to launch as SYSTEM.
Some old issetup.dll, a component in Installshield built setups, had a bug that launched the install as the currently logged on user, which of course failed with tons of access denied. Some installs deploy settings only to the running users profile, which in this case is C:\Windows\System32\config\systemprofile or might fail to write user settings altogether. Some installs get confused for other reasons when the environment is different from a standard user.
Few installs are as awful as Dise, but there are more ways to completely destroy a computer. More about that in a later post.
onsdag 4 oktober 2017
Success fail
A successful installation should return an exit code of 0, but that is not always the case. These cases need to be handled properly, or I'll get a very red pie-chart in System Center.
The most common exception is 3010, a successfull install that needs a reboot, but there are others. Some more or less retarded.
Just now I needed to deploy an msi that returned 1638 if it was already installed. 1638 is documented as ERROR_PRODUCT_VERSION, "Another version of this product is already installed". This is stupid on many levels. First, if the same version is installed an msi should just install again. If an older version is installed, a proper msi should perform a major upgrade. The exit code might be useful if a newer program exists on the computer, but barely. I would say that installations which return 1638 should be documented as ERROR_MSI_SUCKS. The solution is to always uninstall before installing. This leads to the next problem.
Uninstalling an msi might return 1605, ERROR_UNKNOWN_PRODUCT, "This action is only valid for products that are currently installed." Yes, thank you. Already not there then. Success.
Sometimes you might need to deploy a patch for Windows, usually named kb-something with an msu extension, with your application. Unfortunately a shitload of your computers in your enterprise will report failure 2359302, 0x240006 in hex. This means WU_S_ALREADY_INSTALLED, "The update to be installed is already installed on the system". This is even dumber than 1638. If it is already installed, it is a success!
Related is the msu exit value of 2149842967, 0x80240017 in hex, "The update is not applicable to your computer". You'll get this result if you try to deploy a patch for Windows 7, and you happen to have a few Windows 10 among them, as an example. Not unlikely for many reasons, one of which is the update is included in a larger install where the application needs it on older Windows, but you don't feel like making two different packages for each OS or some other workaround. While the error might be interesting for some reasons, as a deployer I don't care. I filter it to success and I'm just as happy.
Deploying drivers with DPInst is an entire chapter of itself. The return value you get consist of three hexadecimal parts merged with OR like this:
0xYY0000 contains the number of drivers that failed to install.
0x00YY00 contains the number of drivers copied to the driver store.
0x0000YY contains the number of drivers successfully installed.
A return code of 66051 thus means 1 driver failed, two drivers copied to the driver store and 3 drivers installed, because it's 0x010203 in hex.
The simplest way to get a useful value is to do an AND FF0000. If it's zero, it's a success, otherwise you'll get the number of fails times 65536.
But so far the exit codes have at least been valid and have their reasons. Some badly written installers give all kinds of weird return values. Adobe was notorious for a while, returning 255 for a success.
But of all the moronic exit codes to indicate success there is one particularly stupid from msiexec;
1707 - Installation operation completed successfully.
The most common exception is 3010, a successfull install that needs a reboot, but there are others. Some more or less retarded.
Just now I needed to deploy an msi that returned 1638 if it was already installed. 1638 is documented as ERROR_PRODUCT_VERSION, "Another version of this product is already installed". This is stupid on many levels. First, if the same version is installed an msi should just install again. If an older version is installed, a proper msi should perform a major upgrade. The exit code might be useful if a newer program exists on the computer, but barely. I would say that installations which return 1638 should be documented as ERROR_MSI_SUCKS. The solution is to always uninstall before installing. This leads to the next problem.
Uninstalling an msi might return 1605, ERROR_UNKNOWN_PRODUCT, "This action is only valid for products that are currently installed." Yes, thank you. Already not there then. Success.
Sometimes you might need to deploy a patch for Windows, usually named kb-something with an msu extension, with your application. Unfortunately a shitload of your computers in your enterprise will report failure 2359302, 0x240006 in hex. This means WU_S_ALREADY_INSTALLED, "The update to be installed is already installed on the system". This is even dumber than 1638. If it is already installed, it is a success!
Related is the msu exit value of 2149842967, 0x80240017 in hex, "The update is not applicable to your computer". You'll get this result if you try to deploy a patch for Windows 7, and you happen to have a few Windows 10 among them, as an example. Not unlikely for many reasons, one of which is the update is included in a larger install where the application needs it on older Windows, but you don't feel like making two different packages for each OS or some other workaround. While the error might be interesting for some reasons, as a deployer I don't care. I filter it to success and I'm just as happy.
Deploying drivers with DPInst is an entire chapter of itself. The return value you get consist of three hexadecimal parts merged with OR like this:
0xYY0000 contains the number of drivers that failed to install.
0x00YY00 contains the number of drivers copied to the driver store.
0x0000YY contains the number of drivers successfully installed.
A return code of 66051 thus means 1 driver failed, two drivers copied to the driver store and 3 drivers installed, because it's 0x010203 in hex.
The simplest way to get a useful value is to do an AND FF0000. If it's zero, it's a success, otherwise you'll get the number of fails times 65536.
But so far the exit codes have at least been valid and have their reasons. Some badly written installers give all kinds of weird return values. Adobe was notorious for a while, returning 255 for a success.
But of all the moronic exit codes to indicate success there is one particularly stupid from msiexec;
1707 - Installation operation completed successfully.
Firewall rulez!
If your program needs to add firewall rules, your installer should provide the option.
DO NOT rely on the person installing your application to know what needs to be done.
DO NOT ignore it and let Windows pop up the Security Alert, this one:
Not the user nor the administrator knows or cares what firewall rules your application requires. The user probably, preferably, don't even have permission to allow access.
A lazy application manager, one like me for instance, might even consider turning off the local firewall altogether if it get complicated enough.
A prime example is the Flexera LMFlex, a pretty common manager for floating licenses used by a wide range of applications such as Autodesk AutoCAD, Pitney Bowes MapInfo and Safe Software FME.
LMFlex does not configure the rules for you, it requires a range of ports to be open, uses random ports as default, and every dependent application is managed by a separate LMgrd.exe process.
I could write an entire post about LMFlex, and probably will, but for now I'll just sigh and turn off the firewall.
I don't have time for this, I have porn to discover.
DO NOT rely on the person installing your application to know what needs to be done.
DO NOT ignore it and let Windows pop up the Security Alert, this one:
Not the user nor the administrator knows or cares what firewall rules your application requires. The user probably, preferably, don't even have permission to allow access.
A lazy application manager, one like me for instance, might even consider turning off the local firewall altogether if it get complicated enough.
A prime example is the Flexera LMFlex, a pretty common manager for floating licenses used by a wide range of applications such as Autodesk AutoCAD, Pitney Bowes MapInfo and Safe Software FME.
LMFlex does not configure the rules for you, it requires a range of ports to be open, uses random ports as default, and every dependent application is managed by a separate LMgrd.exe process.
I could write an entire post about LMFlex, and probably will, but for now I'll just sigh and turn off the firewall.
I don't have time for this, I have porn to discover.
Everybody writes to program files!
Now and then I am given a program to deploy that doesn't work. Just kidding, I get such programs all the time.
Actually, I am quite surprised when something works straight out of the box. I have a hard time fathoming how people without my amazing skills get anything to work on their computer at all.
Well, one of the reasons is that most people are using their home computers with an account that has administrative privilegies. Some people even turn off UAC to get rid of some annoying consent-dialogs.
In a corporate environment, this is a very very bad idea. Ask anyone working at an Iranian nuclear facility. (Full disclosure: I don't have a clue about the infrastructure at any nuclear facility, Iranian or otherwise).
A very common problem I face is programs that require write-permissions in its program folder. Older programs, binaries that does not include a manifest with a requested execution level, have their writes redirected by modern Windows to the users profile, to %localappdata%\VirtualStore. This, however, only works with UAC enabled.
But so far so good, these old crap program works somewhat, thanks to the pile of workarounds that is Windows.
New crap programs does not.
They are getting less and less common but I still get them.
Why not just give users write-permissions, you may ask. Because they don't deserve it I may answer, but that would be wrong. No, it's because it's a major security concern.
Having write access to program or system folders is different than having write access anywhere else, because a malicious program could replace files the user launches, and unlike executables saved on the desktop or the download folder, users don't have a clue what they are launching when starting an already installed program.
Also, it makes further security restrictions like AppLocker a pain to administer. Imagine you manage a restricted environment where users are only allowed to start prior approved programs, that you have tried, tested and deployed. The users are not local administrators, so they can't install anything, and you wan't to configure AppLocker so that they can't even start binaries but the programs you deploy.
Pretty much the only AppLocker rules you would need then are the default rules, like this one:
While this isn't entirely true if you use stuff like Click-to-Run, ClickOnce (stupid names, by the way) or AppV, it covers most of what you need.
However, if only ONE folder that fits within your Allow-rules are writable by users, it all falls apart! Any user or a malicious program can then launch whatever they want, and the added security AppLocker is supposed to provide is to no avail.
Microsoft has a tool, Sysinternals AccessChk that will help you after the fact, but you will need to be the person to avoid installing programs that changes permissions on folders.
If you absolutely MUST, install the program elsewhere. Not in the root directory, but maybe in C:\ProgramData or make a new folder called C:\Program Files Secure.
Or why not C:\Program Files That Suck!
Then you'll need to add new AppLocker rules separately. But it works.
Actually, I am quite surprised when something works straight out of the box. I have a hard time fathoming how people without my amazing skills get anything to work on their computer at all.
Well, one of the reasons is that most people are using their home computers with an account that has administrative privilegies. Some people even turn off UAC to get rid of some annoying consent-dialogs.
In a corporate environment, this is a very very bad idea. Ask anyone working at an Iranian nuclear facility. (Full disclosure: I don't have a clue about the infrastructure at any nuclear facility, Iranian or otherwise).
A very common problem I face is programs that require write-permissions in its program folder. Older programs, binaries that does not include a manifest with a requested execution level, have their writes redirected by modern Windows to the users profile, to %localappdata%\VirtualStore. This, however, only works with UAC enabled.
But so far so good, these old crap program works somewhat, thanks to the pile of workarounds that is Windows.
New crap programs does not.
They are getting less and less common but I still get them.
Why not just give users write-permissions, you may ask. Because they don't deserve it I may answer, but that would be wrong. No, it's because it's a major security concern.
Having write access to program or system folders is different than having write access anywhere else, because a malicious program could replace files the user launches, and unlike executables saved on the desktop or the download folder, users don't have a clue what they are launching when starting an already installed program.
Also, it makes further security restrictions like AppLocker a pain to administer. Imagine you manage a restricted environment where users are only allowed to start prior approved programs, that you have tried, tested and deployed. The users are not local administrators, so they can't install anything, and you wan't to configure AppLocker so that they can't even start binaries but the programs you deploy.
Pretty much the only AppLocker rules you would need then are the default rules, like this one:
While this isn't entirely true if you use stuff like Click-to-Run, ClickOnce (stupid names, by the way) or AppV, it covers most of what you need.
However, if only ONE folder that fits within your Allow-rules are writable by users, it all falls apart! Any user or a malicious program can then launch whatever they want, and the added security AppLocker is supposed to provide is to no avail.
Microsoft has a tool, Sysinternals AccessChk that will help you after the fact, but you will need to be the person to avoid installing programs that changes permissions on folders.
If you absolutely MUST, install the program elsewhere. Not in the root directory, but maybe in C:\ProgramData or make a new folder called C:\Program Files Secure.
Or why not C:\Program Files That Suck!
Then you'll need to add new AppLocker rules separately. But it works.
Prenumerera på:
Inlägg (Atom)