Don Kiely's Technical Blatherings

All Things Technical in .NET, SQL Server, and Security

<January 2009>
SuMoTuWeThFrSa
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567


Navigation

Personal

Subscriptions

News

Post Categories



Saturday, September 25, 2004 - Posts

Updating Application Data

Yesterday (this morning? can't tell anymore....) I wrote about a nice question from Julie Lerman about how WinXP SP2 changed the permissions of the Application Directory folder and how Julie mentioned after the fact that she was using Windows 2000.

This afternoon I was catching up on my blog reading and found this great post by Larry Osterman, who frequently writes about security issues at a fairly low level. He regularly posts some code that has issues, gives it a day, and then posts his thoughts on the matter. In this case he talks about why you might not want to be allow the user to update application data, but they can freely delete and recreate it. It's all about data integrity.

Seems like overkill to me in most cases, but in this day and age who am I to criticize playing it safe?

posted Saturday, September 25, 2004 1:23 PM by donkiely with 0 Comments

Great Series on Source Control Management

Eric Sink of SourceGear has been doing an occasional series of blogs on the intricacies of source control. Even if you don’t use the company’s Vault product (which I think is one of the best on the market) the series is a great analysis of the issues involved with managing concurrent software development. Eric has some great insights into the whole mess.

My favorite chapter is Chapter 3: File Merge. Great reading! And—gasp!—a source control vendor who actually uses their product for active development, unlike Microsoft and SourceSafe!

posted Saturday, September 25, 2004 3:59 AM by donkiely with 0 Comments

A Secure Windows Installation Recipe

Once I got past the hang problem I blogged about here when rebuilding a WinXP system, I switched my regular login to least privilege, of course. Then, logged in as Administrator (the name of which I had changed, of course), I installed my many apps. It blows my mind the number of setup apps that have no respect for the user profile they’re installed against. To their credit, some have the setup screen that asks whether to install the app for all users or just the current user. Running as the Administrator user you want to select all users, of course. But even in those cases sometimes the Program Files item on the start menu was only in the Administrator.

It’s hard enough to install a new app every so often on a machine that has been long since configured and used on a daily basis. Every week or three when you have to install a new app you have to put up with the hassles of finding the right trick to use to get it installed correctly under least privilege. But to spend half a day installing app after app and having to fight it all along the way just isn’t worth it.

So at this point I have to recommend that you build a new machine with admin privileges while logged in as your regular, non-admin login. That way you don't have to fight setup programs that act like they were designed before security was invented (well, because most were) and your configuration settings are properly installed for your everyday login.

The pattern would look something like this:

  • Install Windows and configure its components logged in as Administrator.
  • Go to Windows Update and install everything but SP2.
  • Create your regular user login and make it a member of both the Administrators and Users group.
  • Log in under that login and install security-related utilities, including a firewall if you’ll not use the Windows firewall, antivirus software, adware protection, antispam software, and anything else that gives you a warm, fuzzy, secure feeling.
  • Install Office, Visual Studio, and all your other apps and tools.
  • At the very least, startup all those applications and do whatever configuration dance they require. Some apps write config data in protected areas, so you need to do this with admin privileges. This gets your apps configured without hassle.
  • Use the machine for a day or three with your login still a member of the Administrator group. It pains me to no end to write this, but it’s the best balance between security and sanity. 
  • Once you’re reasonably satisfied that things are configured the way you want, install SP2 and then remove yourself from the Administrators group. Put a reminder in Outlook to do this so you don’t forget.

Voila! A secure Windows installation.

I think this recipe is a reasonable compromise between security and sanity. If you have any ideas for better ways to do things, I’m all ears!


Footnote: Somewhere I have a reference for steps you can follow to prevent attacks while connecting to the Internet with an unpatched Windows install in order to connect to Windows Update. Does anyone know of such a thing? If not, I’ll poke around and post it when I find it again.

posted Saturday, September 25, 2004 3:54 AM by donkiely with 2 Comments

Trials and Tribulations of Building an SP2 Machine

I’ve spent considerable time this last week reinstalling Windows XP on my IBM ThikPad T40. It was becoming way too unstable—all that installing and uninstalling of way too much software caught up with it, I’m afraid. At VSLive! Orlando last week I was on pins and needles about whether during my ASP.NET session I would show running code or just sock puppets.

So between intense bouts of real work, I explored the features IBM builds into its ThinkPads these days for restoring a system. I was overjoyed to find that everything I needed to restore it to a fresh-from-the-factory state was just a couple of clicks away during a reboot. It blew away my system partition and put a copy of WinXP with the ThinkPad tools. Took more than an hour, but I didn’t have to touch the machine once I started it through Access IBM.

Being the security-conscious type, I took that pristine version of WinXP and installed SP2 and various other updates and fixes, along with Norton Internet Security to provide firewall and antivirus services. At this point I was thinking how much simpler this was than doing a fresh install of Windows.

Alas, the warm fuzzies weren’t to last long. To make a long story long, once I started installing applications the Windows Installer would hang. The progress bar wouldn’t budge even though the Cancel button was active and responsive. But after confirming that I wanted to quit the install, the progress bar still just sat there. This was with Office 2003 and Visual Studio .NET 2003, and various other applications I tried.

Googling “Windows Installer” hang found plenty of ideas and tools, none of which worked. I tried various combinations of apps and installation sequences to no avail. After at least a day of this, I began to question whether the result of restoring WinXP using the IBM restore tools was as pristine as I would hope.

The only thing that I finally found that worked was to not install SP2. I restored WinXP using Access IBM and installed all the updates and hotfixes that Windows Update wanted to throw at me, except for SP2. Voila! Everything installed beautifully and I’m now back in business, but still without SP2.

posted Saturday, September 25, 2004 3:47 AM by donkiely with 1 Comments

Permissions Change in WinXP SP2 for Application Data Directory

Julie Lerman, the fabulous leader of the fabulous Vermont .NET Users Group, wrote me today with a question arising from her efforts to code more defensively. I’m happy to say that she’s a real convert to least privilege since I spoke on the topic at her user group. She wrote:

One of the great lessons I got from a talk on least privilege by Don Kiely was about persisting data into the application data folder, not into the application's folder inside of program files.

I overhauled an app that reads and writes xml files and was  originally doing so inside of the startup directory. I changed it to go to "all users\application data\blah blah..."
 
My first test with a lowly USER resulted in the discovery that a lowly user does not have write/modify access by default in that folder either.

My first response to her:

In the default install of WinXP, the C:\Documents and Settings\[user]\Application Data folder and its children should have three users with Full Control permission:

  • Administrators Group
  • SYSTEM
  • User whose profile this is part of

Fortunately I have a pristine, pre SP2 machine at hand (I just had to rebuild my laptop), and there seems to have been no changes here with SP2. The All Users profile has Everyone with Full Control to that Application Data directory.

BUT this is different on a machine with SP2 installed. Microsoft seems to have dogfooded (dogfed?) least privilege down our throats, so that All Users\Application Data now has these settings:

  • Administrators: Full Control
  • CREATOR OWNER: Full Control of subfolders and files only
  • Power Users:Modify, Read & Execute, List Folder Contents, Read, Write
  • SYSTEM: Full Control
  • Users: Read & Execute (special), List Folder Contents, Read, Write (special)

Note that Users no longer have the Modify permission. So that looks better from a least privilege standpoint, but it changes the recommendation. Kinda screwy that a user can read and write but not modify.

Alas, she responded that the target system is running Windows 2000. Hmm. Well, never mind then! :-D But her question let me to explore the SP2 changes in permissions for the Application Data directory.

Now as soon as I get my hands on a Windows 2000 virtual drive I’ll prod the situation there. Stay tuned.

posted Saturday, September 25, 2004 3:43 AM by donkiely with 1 Comments




Powered by Dot Net Junkies, by Telligent Systems