And the minute you do this is when "I" the admin take responsibility for
testing and it's no longer a "buggy patch" but an issue of a "buggy
admin" not doing their job and testing the changes they made.
I [hope anyway] I have full understanding of what I am doing and full
understanding that Intuit will no longer support me in this condition.
If the vendor is not willing to code appropriately, and the marketplace
has yet to realize how 'legacy' they code, sometimes one chooses to hack
up the app and take the risk. The alternative is local administrator or
power user rights on that desktop which has it's own risks.
Jim Harrison (ISA) wrote:
Unfortunately, this sort of behavior is also what caused many of the
failures for 05-051 and necessitated the follow-on KB for restoring
permissions to the %windir%\registration folder and contained .clb
packages.
Remember; all MS code is tested in the context of OOB deployment and
MS-published security guidelines. The minute you step out of those
boxes, you're taking some not-so-insignificant risks upon yourself and
your customers.
Luckily, the recommendations made therein are limited to folders and
registry entries specific to QBP, so they don't raise too many hackles,
assuming you limit local & remote access to that machine for trusted
users only. I'd hate to see your customer's financials get sold to the
highest bidder for all those changes...
Jim Harrison
Security Platform Group (ISA SE)
If We Can't Fix It - It Ain't Broke!
-----Original Message-----
From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
[mailto:[EMAIL PROTECTED]
Sent: Friday, November 11, 2005 11:24 AM
To: matthew patton
Cc: [email protected]
Subject: Re: What server hardening are you doing these days?
QuickBooks Community - Running QuickBooks 2005 as a Restricted User
(Admin Rights FIX):
http://www.quickbooksgroup.com/webx?14@@.eeb323b/9
We throw vendor documentation in the trash all the time and hack
registries and hives.
matthew patton wrote:
ok, seems I need to clarify since several people have responded with
their bookmark collection of tips, cheats, workarounds, papers, etc.
etc. etc.
While not having looked at all of them, the point is none of them has
bothered to address the basic, out of the box faults of the windows
filesystem permissions, nor the culture of permissiveness that
permeates all things windows. It's one band-aid after another.
LocalSystem isn't 'root'. It's similar in some aspects, but I can
trash
an NT box by denying LocalSystem permissions to certain files. I can
lock out the Administrator likewise. The point is not that there
aren't
a zillion different guides to living "more safely" with windows. The
point is that on a most rudimentary level, when you start with
LocalSystem having Full Control over the entire disk and there is NOT
ONE reason for it to be that way, you have a situation where security
wasn't thought thru. IIS has no business running as LocalSystem for
example. It should be fully capable of running as a 'normal' user with
maybe a couple of special privs attached. The concept and
implementation of 'sudo' has been around for what, more than 10 years?
How many of you throw the vendor documentation in the trash and
actually make the product run as an unprivileged user? Say Oracle? or
ColdFusion, or WEbsphere, BEA, etc? Think about it. You have all these
operating system components, 3rd party "daemons", and who knows what
all running as the same user. And said user has full control
permissions to practically every file on the disk. So what that maybe
there are 30% fewer buffer overflows in the unholy number of millions
of lines of code. If the filesystem/registry permissions are such that
LocalSystem can't do jack, I don't care so much if there are glaring
problems. (not to imply I condone sloppy coding)
I have yet to find a guide that actually spelled out the REAL
permissions needed for LocalSystem. It needs 'read' to pieces of the
%system% tree and 'write' to a couple of files but that's it. Mention
to Microsoft that you've wholesale mucked with their "anything goes"
permission set and they have a coronary and disavow any notion of
support. Why is that? Are they ignorant about what their own product
actually needs? Where is the security team that has gone thru and
redefined all permissions to what they should be and told the
programmers to go back and fix their code?
The filesystem is the easy one. I don't have the interest or the time
to bother with the registry though in some respects that's probably
more important.
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------
