On Thu, 2005-11-10 at 22:59 -0800, 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?
Services running as LocalSystem are a security hazard, but the general permissiveness of services running as privileged accounts is (although particularly bad in windows) not solely a windows problem - many services in linux (depending upon the distribution) run as root - on an ubuntu linux system, I can see acpid, powernowd, sshd, sdpd, cron, and several gdm/X-related processes, all running as root - and this is a system on which I've stopped and removed 'unnecessary' services. This is something doesn't do particularly well either - there's no reason that a process relating to bluetooth (sdpd), really, should be running with permissions to load and unload kernel modules, add and remove user accounts, access raw block devices, etc. Even processes running as their own user (such as dhclient) are still running as a user account (dhcp) with permissions allowing them to execute arbitrary files on the host in question, a fact which coupled with a privilege escalation vulnerability could quite happily yield a malicious intruder root access in an instance which could have been mitigated by more restrictive permissions on an app, even if the same bug (remote code execution) existed. You could argue that linux is a step ahead of windows in this respect in that the fact that we have a dhcp user, a www-data user, etc, is superior to LocalSystem, but progress in adding capabilities to the linux kernel to *properly* restrict service accounts (or using DACLs to alter the permissions on.. ooh.. the entire filing system) so that my DHCP client can't run arbitrary executables from /*/bin seems to be exceptionally slow. We're not all running everything as root, but without weeks of effort and considerable expertise. This can also be no mean feat for anyone who has a distribution which doesn't support Linux Access Control Lists or who doesn't know they exist - very few linux administrators I've encountered actually use these, and without them locking down the filing system is really quite hard. If only I had a penny for every group I'd created in accomplishing this in the past... ;) Again, although windows doesn't do this spectacularly well at the moment, this is one issue which Vista seems to be attempting to address: Quote from http://tinyurl.com/aww4r (microsoft.com): > Windows Service Hardening reduces the damage potential of a > compromised service by introducing new concepts which are used by > Windows services: > > Introduction of a per-service security identifier (SID). > > Moving services from LocalSystem to a lesser privileged account such > as LocalService or NetworkService. > > Stripping of un-necessary Windows privileges on a per-service basis, > for example the ability to do debugging. > > Applying a write-restricted token to the service process. [...] Write > attempts to resources which do not explicitly grant the Service SID > access will fail. > > Services are assigned network firewall policy, which prevents network > access outside the normal bounds of the service program. The firewall > policy is linked directly to per-service security identifier (SID). Write-restricted tokens, per-service SIDs, and stripping of privileges would all go very far towards addressing the criticisms you've levied. > 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) Wherever possible, our services run under their own accounts, and there's a very simple process (as far as I'm concerned) for vendors who are un-cooperative in allowing customers to run their software under restricted accounts - not buying their software in future. > 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? Obviously, fixing localsystem isn't the answer, moving to separate user accounts is - even if you lock down localsystem to the point at which it has no permissions required for your services not to run, your DHCP Server still has permissions that your DNS Server requires, your DNS Server has permissions required for your IIS Installation, etc. > 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. - James. --------------------------------------------------------------------------- ---------------------------------------------------------------------------
