Re: More before-the-fact advice for 2K and XP?
From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 12/18/04
- Next message: S. Pidgorny
: "Re: EAP types" - Previous message: Paul Mars: "Re: virus? At who's end?"
- In reply to: Gordon Fecyk: "Re: More before-the-fact advice for 2K and XP?"
- Next in thread: Gordon Fecyk: "Re: More before-the-fact advice for 2K and XP?"
- Reply: Gordon Fecyk: "Re: More before-the-fact advice for 2K and XP?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 17 Dec 2004 20:03:46 -0700
"Gordon Fecyk" <gordonf@pan-am.ca> wrote in message
news:ehD1Ll54EHA.1404@TK2MSFTNGP11.phx.gbl...
> > I believe you keyed in too much on the first mention of temp
> > folder. That was a standalone comment.
>
> The temp folder in %systemroot%\temp was a nasty point of contention when
> Win2K SP4 came out. It tickled an obscure bug in an old app that took me
> weeks to hunt down.
>
> > Your biggest issue
> > is likely to be old apps that expect to use temp files in their
> > install dir.
>
> Or stores user settings in the install dir (Palm One, Netscape prior to
v7,
> All id Software games prior to DOOM 3...)
>
> With these, I grant Modify permissions to the Users local machine group
> currently. These vary wildly between clients so there's no standardized
> attack to take advantage. Of course there aren't any games on office
> machines (certainly not id Software games).
>
Yep, and so it is the campaign to let ISVs know that being
logo certified is a factor in the buying decision
> > The design of .Net is such that some things are no longer what
> > you expect relative to user account and filesystem ACLs.
> > Take a look at/in the special folder representation of the gac in
> > the filesystem at c:\Windows\assembly as an example.
>
> Actually, it looks like the ACLs in that folder are perfect for me[1].
> %systemroot%\assembly and its sub-folders are read-only to limited users
> already. At least on Win2K running .NET 1.1 SP1. It's inheriting the
ACLs
> from %systemroot%.
>
But - you need to take into account what account might write
into the area on behalf of the limited account
This gets back to paying attention to the CAS policies.
> Does the .NET dynamic compiler use the folder referred to by %temp% to do
> its work? Or does it use %systemroot%\assembly\temp and do its work as a
> privileged user? If it uses %systemroot%\assembly\temp then my changing
the
> default ACL for %userprofile% won't affect it. If it uses %temp% that
would
> be a problem.
>
AIUI there are different way to cache assemblies, the global aka gac
being but one. Aside from this the CLR can trigger .Net code that is
in its source form to be dynamically compilied. I am still in process
of unravelling just were things do get persisted and changes as we go
from v1, v1.1, to v2
> > Now
> > as I see it, if one effectively uses CAS Policies, you should
> > not run into issues; but, I wanted to mention that this brings
> > on a different world, since you obviously have done a lot of
> > leg work on this already.
>
> OK, .NET presents its own security problems and solutions which I can deal
> with through its own policies. At least I can worry just about its unique
> issues instead of Win32 Native issues that happen to occur around the .NET
> framework and file system.
>
> > For what it may be worth, from what I understand of the
> > future, things will be getting better in regard to this objective,
> > in fact much better.
>
> It can be much better right now, actually. I thought I wasn't asking for
> much - only leveraging the existing protection in the OS to my advantage.
Agreed. And, there are some issues more simple to tackle than others.
User workstations are more simple than say a Frontpage extended IIS
storage area. MS could have gone further, way back at W2k, but the
independent vendor pain would have been much greater. They then did
take further tightening step with XP/W2k3, and we see the laggard ISVs
(maybe) feeling the pain now. But, there are still loose areas, and MS
has indicated that one really really should give full control on the profile
of an account to that account. There is so much that dumps correctly and
incorrectly there that it is hard to understand just what one can get away
with before impacting something / some application.
> That's just part of the equation of course - using macro security in MS
> Office apps, attachment security in Outlook, ACLs in Windows and a
hardware
> firewall at the network gateway all work together to prevent problems
before
> the fact.
>
> It just seems like a trivial thing to specify a different default ACL for
a
> user profile. Maybe it's hard-wired into the source code somewhere which
> would make it not trivial (requiring regression testing, etc).
>
> [1] You can observe the ACLs by entering %systemroot%\assembly with a
> command prompt and renaming desktop.ini, then browsing the folder. Just
> remember to rename it back and reset its attributes (hidden) when you're
> done.
>
or just issue a cacls command for the folder
> --
> PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
> 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>
>
>
- Next message: S. Pidgorny
: "Re: EAP types" - Previous message: Paul Mars: "Re: virus? At who's end?"
- In reply to: Gordon Fecyk: "Re: More before-the-fact advice for 2K and XP?"
- Next in thread: Gordon Fecyk: "Re: More before-the-fact advice for 2K and XP?"
- Reply: Gordon Fecyk: "Re: More before-the-fact advice for 2K and XP?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
