Thu, Dec 30 2004 1:16
Running with Scissors... uh .....I mean admin rights
When we were little kids we were told by our parents to “don't run with you have sharp objects in your hands” ... like..scissors. So remember my rant how I don't trust any browser? I want to revisit that a bit again tonight. Active controls in a web browser are, I think, like “running with scissors”. Why? Because what I said before that they rely on me trusting too much. While the whole concept of “active content” means great things have happened in the Internet space, it also means that the very way we have let our applications get away with being coded as horrifically as they are and haven't really noticed how bad they are is contributing to the malware/spyware and other gunk we now have to deal with.
While one could argue that Active X is worse than Darth Vadar, worse than ....oh I don't know.... worse than offering me fresh fish [I really hate sushi...I“m really sorry... it's chicken or beef for me], the fact is the real threat is there because Active X only plays in whatever “rights” you have on that system. Run in user mode and Active X isn't the issue we're all running from. Run like we're all used to with full rights to every single registry key on that box and Active X starts making us start thinking of a tall guy in a dark plastic suit that is a heavy breather. Active X is the bad guy it is because we're running with scissors around here. It can't be sandboxed from the user rights we have. Thus as long as we go “la di da ing“ through life accepting that my business applications, ones that I just bought during the 4th quarter of 2004, many of them still think they live in a Win98 world are just wonderful, we're going to be stuck in the mess we're in.
Tonight I was running some tests on one of my lovely applications that are not “Designed for Windows XP” but yet we all happily load it and run it on our XP systems. Once in particular ...well lets just say that I knew it was coded pretty poorly and now I'm certain more than ever that Vendors really need to step up to the plate more on securely coding these applications.
Now I'm not a coder by any means. The last coding I did [other than a quick batch file here and there] was the misguided attempt to have beancounters learn cobol. But it didn't take a degree in computer science or a slew of certifications to take one look at what that testing program was trying to tell me. That application of mine, the one that I put firm's financial data in, looked to this untrained eye to probably make someone like Michael Howard or Howard LeBlanc fall over in apoplexy.
In the document “Designed for Windows XP“ logo certification, the documents are pretty clear. Support user mode and you get that certification. So why the heck are we not beating up on vendors that DO NOT get certified on it and not giving awards for those vendors that DO get certified.
As I'm typing this up I have an idea. My term as Chairman of the Technology Committee of California CPA Society expires in May. Perhaps one of my final duties can be to set up an “award” to the accounting application that meets security criteria. Hmm.... I'll bring it up at the next meeting. Or perhaps my AICPA geek group, CITPers can also do that?
I'll showcase some of the vendors who ARE coding for least priviledge
Keep in mind that Peachtree 2003 is “compatible with XP“ and thus doesn't meet the guidance. Notice there is one major application missing that isn't in the “designed for Windows XP“ logo program at all.
Amazing isn't it? We run our daily business in an application that is not “designed for Windows XP“
That in this day and age we can accept “The user doesn't have sufficient permissions with the Windows user login. Users must have full Admin or Power User permissions that permit them to write to the Windows registry. “ as being acceptable from an accounting application... shouldn't we as CPAs, as fididuciaries of our client's records demand better than this?
Pssst you can't “intuit-itively“ figure out the app?
The designed for Windows XP logo includes this as a criteria
Applications must not require users to have unrestricted access (for example, Administrator privileges) to make changes to system or other files and settings. In other words, the application must function properly in a secure Windows environment. Complying with the previous requirements in this section will help to ensure that the application meets this requirement.
An application that does not install (executes without installing any components) must still support use by a Limited User.
A secure Windows environment is defined as the environment exposed to a Limited (non-Administrator) user by default on a clean-installed NTFS system. In this environment, users can only write to these specific locations on a local computer:
· Their own portions of the registry (HKEY_CURRENT_USER)
· Their own user profile directories (CSIDL_PROFILE)
· A Shared Documents location (CSIDL_COMMON_DOCUMENTS) [Note 3]
· A folder that the user creates from the system drive root
However, applications defaulting to use of these folders do not comply with the other requirements of this section.
Users can also write to subkeys and subdirectories of these locations. For example, users can write to CSIDL_PERSONAL (My Documents) because it is a subdirectory of CSIDL_PROFILE. Users have read-only access to the rest of the system.
 Applications can modify the default security for an application-specific subdirectory of CSIDL_COMMON_APPDATA. This may provide an additional location to which users can write for a given application.
Any modification of the default security for an application-specific subdirectory of CSIDL_COMMON_APPDATA must be documented when submitting your application.
 Users cannot write to the following subsections of HKCU:
 By default, users cannot write to other users’ shared documents; they can only read other users’ shared documents. Applications can modify this default security on an application-specific subdirectory of CSIDL_COMMON_DOCUMENTS.
Any modification of the default security on an application-specific subdirectory of CSIDL_COMMON_DOCUMENTS must be documented when submitting your application.
This requirement does not apply to all features.
WHEN DOES THIS APPLY?
When the major features of the application can be successfully run by a non-privileged user, minor features are allowed to fail gracefully. These minor features must not be installed by any default mechanism (for example, a minimal or typical install) other than a complete install and must not be considered important for the operation of the program. Examples of such minor features include components necessary to support legacy file formats.
Limited Users cannot perform several system administration functions such as disk defragmentation, backup/restore, changing system time, and so on. When most of the primary functionality of an application is system administration, the application must still run from a Limited User account and inform the user why none of the features can be used.
For any feature that a limited user cannot use, when submitting your application you must document what objects need to be opened for that feature to work, such as file system, registry keys, and so on.
When a limited user can’t use a feature, the application must degrade gracefully.
As defined in “Designed for Microsoft Windows XP” Application Test Framework:
TC3.4 Does application support running as User1, a Limited User?
Filed under: Rants