[gptalk] Re: Office Blockage...
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Wed, 23 Jul 2008 10:59:00 -0700
Deepu-
You will be hard pressed to find a perfect solution for every scenario you
have. Security is a combination of elements. You need to ensure first that
users are not administrators on their workstations. Next, you need to ensure
that the file system and registry are as secure as possible, so that it is
difficult for the user to move things around or change things to their
liking. Finally, you need to control what code is installed and run on a
system. Each of these lines of defense requires a fair bit of work and even
then, if your users need to run a lot of applications as a function of their
job, you will find it hard to reach your goal.
But, for the purposes of this discussion, let's try to get you closer. First
off, is cmd.exe allowed to run? If not, then scripts won't run. Also, when
you create SRP policy, MS adds some default registry path rules that
basically allow core Windows components and anything in Program Files to
run. Did you leave those rules in place or delete them?
If you want to control what the user can run, but, as you say below, "it's
not feasible to block all exe's as user may have to install some files or
they may need some exe to run externally..." then you are cross-purposes to
your goal. If the user can install code willy-nilly and that's ok, then you
will never be able to successfully control what they can do.
At this point, you might want to look into 3rd party products that perhaps
have more flexibility than SRP. For example, while I haven't used it, I know
that Bit9 (www.bit9.com) helps in this area.
Darren
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Deepu
Sent: Wednesday, July 23, 2008 10:47 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Office Blockage...
Hi Darren,
Even after removing the vbs and cmd extension. We can't run cmd
files.
Let's assume even if starts working. it's not feasible to block
all exe's as user may have to install some files or they may need
some exe to run externally...
So using this method will be a problem for us...
Also let me know why the script is not running even after removing
the cmd and vbs extension...
Thx...
On Wed, 23 Jul 2008 Deepu wrote :
>Hi Darren,
>
>I have even tried the whitelist mode. But doing so blocks all exe
>and even it doesn't allow to run vbs (scripts) which are
>necessary to run.
>
>There may be some exe's which user should run.. So, allowing this
>policy doesnot works...
>
>Thanks...
>
>------------------------------------------------------
>
>On Wed, 23 Jul 2008 Darren Mar-Elia wrote :
>>Deepak-
>>Have you considered using Software Restriction Policy in
>>whitelist mode?
>>That is, set the default level to disallowed and then only allow
>>a specified
>>pre-approved set of executables?
>>
>>Darren
>>
>>-----Original Message-----
>> From: gptalk-bounce@xxxxxxxxxxxxx
>>[mailto:gptalk-bounce@xxxxxxxxxxxxx] On
>>Behalf Of Deepu
>>Sent: Wednesday, July 23, 2008 7:39 AM
>>To: gptalk@xxxxxxxxxxxxx
>>Subject: [gptalk] Office Blockage...
>>
>>Hi Friends,
>>
>>I am in a great problem. I would really appreciate if anyone
>>can
>>help me at the earliest:
>>
>>Problem: I want to block some executables like access.exe,
>>publisher.exe and communicator.exe using group policy.
>>
>>Now the problem is i can't use Software Restriction Policy
>>using
>>hash rule as the hash will change everytime microsoft patches
>>or
>>release service pack for office 2007.
>>
>>Secondly if i use Software Restriction Policy using path rule.
>>The
>>user can simply copy the exe to alternate location and can run
>>the
>>program with ease.
>>
>>So,i would really appreciate if anyone can help me to solve
>>this
>>issue, as the user can't open the above mentioned exe from
>>anywhere. I want to implement it using group policy. A custom
>>ADM/ADMX will also work... Please guide me if possible...
>>
>>Waiting for your reply...
>>Deepak Kumar...
>>India...
>>
>>***********************
>>You can unsubscribe from gptalk by sending email to
>>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>>field OR by
>>logging into the freelists.org Web interface. Archives for the
>>list are
>>available at //www.freelists.org/archives/gptalk/
>>************************
>>
>>***********************
>>You can unsubscribe from gptalk by sending email to
>>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>>field OR by logging into the freelists.org Web interface.
>>Archives for the list are available at
>>//www.freelists.org/archives/gptalk/
>>************************
>
>***********************
>You can unsubscribe from gptalk by sending email to
>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>field OR by logging into the freelists.org Web interface.
>Archives for the list are available at
>//www.freelists.org/archives/gptalk/
>************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
Other related posts:
