Skip to main content

 none
icacls to block all users from write RRS feed

  • Question

  • Hello.

    My scenario is our software elevates via UAC and extracts files to a %temp% directory that needs protection from a standard user, preventing it from WRITING to any files inside our folder. But allowing any local_admin/domain_admin/system to be able to write to the dir. But user is allowed to READ and EXECUTE.

    So the directory originally has permissions, maybe user or admin creates the dir. 

    cd "C:\Users\user-lp\AppData\Local\Temp"
    mkdir dir12 // Inherits parent directory permissions
    icacls dir12
            NT AUTHORITY\SYSTEM:(OI)(CI)(F)
            BUILTIN\Administrators:(OI)(CI)(F)
            DESKTOP-sss\user-lp:(OI)(CI)(F) // Bad ACE, standard user has FULL (i.e. WRITE) permissions because he created 

    Then from an elevated position I run my icacls command it receives:

    icacls dir12 /reset // Remove inherited ACLs from parent directory
    icacls dir12 /setowner "BUILTIN\Administrators" // Replace owner of directory from user-lp to admins
    icacls dir12 /inheritance:r /grant:r BUILTIN\Administrators:(OI)(CI)F /grant:r SYSTEM:(OI)(CI)F /grant:r Everyone:(OI)(CI)RX
    icacls dir12
            Everyone:(OI)(CI)(RX) // Good now everyone can only R/X
            NT AUTHORITY\SYSTEM:(OI)(CI)(F)
            BUILTIN\Administrators:(OI)(CI)(F) // Good admin has full permissions

    Can you confirm my icacls commands are correct in what I was trying to achieve - allowing only admin/domain admin to write to a folder, and deny standard user from write.

    Do I need to in the icacls state domain user/domain admin too, domain user should be banned from writing too.



    Wednesday, June 26, 2019 2:53 PM

All replies

  • Hello.

    My scenario is our software elevates via UAC and extracts files to a %temp% directory that needs protection from a standard user, preventing it from WRITING to any files inside our folder. But allowing any local_admin/domain_admin/system to be able to write to the dir. But user is allowed to READ and EXECUTE.

    So the directory originally has permissions, maybe user or admin creates the dir. 

    cd "C:\Users\user-lp\AppData\Local\Temp"
    mkdir dir12 // Inherits parent directory permissions
    icacls dir12
            NT AUTHORITY\SYSTEM:(OI)(CI)(F)
            BUILTIN\Administrators:(OI)(CI)(F)
            DESKTOP-sss\user-lp:(OI)(CI)(F) // Bad ACE, standard user has FULL (i.e. WRITE) permissions because he created 

    Then from an elevated position I run my icacls command it receives:

    icacls dir12 /reset // Remove inherited ACLs from parent directory
    icacls dir12 /setowner "BUILTIN\Administrators" // Replace owner of directory from user-lp to admins
    icacls dir12 /inheritance:r /grant:r BUILTIN\Administrators:(OI)(CI)F /grant:r SYSTEM:(OI)(CI)F /grant:r Everyone:(OI)(CI)RX
    icacls dir12
            Everyone:(OI)(CI)(RX) // Good now everyone can only R/X
            NT AUTHORITY\SYSTEM:(OI)(CI)(F)
            BUILTIN\Administrators:(OI)(CI)(F) // Good admin has full permissions

    Can you confirm my icacls commands are correct in what I was trying to achieve - allowing only admin/domain admin to write to a folder, and deny standard user from write.

    Do I need to in the icacls state domain user/domain admin too, domain user should be banned from writing too.



    A number of questions come quickly to mind --
    1) Why would a sub-folder in a user's profile be used to store data for which that user should not have full control?
    2) Why would the Everyone group need read/execute access to a sub-folder in a particular user's profile?
    3) Why store data that is intended to be persistent into a "temp" folder?
    4) What if that user's profile is deleted?

    Is the intent is to store data in a location for which only the SYSTEM and Administrators have full control while one or more standard users should have read/execute access?

    If so, then the application running with elevated privilege should create the required folder outside of any user's profile and provide an appropriate security descriptor at the time that the folder is created. Consequently, there would be no need to run icacls since the folder already has the desired access permissions.

    • Edited by RLWA32 Wednesday, June 26, 2019 5:04 PM
    Wednesday, June 26, 2019 5:01 PM
  • 1) Why would a sub-folder in a user's profile be used to store data for which that user should not have full control?
    4) What if that user's profile is deleted?

    It was merely an example the "cd" command. Our temp folder to extract to, can be anywhere, was testing with %temp%

    2) Why would the Everyone group need read/execute access to a sub-folder in a particular user's profile?

    Don't know. In case, someone wants to be tech savvy and execute from our temp folder. But thinking about it, only an elevated user can install since the extracted installer which will prompt UAC, so I guess just have the admin only access ACL. Not even allow users to +R into our temp folder, right. 

    3) Why store data that is intended to be persistent into a "temp" folder?

    The main binary extracts a couple of files into a temp folder, then one of those files is an installer, and some of the files are moved into there appropiate places. It then deletes that temp directory. 

    5) Is the intent is to store data in a location for which only the SYSTEM and Administrators have full control while one or more standard users should have read/execute access?

    Exactly. The user could have any name so I can't explicitly deny/allow based on a SID, hence have to operate on groups. But it is the user that will download our file, then doubleclick, which will prompt UAC, then do the extraction, and run the extracted installer. 

    6) If so, then the application running with elevated privilege should create the required folder outside of any user's profile and provide an appropriate security descriptor at the time that the folder is created. Consequently, there would be no need to run icacls since the folder already has the desired access permissions.

    I don't think I can guarantee the parent folder I get extracted into will have secure permissions. If I installed to %system32% and someone gave Everyone +W access (unlikely yes), but it can happen, as we don't own the user's PC. So better to set the DACL on our temp directory explicitly preventing a standard user from writing to us. 

    Before you ask why am I running a binary, to extract an installer and other files. I don't control that process. All I control is the wrapper binary. And the icacls commands I posted were examples as well, just for me to get the correct permissions on target temp dir. 

    Wednesday, June 26, 2019 5:20 PM
  • You can get the SDDL string required by the function using the command line

    CACLS pathname /S

    Provided you already setup the desired permission on a file/folder in Windows Explorer. 

    There are not a lot of places in the system where a normal user can't read. And %temp% is not one of them. creating your own private admin-only folder under %temp% may cause issues for utilities like Microsoft's disk cleanup tool. Better put it somewhere else. 

    Since you are creating your own temp folder, you can put it anywhere. Windows Installer puts its temp files under a temp folder rootdrive\config.msi\. 




    Visual C++ MVP


    Wednesday, June 26, 2019 6:30 PM
  • Lets assume that the wrapper binary manages to extract the installer and other files into a location where the user only has read/execute access.  What prevents the user from copying those files to another location where they can be manipulated/replaced before the actual install from that alternate location?
    • Edited by RLWA32 Wednesday, June 26, 2019 7:37 PM
    Wednesday, June 26, 2019 7:36 PM
  • Yes very good. icacls on directory c:\config.msi is:

    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
    BUILTIN\Administrators:(OI)(CI)(F)

    And config.msi folder owner is:

    BUILTIN\Administrators

    Looks like I just need to remove "Everyone RX" privs then and I'm all set. What folder do you recommend for temporarily storing? As a just in-case our installer fails, and the cleanup code does not run to delete all the files, I ideally don't want files lingering around, hence why I put it in %temp% for it to eventually be cleaned up. 

    Wednesday, June 26, 2019 10:45 PM
  • well just name your folder temp something so the user know its safe to delete. Your permission makes Disk Cleanup impossible to delete your folder, because your folder is invisible to the user. 


    Visual C++ MVP

    Wednesday, June 26, 2019 11:49 PM