Re: More before-the-fact advice for 2K and XP?

From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 12/24/04 

Date: Fri, 24 Dec 2004 12:08:11 -0700

Gordon,

I have not seen documented where the "template" for ACLing
new profiles is stored, or if it is hardwired. If it is stored it
is likely as a reg binary blob, the binary form of a SDDL spec.

I have never tried this, but I will assume you have tested
long-term with a profile without execute granted, and so
assuming that does work to your satisfaction . . .

Since in the initial state an account has full on its own
profile it has the ability to change its permissions, so
we can consider changing these in a login script.
This has the advantage of handling new profiles from
a fresh first-time login, something doing modifications
from a startup script does not.

So, if you can script the permissions change in a login
script you would have what you are after.

The tools cacls.exe and xcacls.exe with such as
(shown for a startup script) cannot do this however
cacls "%systemdrive%\Documents and Settings" /e /t /d Users:X
as the /d switch is only deny of full

But, xcacls.vbs can do this, a naive view making one think does it
cscript xacls.vbs "%systemdrive%\Documents and Settings" /e /t /d Users:6
http://www.microsoft.com/downloads/details.aspx?FamilyID=0ad33a24-0616-473c-b103-c35bc2820bda&DisplayLang=en
http://support.microsoft.com/default.aspx?scid=KB;EN-US;825751
would work (again shown in startup script form)

(btw I am not showing the /q switch one would actually use)

Now, the above actually does not work because it does not get
inherited onto the root of each profile as these have blocked
inheritance from their parent. IOW the /t does not actually do
a tree traversal applying the same delta at each, but relies on
inheritance to do so. So, you need to enumerate the folders
and execute this for each if in a startup script

So what about in login script form?
cscript xacls.vbs "%userprofile%" /e /t /d %username%:6;
OK, so that handles _part_ of the problem, and the account
does not have execute. But what if Users got granted access
to the profile in the future? So
cscript xacls.vbs "%userprofile%" /e /t /d Users:6;

The next issue wrong with the above is that one really needs
cscript xacls.vbs "%systemdrive%\Documents and Settings" /e /t /d Users:C6;C
in order to deny the permission to change permissions, but
interestingly if you test this you encounter a failure when it
tries to do the first directory within the first, since you no
longer have the permission to change permissions.
Trying in a login script has the same problem upon the recurse
cscript xacls.vbs "%userprofile%" /e /t /d %username%:C6;C

