AppExec - Registry ACLs not working
WildByDesign opened this issue · 8 comments
I just noticed that registry ACLs are currently not working in AppExec. File system ACLs are working.
All examples below failed to set ACL:
Computer\HKEY_CURRENT_USER\SOFTWARE\Sysinternals
HKEY_CURRENT_USER\SOFTWARE\Sysinternals
CURRENT_USER\SOFTWARE\Sysinternals
HKCU\SOFTWARE\Sysinternals
Running AppExec as admin also failed to set registry ACL.
However, in the registry ACL reference app, RunAppContainer (https://github.com/zodiacon/RunAppContainer / https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/) I was able to successfully use: CURRENT_USER\SOFTWARE\Sysinternals
I haven't used registry ACLs in AppExec for a long time now and therefore I don't recall if it worked initially or if it stopped working at some point in time.
try this prefix:
only support SE_REGISTRY_KEY
I tried all possibilities to get this to work now, particularly after doing some more studying after your suggested prefixes. Unfortunately it is still failing.
The prefix that works in RunAppContainer program (CURRENT_USER\SOFTWARE\Sysinternals) is interesting because that program you specifically have to remove the HKEY_ part for all registry ACLs. In RunAppContainer, HKEY_CURRENT_USER\SOFTWARE\Sysinternals fails, but CURRENT_USER\SOFTWARE\Sysinternals is successful.
All attempts with AppExec with different prefixes seem to fail for me.
But what is interesting is, if I use the method of removing the HKEY_ part like what works for RunAppContainer, AppExec parses that in an interesting way and may possibly be the source of where the registry ACLs are failing in AppExec. For example, if I use CURRENT_USER\SOFTWARE\Sysinternals in AppExec, I get the following output:
Fs Access: CURRENT_USER\SOFTWARE\Sysinternals
AppExec is parsing these as File System ACL instead of registry ACL and therefore that could potentially be a source of where this is failing. That is my only theory at the moment.
As always, thank you for your time. I appreciate it.
I tested my theory briefly and found a temporary fix. I modified /AppExec/app.cc only in my testing and looked at the code section that you pointed out: https://github.com/M2Team/Privexec/blob/master/AppExec/app.cc#L170
Before:
constexpr std::wstring_view keys[] = {L"HKEY_CLASSES_ROOT", L"HKCR", L"HKEY_CURRENT_USER", L"HKCU",
L"HKEY_LOCAL_MACHINE", L"HKLM", L"HKEY_USERS", L"HKU"};
After:
constexpr std::wstring_view keys[] = {L"HKEY_CLASSES_ROOT", L"HKCR", L"HKEY_CURRENT_USER", L"CURRENT_USER", L"HKCU",
L"HKEY_LOCAL_MACHINE", L"HKLM", L"HKEY_USERS", L"HKU"};
The only thing that I did as part of my testing was added L"CURRENT_USER", to the code section.
My very first test now with CURRENT_USER\SOFTWARE\Sysinternals in the registry ACL for AppExec, I got the following output:
Registry Access: CURRENT_USER\SOFTWARE\Sysinternals
Previously the output was showing Fs Access. So this is a good start. I following up by checking the ACLs for that key in the registry and it is now successful. AppExec successfully set the registry ACLs now.
While that was a quick fix based on my initial theory, I am not a programmer and therefore I don't know how best to fix this problem. The fix would involve adding {L"CLASSES_ROOT", L"CURRENT_USER", L"LOCAL_MACHINE", L"USERS" sections of registry without the HKEY_ part. This will allow it to work correctly.
This registry ACL method just does not work with HKEY_ part or the abbreviated registry prefixes such as HKCU. Those all fail to set registry ACL.
Correction: HKEY_LOCAL_MACHINE does not work as LOCAL_MACHINE. It has to be just MACHINE to work for setting admin registry ACLs. See Pavel Yosifovich's example: https://zodiacon.files.wordpress.com/2019/01/appcontainer6.png
Therefore, {L"CLASSES_ROOT", L"CURRENT_USER", L"LOCAL_MACHINE", L"USERS"}; should be {L"CLASSES_ROOT", L"CURRENT_USER", L"MACHINE", L"USERS"};.
So far I have successfully tested and confirmed CURRENT_USER and MACHINE.
I have not yet tested CLASSES_ROOT or USERS, but have no real use cases for those at the moment.
Anyway, the following line of code is working 100%:
{L"CLASSES_ROOT", L"CURRENT_USER", L"MACHINE", L"USERS"};
Look: https://github.com/M2Team/Privexec/releases/tag/4.4.0
I released a new version of Privexec. One big change is that AppExec Registry ACLs need to start with Registry::, such as CURRENT_USER\SOFTWARE\Sysinternals You can write:
Registry::\CURRENT_USER\SOFTWARE\Sysinternals
Also:
Registry::CURRENT_USER\SOFTWARE\Sysinternals
After AppExec processing, it becomes
CURRENT_USER\SOFTWARE\Sysinternals
This actually reduces the ambiguity and conflict in path resolution, give it a try.
Thank you for the quick fix. I did some testing this morning and confirmed everything is working regarding registry ACLs.
I tested the following under HKEY_CURRENT_USER:
Registry::\CURRENT_USER\SOFTWARE\Sysinternals (successful ACL)
Registry::CURRENT_USER\SOFTWARE\Sysinternals (successful ACL)
With AppExec run as Admin, I tested the following under HKEY_LOCAL_MACHINE:
Registry::\LOCAL_MACHINE\SOFTWARE\LibreOffice (not work)
Registry::LOCAL_MACHINE\SOFTWARE\LibreOffice (not work)
Registry::\MACHINE\SOFTWARE\LibreOffice (successful ACL)
Registry::MACHINE\SOFTWARE\LibreOffice (successful ACL)
So all in all, a good successful change. Users will need to remember to use MACHINE instead of LOCAL_MACHINE when working with HKEY_LOCAL_MACHINE ACLs.
Do you think that it would be good to add subtle tooltips/infotips in the program so that users can hover over certain information (i) bits that would display a tooltip/infotip with some specific details? (If yes, I would be happy to help with some of the descriptions if you would like.)
This is fantastic. Thank you.