Re: SUS/WSUS & Software Restriction Policies

From: Oli Restorick [MVP] (oli_at_mvps.org)
Date: 07/27/05


Date: Wed, 27 Jul 2005 17:59:35 +0100

Hi there

I wonder if allowing all executables signed by Microsoft would be an
acceptable solution. I haven't tested this, but I think it could work.

I find the notion that you allow free administrative access to workstations,
but apply a software restriction policy mildly amusing. What's to stop
these administrators removing or overriding your software restriction policy
locally, and running unauthorised applications? Sure, Group Policy will
place the policy back after (by default) 90 minutes plus or minus 30, but
they can still do it.

Oli

"DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
news:OG6iqwfkFHA.1440@TK2MSFTNGP14.phx.gbl...
> You obviously don't understand my environment and the level of security we
> require here, the DoD would not take your answer for 1 minute. Thanks for
> your .02 but Software Restriction Policies DO work and when setup properly
> the machine will run without a problem.
>
> I do understand all the items you have listed (minus the dozen other
> "elements") and quite frankly they do not apply. You see, SRP is designed
> to prevent a lot of the things you have mentioned. I have my desktops
> working fine besides this SUS issue due to the randomly generated folder
> name created when a patch is installed. With my in-depth understanding
> of the items you listed, I have been able to create a ruleset GPO that
> allows the OS to function and the APPROVED apps to run. I have not had a
> complaint from not one of my 1200 users which tells me I have implemented
> SRP successfully.
>
> I have decided to push forward with WSUS ahead of my plans to rememdy this
> situation. Not worth the time trying to work around an issue like this
> when SUS is going to be replaced anyway.
>
> Cheers!
>
> "Lawrence Garvin" <onsitechsolutions@news.postalias> wrote in message
> news:%23VLsXefkFHA.1464@TK2MSFTNGP14.phx.gbl...
>> I'll throw my .02 in here as well.
>>
>> The policy is /TOO/ restrictive.
>>
>> Furthermore, it causes more problems than it can possibly solve.
>>
>> "Locking down" a workstation to the extent being attempted requires an
>> in-depth understanding of the operation of various aspects of the
>> operating system, update methodologies, application installation
>> processes, and a dozen other elements.
>>
>> My best suggestion is to /REMOVE/ the policies, and let the system do its
>> job of protecting itself with the provided security tools.
>>
>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> wrote in message
>> news:emPY%23DekFHA.3148@TK2MSFTNGP09.phx.gbl...
>>>I have it posted in 4 groups... just included them all in this reply.
>>>
>>> My users are all local admins so doing that would null the whole policy.
>>>
>>>
>>>
>>>
>>> "woef" <woef20@hotmail.com> wrote in message
>>> news:%23RN5IPckFHA.1868@TK2MSFTNGP10.phx.gbl...
>>>> maybe a question for this newsgroup
>>>> microsoft.public.windows.server.update_services
>>>>
>>>> "RodeCa" <rodeca@terra.BASURA.es> wrote in message
>>>> news:%23%23ZJIKckFHA.1948@TK2MSFTNGP12.phx.gbl...
>>>>>I think all these EXE run as SYSTEM or as Administrator (else, they
>>>>>wouldn't run at all: my users don't have right to install anything).
>>>>> So, Could you set your policy to allow SYSTEM and Administrators to
>>>>> run from any path?
>>>>>
>>>>> --
>>>>> HIH
>>>>> RĜ
>>>>>
>>>>>
>>>>> "DJ_Chiro com>" <dj_chiro@hotmail.<DOT> escribió en el mensaje
>>>>> news:eyzYxMSkFHA.2152@TK2MSFTNGP14.phx.gbl...
>>>>>> Thanks for the response Asher
>>>>>>
>>>>>> I agree my policy is VERY restrictive; but it was ultimately not my
>>>>>> decision to lock them down this much. Needless to say, I have
>>>>>> tweaked the policy so that only approved applications run. I have
>>>>>> 1200 users able to do their work as if there is no policy at all.
>>>>>> Bottom line is if they are doing their work, they shouldnt have any
>>>>>> problems :)
>>>>>>
>>>>>> Migrating to WSUS is in my plans but I need more time to setup a test
>>>>>> server.
>>>>>>
>>>>>> Anyone else have any ideas?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I do plan to migrate to WSUS shortly
>>>>>> "Asher_N" <compguy666@hotmail.com> wrote in message
>>>>>> news:Xns969E65D67908compguy666hotmailcom@207.46.248.16...
>>>>>>> "DJ_Chiro" <dj_chiro@hotmail.<DOT>com> wrote in
>>>>>>> news:uLKb3mRkFHA.1480@TK2MSFTNGP10.phx.gbl:
>>>>>>>
>>>>>>> My first thought is that your policy may be a bit too restrictive.
>>>>>>>
>>>>>>> Anyway, consider moving to WSUS. It deposits all the updates in
>>>>>>> sub-dirs in
>>>>>>> a structure inside the windows dir. You can then have your policy
>>>>>>> allow
>>>>>>> execution of anything under that sub-dir.
>>>>>>>
>>>>>>>
>>>>>>>> Hello all, here's a good one!
>>>>>>>>
>>>>>>>> I am running SUS and software restriction policies on my domain.
>>>>>>>> Problem seems that any patches that are approved get downloaded and
>>>>>>>> run from a randomly generated directory off the C drive. My
>>>>>>>> software
>>>>>>>> restriction policy is locked down with ONLY the know file paths
>>>>>>>> added
>>>>>>>> to the rules list. i.e I have c:\program files locked down only
>>>>>>>> allowing certain sub dirs to run.
>>>>>>>>
>>>>>>>> I notice the initial file getting blocked is update.exe. I allow
>>>>>>>> this
>>>>>>>> file to execute only to find another one blocked... I dont want to
>>>>>>>> have to make exceptions for every file in every future update. Any
>>>>>>>> to
>>>>>>>> make matters even more fun it seems the folder name where the
>>>>>>>> patches
>>>>>>>> are extracted to is a randomly generated name that changes EVERY
>>>>>>>> time!
>>>>>>>> Is there any solution for this? I can't imagine MS not allowing
>>>>>>>> these two great features to not play nice together!
>>>>>>>>
>>>>>>>>
>>>>>>>> First error:
>>>>>>>> Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has
>>>>>>>> been
>>>>>>>> restricted by your Administrator by the default software
>>>>>>>> restriction
>>>>>>>> policy level.
>>>>>>>>
>>>>>>>> After allowing update.exe I get:
>>>>>>>> Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has
>>>>>>>> been
>>>>>>>> restricted by your Administrator by the default software
>>>>>>>> restriction
>>>>>>>> policy level.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



Relevant Pages