Restrict Kids from Installing ANYTHING

[wesleyw]

You could use Faronics Deep Freeze that does something similar and you wouldn't have to take all the PCs apart in the process. I'm looking at Faronics and Reborn cards at the moment, mainly because I'm moving the entire setup from RM so I need something like these. Strange though, RM Connect 2.4 used to rebuild workstation images if they got changed (Much like the card or software above) whereas Community Connect 3 doesn't have this anymore and uses a b*stardised version of RIS.

 

Wes

[SpuffMonkey]

So take away the challenge, let 'em wipe the Windows folder, or run FDisk, see if I care! Restart the machine, problem solved. The point is that they don't bother trying any more.

Invest £30 - buy one & try it

 

RoyG

 

P.S. No, I'm not on commission!

 

OK - so where do you buy them?

[Dos_Box]

I think one major problem with GPO's etc is the fact the Microsoft never, ever designed it's systems with schools in mind. Had they done so they would have discovered how to really get around their security mesures. It doesn't help that many settings are replicated or overridded by others in Active Directory.

[RoyG]

So take away the challenge, let 'em wipe the Windows folder, or run FDisk, see if I care! Restart the machine, problem solved. The point is that they don't bother trying any more.

Invest £30 - buy one & try it

 

RoyG

 

P.S. No, I'm not on commission!

 

OK - so where do you buy them?

 

http://www.bits.uk.com/ - talk to Dennis Champion

 

RoyG

[RoyG]

Forgot to mention that on our laptop clusters we use a software version of the Reborn card called EzBack. As far as I know it's only compatible with Intel or Realtek NICs.

 

I'd guess it's not quite as bullet-proof as the card, but as the little dears only get occasional access to the laptops for one lesson at a time they don't really have time for serious hacking. We've been using this for a couple of years & no-one's cracked it yet.

 

RoyG

[ajbritton]

@Geoff - Would I be right in assuming that the ADM template shown below will only disable the USB storage if it is already running? I looked on a PC that has never seen a USB stick and the registry keys are not there. In this instance the policy will have no effect. A user could install a USB key and use it until the PC was rebooted. I think you need to modify the permissions on USBSTOR.INF and USBSTOR.PNF to prevent installation in the first place.

 

How about a GPO ADM template? Per Machine but meh..

 

1.) Take the following text, copy it, and paste it into a text document. Then, save it as USBSTOR.ADM.

 

CLASS MACHINE
CATEGORY "Custom Policies"
KEYNAME "SYSTEM\CurrentControlSet\Services\UsbStor"
 POLICY "USB Mass Storage Installation"
  EXPLAIN "When this policy is enabled, USB mass storage device permissions can be changed by using the drop down box.

Selecting 'Grant Permission' will allow USB mass storage devices to be installed.  Selecting 'Deny Permission' will prohibit
the installation of USB mass storage devices.

IF REMOVING THIS POLICY: Reset to original setting and let policy propegate before deleting policy."
    PART "Change Settings:" DROPDOWNLIST REQUIRED
      VALUENAME "Start"
      ITEMLIST
       NAME "Grant Permission" VALUE NUMERIC 3 DEFAULT
       NAME "Deny Permission" VALUE NUMERIC 4
      END ITEMLIST
    END PART
  END POLICY
END CATEGORY

 

2.) Open a group policy management console, and right click on "administrative templates" under "Computer Configuration". Select "Add/Remove Templates".

 

3.) Browse to the text document you just saved and click OK. You'll now see "Custom Policies" under "Administrative Templates". Right click on it, select "View", then select "Filtering". Uncheck the bottom box, labeled "Only show policy settings that can be fully managed".

 

4.) Click ok. Now you'll see the USB policy available for use under the custom policy heading. From there, you can enable or disable it just like any other policy.

[Geoff]

Well no. Normal users can install drivers. At least here they can't.

[MkII]

It means that we don't have to have any restrictions on the workstations whatsoever.

You still need all protection from the no 1 threat, that is access to sensitive data. This is the main reason for policy lock down. Destruction of the local PC is a concern, but I can't say i've ever really had a problem with that. My machines just get re-built as software sets change.

[sahmeepee]

we do by fact that we run rm here...

 

what they have done is allowed programs to run from program files with out a problem but students cant access program files dir etc...

 

then also if want to run exe outside of that addem to list of allowed files and paths..

 

russ

 

