Re: SUS/WSUS & Software Restriction Policies

From: DJ_Chiro (dj_chiro_at_hotmail.)
Date: 07/28/05


Date: Wed, 27 Jul 2005 19:43:43 -0400

That is a good idea but I wonder if all MS executables are signed?

As for the other statement, I agree with you 100%. I made that point across
before I was told to go ahead with the implementation. It basically came
down to the fact that if we catch someone circumventing the policy they will
have no "excuses" as to why they are running unauthorized apps. In the past
the regulations always stated strict penalties but nobody acted on them and
the users made up bogus excuses. We are all adults and it is basically a
trust thing and if someone wants to mess around they will suffer the
consequences.

Thanks for your input...

"Oli Restorick [MVP]" <oli@mvps.org> wrote in message
news:OBFxTyskFHA.3260@TK2MSFTNGP10.phx.gbl...
> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>