Trouble with XCACLS.VBS and denying Execute access

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>

Roger
Wed Dec 29 02:59:50 CST 2004

Hi Gordon,

I can repro much of what you report, just have not looked at
the log to see the part about non-recurse, but that seems in line
with what I mentioned in earlier thread about how it seemed
/t was being handled by inheritance rather than actual recurse.

Strange how use of the shortcut in the xcacls.vbs set folder
just silently fails to open the target.
Also, I notice that I am not allowed to delete the shortcut in
the dir where xcacls.vbs has perms set per your xcacls spec even
though ACL editor clearly shows this is granted and not denied.
Further, I seem to have ruled out this being an interference due
to the profiles being special folders, as this can repro in any
old directory.

I do not have my ACL low-level dump tools installed here,
but tomorrow will repro on a box with them and look at the
SD in detail, as there must be differences within.

--
Roger

PS.
Note that the two grants to %userdomain%\%username% of
Full Control (This Folder and Subfolders only)
Special [Everything but Traverse Folders / Execute File] (Files Only)
are functionally equivalent to the following two grants
Full Control (This Folder and Subfolders only)
Special [Everything but Traverse Folders / Execute File] (This folder,
subfolders and files)


"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>
>
>

Roger
Wed Dec 29 17:13:37 CST 2004

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>
>
>