System Folder named downloadDir is world readable writeable accessible

russell_garriso
New Contributor III

This post is mostly to document something I ran into, but please feel free to contribute anything that might help.

In the process of running CIS L1 audits on Ventura the following was brought to my attention:

--------
ls -alh /System/Volumes/Data/System/Library/AssetsV2/downloadDir
total 0
drwxrwxrwx@ 2 root wheel 64B Aug 10 15:35 .
drwxr-xr-x@ 43 root wheel 1.3K Aug 8 21:32 ..

--------

The directory is empty and I haven't seen a case where there is anything in it. There is a CIS control "5.1.6" that has a very strongly-worded description of how they think this should not be, so that particular audit fails. I guessed this was legit and got a little more info to corroborate that:

--------

xattr -l /System/Volumes/Data/System/Library/AssetsV2/downloadDir
com.apple.rootless: MobileAssetDownload

--------

So the file is SIP-protected and in an area where that service is expected to do things. I found other occurrences of the same directory on Monterrey and Ventura systems, but I am not entirely sure of the cause in every case. One thing I did remember was my lab machine didn't fail the audit the first time I ran it. That led me to discover one way the directory can be created.

I installed a fresh 13.4.1 OS onto a blank mac. The folder didn't appear until after I restarted to finish applying the 13.5 update. That was why my lab machine passed the first time. So it appears that is is something from when an OS update is applied and probably should be left as is considering SIP is involved. 

Hope this helps anyone else who runs into this. Definitely comment if you know more about this, as I didn't find much info about the directory itself when I searched.

1 REPLY 1

AJPinto
Honored Contributor III

Those benchmarks are just recommendations, and not the gold standard. Specifically for

/System/Volumes/Data/Library, NIST warns you that you need to make exclusions to this recommendation to fit your environment. You cannot change the permissions of SIP protected directories, you need to exclude those from your vulnerabilities. 

AJPinto_0-1691755991383.png