That is part of the network admin's responsibilities -- to test updates so that they are consistent with his network environment. I consider it absurd to believe that Microsoft or any other company can test fixes (the term 'patches' connote a flaw [or perhaps a cat or dog], which isn't the case in most security related fixes, since the actual flaw is in the criminal, not in the software) against a virtually infinite number of software and hardware configuration. It isn't happening now, and it will never happen.
The bottom line, which works well not only in testing software updates is "trust, but verify". Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://spaces.msn.com/members/drisa/ Book: http://tinyurl.com/3xqb7 MVP -- ISA Firewalls **Who is John Galt?** > -----Original Message----- > From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] > [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 13, 2005 1:13 PM > To: Jim Harrison (ISA) > Cc: matthew patton; [email protected] > Subject: Re: What server hardening are you doing these days? > > 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. > >> > >> > >> > >> > >------------------------------------------------------------- > ----------- > >--- > > > > > >------------------------------------------------------------- > ----------- > >--- > > > > > >> > >> > >> > > > > > > > > -------------------------------------------------------------- > ------------- > -------------------------------------------------------------- > ------------- > > > --------------------------------------------------------------------------- ---------------------------------------------------------------------------
