I know that many organizations do not put restrictions on their users’ computers.  The users are often given full administrative privileges on their workstations, which means that they can not only mess around with all the settings on their computers, but they can also install and uninstall applications.  This includes accidental virus and malware installations.  While many Systems and Network Admins consider this unacceptable, it’s still a reality in many working environments.  So rather than complain about how it’s not the ideal way to run a windows network, let’s focus on cool ways to mitigate the risks of this approach.  This is one VERY simple but effective method to limit malware infections on your network computers while still allowing users to be local administrators.  This approach can be used across an entire network with a group policy object, or it can simply be applied to a single computer by modifying the computer’s local security policy.

Overview…

The idea here is that you apply a group policy object to the users or computers in your organization.   It prevents whatever applications you choose from launching with full admin privileges on the users’ computers.  The users are still local administrators, but the particular applications that you pre-select get launched without administrative permissions.  If you apply this restriction to all of the applications that deal with typically untrusted, unsafe, or unknown content, then you dramatically decrease the likelihood that a virus or other malware can be installed because non-admin users are not able to install software on the computer.  Windows doesn’t let them.  I recommend applying it to all web browsers, all email clients, and all media players because these are the primary apps that deal with internet content.  You could alternatively apply it to the entire C:\Program Files folder, but if you do so you should be mindful of the fact that some apps might break as a result.

You can produce functionality that is similar to DropMyRights but without the annoyances that come along with it.  In my opinion this method is by far the easiest to deploy to a lot of users or computers, something which DropMyRights isn’t suited for (since any time an application is updated or a new one installed, the DropMyRights configuration has to be re-applied).  Using Software Restriction Policies, you can apply this functionality in a way that is virtually transparent to users.  However, Microsoft doesn’t publicize this particular usage of SRP for whatever reason (the functionality is actually hidden in XP by default – you need to add a registry DWORD to make it available), which is why I’m taking the time to mention it here.  When I embarked on setting this up today at my job I spent hours researching something that took only minutes to implement.  Hopefully I’m now saving you the hours of research.

Caveat…

The only real caveat is that when an application is launched without admin privileges, if that application then launches another process or program, the program that it launches will also not have admin privileges.  This means that if a user wants to install software that he/she downloads from the web, he/she needs to be aware that launching the setup.exe file directly from browser’s ‘Downloads’ window will generate an error and abort the installation.  In some cases it might not throw an error and instead will appear to install successfully, but when the app is launched it isn’t able to run because the installation was actually not successful.  Users have to be trained to save the application setup files to their desktops (or wherever) and then launch them from the desktops or through Windows Explorer.

Additionally, it is up to you test out any applications that you restrict.  While most of the time this is a transparent deployment, there is always the possibility that this restriction could hinder a custom application from working in the way that it was designed.  However, for most applications in most situations it works great and causes no issues.

Here’s the step by step:

1. Expose the hidden ‘Basic User’ option by opening the registry editor and adding a DWORD called “Levels” with a value of 20000 (hexadecimal) to

HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers

2. Open the domain Group Policy editor (or to apply to a single computer, open the local policy editor by going to Start > Run > gpedit.msc) and go to

Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies

If this is the first time you’ve looked at the Software Restriction Policies, the right hand pane will be empty.  To rectify this, click on Action > Create New Policies.  Once you’ve done this you should see ‘Security Levels’ and ‘Additional Rules.’  Now click on ‘Security Levels’ and verify that you see 3 options (Disallowed, Basic User, and Unrestricted).

If you do not see the ‘Basic User’ option on the right-hand pane, close the GPO editor, go back to step 1 and make sure you’ve properly created the registry DWORD, then re-open the GPO editor (Note that the Basic User option is hidden in Windows XP until you add the Levels DWORD value).

3.  At this point you’re going to highlight ‘Additional Rules’ and right click to create a new path rule. Specify the path to the application that you want to limit.  In the path entry you can use the asterisk (*) as a wild card for multiple letters/words.  The question mark symbol can be used as a wild card for a single letter.

Set the security level drop-down menu to Basic User.  This is the key ingredient that makes the magic happen.  Now any executable file in the specified path or its subfolders will launch with limited user privileges on a computer that receives this GPO.

4.  When you’re done creating the policy, link it to your workstations OU and test it!  That’s it.  Pretty simple, eh?

In this example, I’ve limited Firefox so that it can only be launched as a Basic User with no admin rights. I’m able to verify this is the case by first closing all instances of Firefox, then launching it once again after the path rule has been created.  I browse to a website and download a software installation package. I then try to launch the software package from within Firefox’s ‘Downloads’ window, but I can’t perform the installation, so I know it works!

When you’re creating a Windows Form Application using Visual C# 2008, there are some tricky threading issues that need to be dealt with in order to keep your application running smoothly.  Specifically, you have to be very aware of how your application does work.  If you simply create a worker function and then call it, it’s going to execute in the current thread, which is also the thread that’s handling the user interface.  The result really stinks because your UI will completely lock up until the worker thread is finished executing.  This is unacceptable in nearly all situations.

I want to show you what I believe is the absolute simplest way for executing a worker function in a separate thread while still allowing that separate thread to send information back to the main UI thread, whether it be to update a text box, a label, or a field in a datagridview.

In this example we’re going to click a button to launch our worker function, which will count from 1 to 15.  Our user interface will display each number as it counts. 

Also, please pardon the fact that I use ‘function’ and ‘method’ interchangeably in this post.  Technically, I should just be saying ‘method,’ but ‘function’ always slips out.

Download the entire Visual Studio project here: UI_Threading_Example_CSharp.zip

Let’s take a look at the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

using System;
using System.Windows.Forms;
using System.Threading;
 
namespace UI_Threading_Example
{
    //declare the delegate that we'll use to launch our worker function in a separate thread
    public delegate void workerFunctionDelegate(int totalSeconds);
 
    //declare the delegate that we'll use to call the function that displays text in our text box
    public delegate void poplateTextBoxDelegate(string text);
 
    public partial class Form1 : Form
    {
       public Form1()
       {
          InitializeComponent();
       }
 
       //this function will simply write text to our text box
       //this function will later be called from a worker thread through the use of a delegate using the Invoke method on the form
       void populateTextBox(string text)
       {
          textBox1.Text = textBox1.Text + " " + text;
       }
 
       //this function simulates "work" by simply counting from 1 to totalSeconds
       void workerFunction(int totalSeconds)
       {
          for (int count = 1; count <= totalSeconds ; count++)
          {
             //we use this.Invoke to send information back to our UI thread with a delegate
             //if we were to try to access the text box on the UI thread directly from a different thread, there would be problems
             this.Invoke(new poplateTextBoxDelegate(populateTextBox), new object[] { count.ToString() });
             Thread.Sleep(1000);
          }
       }   
 
       //this function is executed when we click the first button in the windows form
       //this is the PROPER WAY to do work in a UI situation
       //the worker function is launched in a separate thread so that our UI will remain responsive while it does work
       private void buttonNewThread_Click(object sender, EventArgs e)
       {
          workerFunctionDelegate w = workerFunction;
          w.BeginInvoke(15, null, null);
       }
 
       //this function is executed when we click the second button in the windows form
       //it's an example of WHAT NOT TO DO because if we click this button
       //the UI will become completely unresponsive for 15 seconds while the worker fucntion is executed
       private void buttonCurrentThread_Click(object sender, EventArgs e)
       {
          workerFunction(15);
       }
 }

OK, so here’s what we’ve got.  In Visual Studio (I’m using Visual C# 2008) I’ve created a new Windows Form Application and then in the designer window I added a text box (called textBox1) plus two buttons (called buttonNewThread and buttonCurrentThread).

In the code window I created two functions:

1
2

void populateTextBox(string text)
void workerFunction(int totalSeconds)

plus a delegate for each function:

1
2

public delegate void poplateTextBoxDelegate(string text);
public delegate void workerFunctionDelegate(int totalSeconds);

The first function is responsible for writing text to our text box.  The second function is responsible for doing “work,” which in this case is just counting from 1 to 15 and calling the function (using a delegate) to display the count in our text box.  Additionally there are two other functions (buttonCurrentThread_Click and buttonNewThread_Click) which handle the button clicks from our UI:

What’s the deal with delegates in this example?

In order to launch a worker function in a separate thread we have to declare a delegate for that function.  The delegate declaration must be outside the class declaration, and the delegate for each function must have the same format as the function that it’s going to be used to call.  So for example, if your worker function has 3 parameters, your delegate must also have 3 parameters.  And in this example, we not only need a delegate to handle launching our worker function in a new thread, but we also need to declare a delegate that we’ll use from within the worker thread to call a function to update the text box on the UI thread.  It is NOT ok to try to update a text box in the UI from a different thread without the use of a delegate.  If you don’t believe me then give it a shot and you’ll see for yourself that the results are funky.

The WRONG way to execute the worker function (using the UI thread)

When you click the button to execute the worker function in the current thread, which is the same thread that handles the UI, then you’ll see that for 15 seconds you can’t do anything with the UI or even move the form window to a new location.  At the end of 15 seconds the UI becomes responsive again and you see a “15″ in the text box.

1
2
3
4
5

//This is the WRONG way to do it
private void buttonCurrentThread_Click(object sender, EventArgs e)
{
   workerFunction(15);
}

The RIGHT way to execute the worker function (using a separate thread)

When you click the button to execute the worker function in a new thread, you watch the count from 1 to 15 displayed in the text box and the UI is not frozen.

Note that the null values are required by the BeginInvoke method.  If you have a function that requires more than one parameter, you would still pass all your parameters in first, followed by the two nulls.  In this example we’re effectively passing the value 15 to the worker function which will then execute for 15 seconds.

1
2
3
4
5
6

//This is the RIGHT way to do it
private void buttonNewThread_Click(object sender, EventArgs e)
{
   workerFunctionDelegate w = workerFunction;
   w.BeginInvoke(15, null, null);
}

The proper way to update the text box in the UI from the worker thread using the Invoke method of the main form

The format can definitely get a little confusing, but hopefully you can follow along and mimic it for your application.  Instead of accessing the text box directly from the worker thread, which will cause problems, we instead invoke a method (using a delegate) that accesses the text box. Note that our populateTextBox function has one parameter, which is a string.  We want to write the current count to the text box using that function, so we have to convert it to a string.  If we were passing multiple variables to the populateTextBox function, the format would still look the same, and we’d simply separate the variables inside the curly braces by a comma.

1
2
3
4
5
6
7
8
9

//update the text box by using a delegate to call a function on the UI thread that will do the update
void workerFunction(int totalSeconds)
{
   for (int count = 1; count <= totalSeconds ; count++)
      {
         this.Invoke(new poplateTextBoxDelegate(populateTextBox), new object[] { count.ToString() });
         Thread.Sleep(1000);
      }
}