This seems like the sanest approach. Let any program run on C:\ (say), but everything else is restricted. Then deny them access to browse the C:\ drive using group policy. (you could go tighter and allow only "c:\program files", but there's bound to be some piece of educational software written circa 1992 that you have to put in c:\ because it hates spaces in paths)

 

Obviously if you need to run apps from windows shares etc., you can just add them to the path rule in software restrictions, but just make sure they can't write to anywhere they can execute from.

[ajbritton]

Hmmm ... Isn't it a bit risky allowing execute from C:\.

All the users temporary internet files are likely to be on C:\.

The %temp% folder will be on C:\

 

Even denying access to browsing C:\ does not prevent a clever user who has found a way of getting a file into his/her temp folder from executing it.

[NetworkGeezer]

Hmmm ... Isn't it a bit risky allowing execute from C:\.

All the users temporary internet files are likely to be on C:\.

The %temp% folder will be on C:\

 

Even denying access to browsing C:\ does not prevent a clever user who has found a way of getting a file into his/her temp folder from executing it.

 

I don't see the problem if all EXEs are restricted to running from Program Files and Windows and perhaps exceptions for other paths (as for the pre 1992 apps) thenn %temp% isn't issue.

 

Is there some way of using temp to graft a abitrary folder so that it appears to be path of the permitted paths?

[ajbritton]

@NetworkGeezer: I was really referring to sahmeepee's suggestion that any program be allowed to run from C:\ (and therefore anywhere on C: drive unless specifically exempt)

[sahmeepee]

@NetworkGeezer: I was really referring to sahmeepee's suggestion that any program be allowed to run from C:\ (and therefore anywhere on C: drive unless specifically exempt)

 

Yeah, sorry if my post was a bit offhand. You'd obviously have to look very carefully at this. You could specifically disallow temp and your browser's cache folder or block everything on C:\ then open it back up folder-by-folder.

 

It definitely takes planning and testing, e.g. you may have problems with blocking shortcuts in the users' docs&settings (e.g. their own start menu) from running if you get it wrong.

[ajbritton]

Well, I'm new to software restriction policies, but I reckon it's better to start with a bucket with no holes and drill 'em where you need 'em rather that a leaky bucket which you hope you've fully patched.

 

I've blocked everything and excpeted the following list (I'll have to update this later when I get to work)

 

(REMOVED LIST FOR SECURITY REASONS) - If you want to see my list, PM me and I will send it...

 

So far I've not had any major problems. (actually that's a lie, I forget to include the path to the server shre where all managed software is installed from, and that caused the occasional error)

If I get any apps which insist on running outside of Program Files, then it's a 2 minute job to add an extra path rule.

 

Maybe a WiKi on use of Software Restriction Policies is in order covering the set up and potential pitfalls.

[sahmeepee]

Looks good.

 

In that scenario, can the user (a normal user) drag an exe file into their start menu and then run it?

[Geoff]

Users dont have write access to their Startmenus here.

[ajbritton]

I need to do more testing. I've been re-reading the SRP reference on technet and noticed the following things

 

1 - Avoid environment variables as they can be redefined to point to a different location

 

2 - If .LNK files can be excluded from the list of extensions which are checked, then the executable will still be subject to the SRP. This would mean that the user profile would not need to be exempt from the restriction.

[ajbritton]

OK, testing with SRP complete.

 

I tried removing LNK from the lsit of extensions in the SRP for students, but shortcuts still failed. It turns out there was a machine based SRP in effect. Now I did not set this up so I assume it is there as a local machine policy in XP. The machine based SRP extension list was taking priority which meant that LNK files were still being blocked. I created my own machine based SRP and applied to an OU which covers all PCs that students will use, and removed LNK files. Bingo

 

In summary then here's my setup...

 

1 - Machine based SRP with LNK removed from extension list (otherwise no changes to defaults)

 

2 - Users based SRP as follows...

• Disallow all software by default
  
• Remove LNK files from extension list
  
• Default exemptions are sufficient to allow software installed under C:\Program Files to execute (limited users cannot write here)
  
• Add exemptions for logon scripts \\(fqdn)\sysvol
  
• Add exemptions for managed software installs \\(servername)\install
  
• Add exemptions for network apps M:\
  
• Add exemptions for an local apps not running from C:\Program Files (NB - Be as precise as possible!)
  

 

The only thing I have not done is a comprehensive analysis of the permissions on C:\WINDOWS to find any locations that limited users might have write access to e.g. C:\WINDOWS\TEMP. If these exist, then they would need locking down with additional exemptions.

[NetworkGeezer]

Good work AJ.

 

I assume for login script exemptions there is an entry for each DC hosting Active Directory.

[ChrisH]

This should cover that:

 

Add exemptions for logon scripts \\(fqdn)\sysvol

[Gatt]

Add exemptions for managed software installs \\(servername)\install

 

Managed software is installed as the "SYSTEM" user so you shouldn't need to specify this as its installed during login before the users desktop is displayed.

 

Then again, my Managed software is assigned to the computer and not to the user... so this may have a bearing on it.

 

Now if only I can find a way to stop the darlings from rebooting the PC cos they cannot be arsed waiting for the software to install - like they did with the install of Service Pack 2!!

 

And then had the nerve to come to me and say their PC wasn't working!

[ajbritton]

Good work AJ.

 

I assume for login script exemptions there is an entry for each DC hosting Active Directory.

 

As ChrisH has pointed out, the \\(fqdn)\sysvol (eg. \\your.domain.name\sysvol) entry should cover logon scripts, unless you are using the old fashioned ones under NETLOGON. If so, then you might need to add extra exemptions on a per DC basis, I'm not sure. If you are using NETLOGON and don't want to add individual exemptions per DC, you could try \\your.domain.name\netlogon, which works if you browse to it.

[ajbritton]

Managed software is installed as the "SYSTEM" user so you shouldn't need to specify this as its installed during login before the users desktop is displayed.

 

True, but some managed software (yes, I do machine assigned installs as well) seems to needs to access to the source MSI when run for the first time on a new profile (e.g. Office first run which sets up some user registry stuff I think). I think this is 'self repair'!

 

In theory, all MSI's are cached in %SystemRoot%\Installer, but as I said, when I tested, at least one piece of software want to go back to the source, and presumably in the security context of the logged on user because SRP blocked it.