@CyberForge
 Live Well. Laugh Often. Love Much.

Last Updated: 2/22/2004; 5:50:32 PM.


 Saturday, May 17, 2003


Went to Lowe's today to get replacement sand for my three year old's sandbox. I knew that I needed 15 bags, each weighing 50 lbs. What I did not figure on is the antiquated trolley-thing whose steering wheels are in the back that I had to use to get all of those bags to my vehicle. But my son had a blast riding on top of it while his Dad was trying to maneuver the infernal thing down aisle ways that seem to be blocked by stacks of stuff, and people who could not seem to understand that something that heavy does not stop on a dime!

Finally got the thing to my van and started putting the bags in. My son kept asking me why I was making all those noises when I was putting the bags in. Don't think he got the "darn things are heavy and they leak" part. It also had not clicked for him why I was getting these bags. So finally we got home and unloaded everything.

Then I told to him that the sand was for his sandbox.

Ahh... These are the moments that you live for and cherish as a parent!  I LOVE being a Dad!

7:14:40 PM     Comment
  


Top 75 Security Tools from Insecure.Org via Larkware News

2:53:42 PM     Comment
  


There have recently been discussions in many places about running and developing as non-Admin. I figured that I would add my $0.02 to it.

There is an excellent document [1] by Lars Bergstrom (Visual Studio Core Team) on MSDN that outlines how to develop as non-Admin when using VS.NET. I've followed the procedure documented in it and have had no issues in developing and debugging ASP.NET applications as a Local User.

Recently, I installed VS.NET 2003 on my primary DEV machine and decided to follow the same instructions and ended up running into a couple of issues. Hopefully my solutions and work-arounds will help others who are trying to do the same thing. I am not going to repeat the existing docs but am just going to document the deltas.

NOTE: My dev machine is Windows XP Pro.

ProcessModel

By default, my restricted user login cannot debug Web applications. The web server started up ASP.NET as the NETWORK_SERVICE account and my user account, which is running the debugger, does not have the rights to debug other users' programs (SeDebugPrivelege).  The work around for this is to either grant my account this right or edit machine.config file to run the ASP.NET process under my user id.  The document recommends the latter approach for IIS 5 (Windows XP) which is what I chose to do.

This is done by changing the <processModel> from the default of:

<processModel userName="machine" password="AutoGenerate" ...... />
to
<processModel userName="YourUserName" password="YourPassword" ...... />

Security Note: If you do not set a restrictive ACL on the machine.config file, putting your userid and password in cleartext allows anyone to see your password. Even if you set a restrictive ACL, all users in the Administrators group will still be able to see it.

My resolution to the above Security Note was the following. Use the aspnet_setreg.exe utility [2] to put an Encrypted version of my account userid and password in the registry by using the following command:

aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"YourUserName" -p:"YourPassword"

Then modify the processModel as follows to point it to the registry:

<processModel 
    userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,userName" 
    password="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,password"
...... />

Registry Permissions

By default the DACL on the "HKLM\SOFTWARE\MY_SECURE_APP" hive grants Full Control to only System, Administrators and Creator Owner. Since ASP.NET is running under my userid, the caveat here is to make sure that I gave my userid (ex. "YourUserName") Read access to this registry hive where the userid and password are now stored.

This way, even if someone peeks into both machine.config and/or the registry they cannot see a cleartext version of my  userid and password.

File system Permissions

VS.NET 2003 installs version 1.1 version of the .NET Framework. Majority of the file ACL's needed are the same as documented in [1] except for that the %INSTALLROOT% changes to "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322". So you need to give the following rights to your account:

- %INSTALLROOT%  - Read
- %INSTALLROOT%Temporary ASP.NET Files - Read and Write

Once I made the above changes, I've have had no issues developing and debugging Web Applications using VS.NET 2003.

 

[1] Developing Software in Visual Studio .NET with Non-Administrative Privileges

[2] Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings

2:18:01 PM     Comment
  


 

© Copyright 2004 Anil John. All rights reserved.
The above are solely my opinions and do not represent the thoughts, intentions, plans or strategies of anyone else, including my employer.