So, one needs to do this from a startup script by listing the
folders in Documents and Settings and then execute this for each
One is tempted (cd'd to Documents and Settings) to
for each folder in folders
    tmp = "xcacls.vbs """ & folder & """ /e /t /d Users:6 """ & folder &
""":C;C"
    wshShell.exec tmp
next
but that assumes the profile folder is correctly the account name,
which is of course not right for a renamed account. For that you
would need to chase the profile/account mappings in the reg.

Finally, one would need to revoke ownership if this vested
in the account of the profile instead of Administrators group.

Instead of installing the xcacls.vbs everywhere you might just make
a stripped down vbs that accomplishes the objective (xcacls.vbs
makes good reading on how to manipulate NTFS ACLs) and put
this in the DCs scripts directory.

It looks to me like you need both a startup script, to remove the
permission to change permission of the specific account, and a
login script to handle new profiles. I would as a first step in
modifying a profile write a null .txt file and set its permissions
so it will stay put, and then check profiles for this file and avoid
processing if present (else attempting to modify an already
modified is guaranteed to fail).

All very messy. 

-- 
Roger Abell
Microsoft MVP (Windows  Security)
MCSE (W2k3,W2k,Nt4)  MCDBA
"Gordon Fecyk" <gordonf@pan-am.ca> wrote in message
news:uOsMy9f5EHA.3084@TK2MSFTNGP10.phx.gbl...
> > Unless I'm mistaken, neither ActiveX nor BHO require Admin permissions
to
> > install.
>
> I'd like to see an example of this.
>
> > Also, a good portion of commercial spyware and adware may use
> > activeX controls or BHO, but viruses rarely do.  In either case, running
> as
> > non-admin does little to prevent any of this from getting on the
machine.
> > Some people say running as non-admin reduces the amount of spyware and
> > adware that gets installed on the machine; however, I find this hard to
> > believe, given that non-admins have a significant amount of control over
> IE
> > settings and the HKCU registry hive.
>
> How about a hundred users from two different clients not getting a single
> bit of spyware over two years?  Without traditional AV software installed?
> I haven't had to lift a finger to remove spyware from these machines in
all
> this time.
>
> Limited users never see the: "Would you like to install the (blah blah)
> control?" prompt.
>
> Now what I _have_ seen is what brought me to the whole default ACL
question
> in the first place.  I've seen applications installed using "Only for
> myself" settings (supported by Windows Installer), and items appearing in
> the user's Startup group through Javascript.  Also, new desktop icons,
home
> page changes, automatic manipulation of Trusted Sites, disabling the HTTPS
> requirement for Trusted Sites - these are all things that don't break the
> _machine_. I can always erase a user profile to correct the worst of these
> problems.
>
> > Last, note that if you're running as power user, you're not much safer
> than
> > if you were running as admin.
>
> I know.  I never recommend "power user" access.  Sometimes that means
> swapping Quickbooks for Simply Accounting.  Or foregoing the latest 3D
> shooter.
>
> > > White-lising executables doesn't work for long.  Nothing stops a user
> from
> > > downloading "unauthdapp.exe" and renaming it "iexplore.exe".
> >
> > Untrue.  White listing is usually done using file hashes, not file
names.
> > Any solution that doesn't do this is not a good solution.
>
> That was pre-2K anyway.
>
> Roger brought up how file hashes take a lot of CPU time.  I can throw more
> hardware at the problem but that's a LOT of binaries to hash (all those
DLLs
> in Office 2000 - ick).
>
> > > And nothing
> > > stops the app writer from signing it.
> >
> > This means nothing.  With executable white listing, the app doesn't just
> > need to be signed, but you must have approved the app.  White listing
> > doesn't usually rely on whether or not the app is signed.
>
> hm... this could work then.  Are 16-bit apps hashable?
>
> > As I said, I don't think you can do what you're trying to do without
> either
> > SRP or third party software.  This is pretty much true of any advanced
> > security countermeasures.  You have to choose what's more important to
> you:
> > using these countermeasures, or avoiding third party software.
>
> As long as the third-party software WORKS, that's fine.  Conventional AV
> software DOESN'T WORK anymore.  Neither do most spyware removers.  Limited
> user accounts seem to stop all spyware today - not to say it will continue
> to do so, but I'd like to prevent that possibility before they start
abusing
> limited user access regularly.
>
> > You're interested in using NTFS file ACLs and GP ACL templates to
prevent
> > execution of apps.  I'm pretty sure this can be done.  Have you tried
> > changing the ACLs on the Documents and Settings\Default User folder and
> the
> > HKEY_USERS\.DEFAULT registry key?  Or search for a hardened GP template
> that
> > someone else has provided that does the same things?
>
> "Default User" inherits its permissions from \Documents and Settings (read
> and execute for limited users).  Those permissions are completely ignored
> when Win2K creates a new profile - they are copied from there into a new
> folder that the user, the Administrators group and the SYSTEM user get
Full
> Control for.  NTUSER.DAT (HKEY_CURRENT_USER) gets copied verbatim and its
> internal permissions reassigned.
>
> >
>
http://www.google.com/search?q=default-user+profile+acl+documents+settings+execute
> > http://www.google.com/search?q=default-user+profile+acl
>
> I did these searches and others.  Lots of documentation on what the
defaults
> are, but nothing on how to change them.  Not even in Group Policy.  There
> are security templates for changing the default ACLs for everything else,
> however.  Unfortunately I can't specify %userprofile% the same way I
specify
> %systemroot% for instance, because the template editor goes and swaps
> %userprofile% with whatever that variable happens to point to at the time.
>
> Maybe I could hand-hack a security template to actually insert
%userprofile%
> there, but I didn't see a way to also specify the user as a variable
> (%username%) I'll give that a try.  Some time ago someone suggested a
login
> script entry that would adjust permissions on the fly (cacls %userprofile%
> /E etc etc) which could work but it would lengthen the logon process
> considerably, and it didn't seem to have all of the granular settings the
> GUI has.
>
> > Do note that those ACLs don't do anything to prevent running executables
> > from a floppy, CD, pen drive or added hard drive, so you would also want
> to
> > consider using other means to disable these drives.
>
> Already considered.  Most client machines don't have floppy drives or
CD-ROM
> drives, have removable devices disabled (no USB sticks), and CD-ROMs first
> evaluated before use.  Canada's PIPEDA act (enforced starting January
2004)
> proved a good reason to do all of this.
>
> > Nor do these prevent
> > running, say, VBA macros in Word documents, buffer overflows in image
> files
> > or PDF files, etc.
>
> Oh hell no, I didn't say changing ACLs was THE only thing to do.  It's
just
> one thing that's part of a much larger security solution:
>
> * Signed macro requirements in MS Office apps (aren't macro viruses dead
> tech nowadays thanks to this?)
> * E-mail attachment security in Outlook (Bye-bye Melissa and all her
> sisters)
> * Hardware firewalls (Blaster? Feh. Didn't phase us.)
> * ACL changes where appropriate (exploits don't work if they can't run)
> * Limited Users (for when buffer overflows etc DO happen)
> * Mail filtering at the gateway (Messagelabs, though this is more for
saving
> bandwidth)
> * Regular updates (not panicked updates whenever the Media decides to play
> Chicken Little)
>
> > Changing ACLs are helpful in locking down a workstation
> > to the level you are trying to do, but only as long as you realize that
1)
> > these things only help so much and 2) hardening ACLs to a very strict
> level
> > can cause a fair amount of frustration and things breaking.
>
> I test things, and I test things some more.  My clients are part of the
> testing process (Would you come down to my testing lab and try some stuff
> out?)  Each thing I do only helps so much, but all of those things working
> in concert helps a LOT.  What's more is no one's more important than the
> client - I need to fulfill their needs and that sometimes includes using
> security practices I would balk at.  Though I try my best to minimize
> potential problems (hey, that's what I get paid for!)
>
> -- 
> 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>
>
>

Relevant Pages

  • Re: Profiles Problem
    ... I had written an e-book about registry ... Since the script will run in the user's ... >> permissions to HKEY_CURRENT_USER. ... >>> Profile Problem ...
    (microsoft.public.win2000.group_policy)
  • RE: VBS Script Execution Fails with Permission Denied
    ... Sounds though there might be a permissions issue on or around the FSO ... adding these user/groups to the ACLs for the resource etc. Try using Filemon ... question and get them to monitor reg/file access while running the script. ... > Server Specs ...
    (microsoft.public.scripting.vbscript)
  • Re: [Updates] Re: More Before-The-Fact-Isms II
    ... permissions to the target files and folders, in this case the user profile. ... but it does probably prevent you from hardening the ACLs ... such as in the root of the user profile folder or on the ...
    (microsoft.public.security)
  • Re: Roaming Profiles
    ... It has the ability to carry over all ACLS and ... permissions associated with files and folders... ... especially for User Profile ... Directories where the permissions may have been changed by the users ...
    (microsoft.public.windows.server.active_directory)
  • Im looking for a script or utility to copy a profile to a specified folder
    ... I'm looking for a script or utility to copy a profile to a specified ... the resultant folder must contain all the original profile's files with ... the identical attributes and permissions. ...
    (microsoft.public.win2000.cmdprompt.admin)