Re: Trouble with XCACLS.VBS and denying Execute access
From: Roger Abell [MVP] (mvpNoSpam_at_asu.edu)
Date: 12/30/04
- Next message: Jason: "Builtin Security Group"
- Previous message: PA Bear: "Re: win98 critical updates."
- In reply to: Gordon Fecyk: "Trouble with XCACLS.VBS and denying Execute access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Dec 2004 16:13:37 -0700
Gordon,
Well, turns out one only needs cacls to see the differences
It seems that if you omit the E in the second of your xcacls.vbs cmds
then you will get the behavior you were expecting (and that I would
expect when E is used also).
Much notes of the testing below.
--
Roger
<example>
\ta\test1\Shortcut to notepad.exe.lnk NEBULAR\cowpoke:(special access:)
STANDARD_RIGHTS_ALL
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
STANDARD_RIGHTS_REQUIRED
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_DELETE_CHILD
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES
\ta\test2\Shortcut to notepad.exe.lnk NEBULAR\cowpoke:(special access:)
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
STANDARD_RIGHTS_REQUIRED
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_DELETE_CHILD
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES
</example>
Both directories had an Administrators full inherited into it while the
xcacls.vbs commands were run.
The difference here is that the second \test2 is just as it looks after
running cacls with
/T /E /Q /L /SPEC C /P "%userdomain%\%username%":F
and then with
/T /E /Q /L /G "%userdomain%\%username%":12345789ABCDE
while the first is how something created just the same way looks after
the GUI ACL editior has been used to remove a grant set on \test1
whereas the inherited grant to Adminstrators was removed at \ta in
order to get it not applicable in \test2
The use of the ACL editior directly on \test1 caused a rewrite in which
the STANDARD_RIGHTS_REQUIRED was honored and so you see
ACEs were added for
STANDARD_RIGHTS_ALL
SYNCHRONIZE (if you recall, this used to be available as a checkbox
in the W2k ACL editor adv view)
and also added were generics that summarize the combos of specials bits
found, namely
FILE_GENERIC_READ
FILE_GENERIC_WRITE
The last does not add anything, just sets two bits in the generic rights
area
of the ACE for more efficient compares in future on use; but the other two
do add capability.
What I find unsavory is that E was specified (SYNCRONIZE) in the xcacls.vbs
command for file only permissions.
Fooling around a little trying to trigger the ACL massaging done by the ACL
editor, except only using xcacls.vbs did not immediately yield any joy.
I for example see that using
/T /E /Q /L /SPEC B /G "%userdomain%\%username%":12345789ABCDE
(which is in this case functionally equivalent, just overlapping) as the
second
makes no difference.
Even using xcacls.vbs to literally alter the ACL of the .lnk itself instead
of its
parent has no impact. i.e.
\tb\test2\Shortcut to notepad.exe.lnk" /T /E /Q /L /R Users
So, is this an xcacls.vbs issue, an OS issue, or . . .
Well, it is well known that the OS defers full consumation of ACL
processing,
MS docs this as an "that is how it is done", and there are certainly "worse"
or
"more buggy/hazardous" lapses that result due to the deferred propagation.
I need to dig into the xcacls.vbs later to see if it is actually setting the
sync
when one uses E or if somehow the bit logic is being reversed because I have
found that use of the two xcacls.vbs commands
/T /E /Q /L /SPEC C /P "%userdomain%\%username%":F
and then with
/T /E /Q /L /G "%userdomain%\%username%":12345789ABCD
(i.e except omit the E sync spec in the file perms only command)
yields exactly what is expected in the original with the E, that is, it has
the SYNCRONIZE and the GENERIC_RIGHTS_ALL and the two
restatement generic bits set on.
--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCDBA, MCSE W2k3+W2k+Nt4
"Gordon Fecyk" <gordonf@pan-am.ca> wrote in message
news:eom7EYW7EHA.2192@TK2MSFTNGP14.phx.gbl...
> Several threads ago I asked about changing the default ACL for a user's
> profile. This was an attempt to stop executables coming from the net,
> including exploits that could work somehow as limited users.
>
> I've run into a brick wall regarding changing the permissions
> programatically on Windows 2000 Professional. I can do it, but the end
> result is not the same as it is if done through the Win2K Security GUI.
>
> The objective is to change the ACLs in %userprofile% so they look like
> this:
>
> %userdomain%\%username%: Full Control (This Folder and Subfolders only)
> %userdomain%\%username%: Special [Everything but Traverse Folders /
> Execeute
> File]
> (Files Only)
> BUILTIN\Administrators: Full Control (This Folder, Subfolders and Files)
> NT AUTHORITY\SYSTEM: Full Control (This Folder, Subfolders and Files)
>
> %userdomain% (which can also mean the local computer) and %username%
> represent the current user and %userprofile% represents this user's
> Documents and Settings folder.
>
> If I change the permissions to look like those above through the GUI, the
> system behaves exactly as I want it to. That is, everything works
> normally
> (including shortcuts, the Send To menu and the Quick Launch toolbar)
> except
> opening an executable returns "Access is Denied." Try this for yourself:
> Copy notepad.exe to your desktop and attempt to open it to observe the
> desired behaviour.
>
> Now I'm attempting to do this programatically with xcacls.vbs. I've been
> in
> a support ticket with Microsoft Support over this and we can't seem to get
> it right. The end result LOOKS correct if I view it all with the GUI, but
> shortcuts stop working. Sometimes, I lose visibility of the shortcuts
> entirely.
>
> The command lines I'm attempting this in are as follows:
>
> cscript Xcacls.vbs "%userprofile%" /T /E /Q /L /SPEC C /P
> "%userdomain%\%username%":F
> cscript Xcacls.vbs "%userprofile%" /T /E /Q /L /G
> "%userdomain%\%username%":12345789ABCDE
>
> The first line REPLACES the ACL (/P) for the current user with the Full
> Cont
> rol permissions I want for this folder and subfolders (/SPEC C). The
> second
> line ADDS (/G) the Special permissions I want for files only (note the
> absence of /SPEC). Notice that "6" (Traverse / Execute) is missing.
>
> I suspect that when I replace the original ACL that the change isn't
> propagating out, because the /T switch generates an "Access is Denied"
> error
> according to the logs if I also do /L. Then when I add the second ACL,
> that
> change also isn't propagating out. I've effectively locked myself out of
> all of my files. I can restore access with the GUI.
>
> I've also tried this:
>
> cscript Xcacls.vbs "%userprofile%" /T /E /Q /L /G
> "%userdomain%\%username%":12345789ABCDE;123456789ABCDE
>
> According to the documentation for xcacls.vbs, the first set of switches
> (everything but Traverse / Execute) is for "Files Only" and the second set
> (absolutely everything) is for "This Folder and Subfolders". In practice,
> the second set of switches is only valid for "This Folder Only" which
> locks
> out all of the subfolders. The change does not propagate even though I
> set
> /T.
>
> So I need to figure out what the GUI is doing that xcacls.vbs isn't, and
> make it do that.
>
> I also tried adding a Deny (/D %username%:6) instead of doing two Allows.
> If I do that I end up disabling all shortcuts again. Adding a Deny
> Traverse/Execute for Files Only through the GUI does the same thing.
>
> --
> 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: Jason: "Builtin Security Group"
- Previous message: PA Bear: "Re: win98 critical updates."
- In reply to: Gordon Fecyk: "Trouble with XCACLS.VBS and denying Execute access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
