Software Restriction Policies... AGAIN

[azrael78]

Morning all,

I've been tasked with getting SRP working properly.
I've taken the 'blacklist/deny' approach (where everything is permitted EXCEPT what we deny).

I'm sure that doing it the other way (where everything is denied...) is just as good but I can count on my fingers what we don't want the kids to get at.

So...

I have several path rules setup - some set to deny and some set to permit.
Now here's an example...

B:\ - Deny (USB Drive Letter)

Now I can open all office docs here EXCEPT MSAccess MDB Files by double-clicking.

On the MDB files it says it's blocked, however MDB does not appear in the 'designated file types' list and even if I put it there, it makes no difference.

So... B:\*.mdb - Permit

This works provided the MDB is in the root folder, it doesn't work if that MDB is anywhere else on B:.

So am I doing something stupidly wrong with this or am I missing something obvious?

I will post the full configuration in a bit, gotta do a bit of early-morning fire-fighting first but any suggestions in the mean time would be great

Az

[Michael]

I'm a little confused, do you want to allow drive letter B:\ or deny it? As you said:

B:\ - Deny (USB Drive Letter)

Which I presume means you want to deny access to B:\ but you can still open all Office related documents.

SRPs are only recommended for allowing or restricting file paths and not drives as such. If you want to deny drives, using this method is recommended.

I've done it plenty of times, so if you need any help let me know. The value of the drive letters is as follows:

A - 1
B - 2
C - 4
D - 8
E - 16
F - 32
G - 64
H - 128
I - 256
J - 512
K - 1024
L - 2048
M - 4096
N - 8192
O - 16384
P - 32768
Q - 65536
R - 131072
S - 262144
T - 524288
U - 1048576
V - 2097152
W - 4194304
X - 8388608
Y - 16777216
Z - 33554432

You can manually create a file association with registry files. Take a look here. Hope this helps!

[azrael78]

Michael,

I want to stop the kids running undesirable file types from USB sticks.

Hence why I've got B:\ as a denied path (that's the drive letter for USB sticks).

But I still want to allow them to open office documents from B:\.
What I don't understand is why it's denying MDB files - when it shouldn't be.

They need to be able to 'see' B: drive and read/write to it but I don't want them running things from it.

Az

[ZeroHour]

Cant you just use *.mdb to whitelist the type?
mdb's I think are part of the defaults you dont see that are blocked.

[azrael78]

I've just tried that one ZH - unfortunately the PC on which I'm trying this REALLY HATES SRP for some reason, if I update the policy, I have to disable the link, reboot the PC, enable the link and then reboot it to make it work.

It's driving me crazy (well, crazier)

Az

[SYNACK]

I'm sure that doing it the other way (where everything is denied...) is just as good but I can count on my fingers what we don't want the kids to get at.

Default permit is not a very good security model overall, its easier at first but does not hold up very well to new threats, in comparison the other method is much more secure. Have a read of this site: The Six Dumbest Ideas in Computer Security which has a very good write up on the differences.

[Michael]

It's a little strange that *.mdb files, which should be associated with MS Access are being blocked as you say.

And as for Software Restriction Policies requiring multiple reboots, I've found this too. Not quite sure why, but at least it works (which is the most important thing).

I think the problem 'might' be to do with designated file types. On the server, chances are you may have Word and Excel Viewer installed, but as far as I am aware, there's no such thing as Access Viewer.

Try administering your SRPs from a workstation (using MMC) which does have MS Office installed (so the *.mdb association is created). You may want to install the Server 2003 SP2 Admin Tools and GPMC on your admin workstation.

[azrael78]

Default permit is not a very good security model overall, its easier at first but does not hold up very well to new threats, in comparison the other method is much more secure. Have a read of this site: The Six Dumbest Ideas in Computer Security which has a very good write up on the differences.

I understand what you mean perfectly and you are absolutely right, however I don't feel confident enough to hit 'deny all' and then permit little bits, I'd rather do it this way until I'm comfortable with how SRP works exactly.

I'm the only one in a team of 4 who has any idea about AD and how it works, so I like to take things slowly when I'm unfamiliar with something like this.

I'd rather allow too much and have to lock down, than lock down too much at this stage - but I will take your suggestion onboard and will be looking at SRP (assuming it works well this time around) and will be working on the premise of 'deny all but' rather than 'allow all but'

It's a little strange that *.mdb files, which should be associated with MS Access are being blocked as you say.

And as for Software Restriction Policies requiring multiple reboots, I've found this too. Not quite sure why, but at least it works (which is the most important thing).

I think the problem 'might' be to do with designated file types. On the server, chances are you may have Word and Excel Viewer installed, but as far as I am aware, there's no such thing as Access Viewer.

Try administering your SRPs from a workstation (using MMC) which does have MS Office installed (so the *.mdb association is created). You may want to install the Server 2003 SP2 Admin Tools and GPMC on your admin workstation.

Got all that on my admin workstation - what I found is that an XP SP2 PC that has never seen SRP before updates just fine from the AD and is okay - but one that has seen it needs ALOT of reboots and to my way of thinking that's stupid.

But I just tested my SRP setup on a new VM and it works fine - as no other PCs on site (except my original testing PC) have seen SRP, I'm hoping this will all work out.

I'm using *.MDB and then blocking B:\.
It gives me the desired result I wanted

Az

[ssiruuk2]

I would seriously consider restarting from scratch and set it up again with denying everything as default. All you have to do then is allow your individual apps and where scripts etc run from. Job done. Every time you add an application you just create a new hash value or path rule. Default permit is pretty useless to be honest.

[azrael78]

Okay, it's sorted.

It turns out the stupid machine was just taking an age to re-read the policy from the DC, despite the fact it's been left alone and nothing has been stressed out.

No errors in the eventlog - no nothing.

But explain something - for those of you who use 'deny all but' rules - the designated filetypes - these are blocked or permitted?

In my 'allow all but' rule, the filetypes are blocked unless I've made a huge mistake somewhere.

Az