Skip to content

January 20, 2012

Deployment Blocker No. 3: Fiddle with System Permissions

by Shelly Bird

Some customers want to play around with system file permissions and lock their computers and servers down even further, often using guidance that is decades old, built for another operating system.  As mentioned before in Deployment Blocker No. 5:  Separate partitions for applications and/or data blog, unless it is specifically recommended by the manufacturer of the Operating System, changing default system permissions is generally not a good idea.  Usually these types of lockdowns emerge from an overzealous security team, but we’ve seen plenty of Operations folks get into this bad habit as well.

There are a number of other problems with getting creative with file permissions, beyond what the manufacturer of the operating system agrees is supported and necessary.   For Windows, consult with Microsoft Premier, the support arm of Microsoft’s Services groups.  Many of them are Tier III engineers who are tied at the hip to Microsoft Product Groups.   Premier has on some occasions told my customers they need to  wipe and load all their desktops if they are to get support, otherwise the only thing Premier can do to resolve reported problems is “best effort”.  That can be painful for everyone.

Here are just a few of the issues which deployment consultants and I have seen directly impact a deployment once permissions were changed too aggressively:

  1. Group Policy fails to apply.  A customer had added file permissions that affected the area into which Group Policy applied the user’s local settings.  We’ve also seen some cases where the volume of file permission changes are so great, logon times become unacceptably long.
  2. Applications fail.  An application works on the system without the customer’s creative file permissions, but fails on the locked down system.  In some cases, I’ve seen the customer’s field personnel throw their hands up in frustration and change the critical folder Program Files to give Everyone Full Control.  Whoops. Now it’s less secure than it was out of the box.
  3. Major services fail to start. We’ve had a wealth of problems with servers, among others, where the services were shut down by the new permissions or operated poorly.  Among the problems we’ve seen:  replication chokes and web services that won’t start.

The Better Way:  Don’t do it.  The kinds of headaches these cause are simply not worth the effort.  Ask your team what their justifications are for making such changes.  Consider whether your organization is willing to toss out the years of testing done by Microsoft in their Application labs with thousands of COTS applications, testing which was done to make sure these out-of-the-box security permissions and settings do not cause application compatibility issues.  Keep in mind the current security model was developed after a great deal of feedback  from security standards bearers out there, who get early looks at the operating system.  They have already worked and continue to work to identify potential target vectors so Microsoft can close them off, and second guessing is likely to open more holes than it plugs.

This is part of a ten part series of blogs “Top Ten Deployment Blockers”

Advertisements
Read more from Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: