Re: More before-the-fact advice for 2K and XP?
From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: Wed, 15 Dec 2004 07:43:12 -0700
An interesting set of customizations. Once the majority of
Windows users do run as limited users, you may be correct
that we will see more malware that vectors in within that
context and then mounts priv elevation exploit against known
vulnerabilities leveragable by a locally logged in limited user.
Did you only accidentally not mention the temp folder ? the
ability to support .Net assemblies dynamic compile and run ?
and the need to verify what any software installer may have
done relative to new folders and/or ACLing of existing folders
before such software is validated for installations ? etc..
While I agree that Windows could more effectively facilitate
you objective, which seems to be making a clean separation
between where a limited user may write from where a limited
user may execute, it is not really there yet. Windows has been
drawing closer with each release in effecting a manageable
separation, but IMO it is not there yet and the reasons in cases
come down to issues that the admin also cannot easily deal
with by adjustment of ACLs.
-- Roger Abell Microsoft MVP (Windows Security) MCSE (W2k3,W2k,Nt4) MCDBA "Gordon Fecyk" <email@example.com> wrote in message news:eGXxVrl4EHA.1976@TK2MSFTNGP09.phx.gbl... > I'm consulting for several firms who are using Win2K and XP Pro as limited > users, which so far is keeping the current crop of viruses and other garbage > off the machines. Hardware firewalls do the rest. > > I believe future exploits will be deliberately designed to run as a limited > user. That means a trojan, or virus or what-have-you will work only while a > specific user's logged on to the machine. But it will still run. It > wouldn't need to take advantage of raw sockets, UPnP or other "supposedly > dangerous" technologies to do its dirty work. > > So the question I ask is, how to prevent unauthorized software from running > even as the limited user? Here are the things I've ruled out so far: > > * Signed programs are difficult to maintain. A lot of sites use old apps > that can work as a limited user, but aren't digitally signed. And nothing > stops a disreputable company with a code certificate from writing a bad > program that happens to be signed. > > * "Outbound firewalls" are an annoyance to the average user, because they > warn you about every single little applet that wants network access. That > includes the Windows Firewall when you enable outbound connection > monitoring. Besides, it's one more thing that runs in the background using > up CPU time that a useful app can use instead. And they don't stop bad > programs that use file system APIs instead of network APIs to spread. > > * I would love to see "ZIP file type restrictions" in the Compressed Folders > shell extension for Windows XP. Like the attachment restrictions built into > Outlook 2002 and later, I could disallow opening certain file types from > within ZIP and other archive files. There's no such functionality yet, so > I've had to block ZIPs as "level 1" and allow "level 2" access only to > people I've trained in handling ZIP archives safely. This sucks because > even a trained user can make mistakes. > > * I already change the security ACLs for the root of Drive C to read-only > for limited users, and apply special ACLs to the "RECYCLER" folder so > limited users can still create and use Recycle Bins. I borrowed the same > ACL for "Shared Documents" to accomplish this. The only folders that need > to be on the root of Drive C are "Documents and Settings," "Program Files," > "Windows," and "RECYCLER." And these folders (except for RECYCLER) have > default ACLs that are perfect for before-the-fact security. I also create a > separate volume exclusively for the paging file and make that unreadable to > limited users entirely. > > Which comes to my latest idea which I have no clue how to implement: Deny > (or remove) Execute permissions by default to Documents and Settings for > limited users. I don't know how to implement this because I don't know > where the default ACL for a user's profile is stored. Whatever it is, it's > normally "Full Control" for the user. There's also the matter of setting up > the same or similar ACL for whatever the user's Home directory is (on an > Active Directory network) or their Profile directory (also on AD). > > Even if there were an ACL template I could change, I'd have to change it in > three places: for the user's local profile, the user's roving profile (if > any) and the user's home directory (if any). > > If this were possible, it would eliminate last remaining problem I can > figure out: How to keep limited users from running unauthorized programs > for good. A privilege elevation exploit won't work if it can't run in the > first place. > > -- > PGP key (0x0AFA039E): <http://firstname.lastname@example.org> > What's a PGP Key? See <http://www.pan-am.ca/free.html> > GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4> > >