AppContainer: Access some folder Enable
fcharlie opened this issue · 4 comments
Enable access some folder support. use GetNamedSecurityInfo
SetEntriesInAcl
SetNamedSecurityInfo
Fun with AppContainers: https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/
https://github.com/zodiacon/RunAppContainer
Modifying the ACLs of an Object in C++
#include <windows.h>
#include <stdio.h>
DWORD AddAceToObjectsSecurityDescriptor (
LPTSTR pszObjName, // name of object
SE_OBJECT_TYPE ObjectType, // type of object
LPTSTR pszTrustee, // trustee for new ACE
TRUSTEE_FORM TrusteeForm, // format of trustee structure
DWORD dwAccessRights, // access mask for new ACE
ACCESS_MODE AccessMode, // type of ACE
DWORD dwInheritance // inheritance flags for new ACE
)
{
DWORD dwRes = 0;
PACL pOldDACL = NULL, pNewDACL = NULL;
PSECURITY_DESCRIPTOR pSD = NULL;
EXPLICIT_ACCESS ea;
if (NULL == pszObjName)
return ERROR_INVALID_PARAMETER;
// Get a pointer to the existing DACL.
dwRes = GetNamedSecurityInfo(pszObjName, ObjectType,
DACL_SECURITY_INFORMATION,
NULL, NULL, &pOldDACL, NULL, &pSD);
if (ERROR_SUCCESS != dwRes) {
printf( "GetNamedSecurityInfo Error %u\n", dwRes );
goto Cleanup;
}
// Initialize an EXPLICIT_ACCESS structure for the new ACE.
ZeroMemory(&ea, sizeof(EXPLICIT_ACCESS));
ea.grfAccessPermissions = dwAccessRights;
ea.grfAccessMode = AccessMode;
ea.grfInheritance= dwInheritance;
ea.Trustee.TrusteeForm = TrusteeForm;
ea.Trustee.ptstrName = pszTrustee;
// Create a new ACL that merges the new ACE
// into the existing DACL.
dwRes = SetEntriesInAcl(1, &ea, pOldDACL, &pNewDACL);
if (ERROR_SUCCESS != dwRes) {
printf( "SetEntriesInAcl Error %u\n", dwRes );
goto Cleanup;
}
// Attach the new ACL as the object's DACL.
dwRes = SetNamedSecurityInfo(pszObjName, ObjectType,
DACL_SECURITY_INFORMATION,
NULL, NULL, pNewDACL, NULL);
if (ERROR_SUCCESS != dwRes) {
printf( "SetNamedSecurityInfo Error %u\n", dwRes );
goto Cleanup;
}
Cleanup:
if(pSD != NULL)
LocalFree((HLOCAL) pSD);
if(pNewDACL != NULL)
LocalFree((HLOCAL) pNewDACL);
return dwRes;
}
Excellent feature. This will be very beneficial and I am looking forward to it. Having folder and registry ACL permissions will be helpful especially for LPAC.
One thing that I noticed when playing with Pavel's RunAppContainer tool was that you had to specifically run RunAppContainer.exe as Administrator for the folder and registry permissions to work. Without RunAppContainer.exe run as Admin, those ACL permissions failed.
Currently, AppExec has been added to launch AppContainer separately. It supports opening file system permissions and registry permissions.
There are two points to note here.
- Repeat testing needs to consider whether AppContainer is deleted.
- File system ACLs may not be properly configured in other partitions
Currently, AppExec has been added to launch AppContainer separately. It supports opening file system permissions and registry permissions.
There are two points to note here.
Repeat testing needs to consider whether AppContainer is deleted.
File system ACLs may not be properly configured in other partitions
Ok, I will test this thoroughly over the next few hours and I will let you know any details that I discover.
Is this expected to delete the files within the AppData\Local\Packages folder?
Is this also expected to delete the AppContainer SID details in the registry?
Also, does it require running as Admin to set the ACL details?
Thank you. I will continue testing over the next few hours.
I have now had some time to play around with this some more. I tested all variations of regular AppContainer and LPAC, by running AppExec as regular user and as Admin. And combinations of Capabilities and such. Also tested many different AppContainer Names since that caused random SIDs for more testing.
Repeat testing needs to consider whether AppContainer is deleted.
I used the latest version of WinObjEx64 throughout this testing.
Sessions > 1 > AppContainerNamedObjects
I was able to see the successful creation of AppContainer/LPAC SIDs and successful deletion of each of those unique SIDs. No AppContainer SIDs left behind in this regard. In my opinion, this is a success.
File system ACLs may not be properly configured in other partitions
Yes, I have noticed this as well. I have been using AppExec to successfully create ACLs for my C: and D: drives. However, every attempt to create ACLs for my R: drive (RAMDisk - NTFS) has failed.
Actually, AppExec is creating to correct ACLs for my R: drive. But the testing programs (Notepad and cmd) both fail to access my R: drive. As a workaround, I just use 'icacls' commands for now which is working successfully.