Remove World Write Permissions

Some more detail is necessary. Because this is a security concern for you, we should have the full details. Who's requesting this and why? Also, what is the requestor's familiarity with the Mac file system and how it's designed?

"World writeable" means any end user (whether admin or standard) has the ability to create a directory or file in a specific location on a computer. That's not always a bad thing.

For example, the directory on the Macintosh HD disk at Users > Shared is world writeable. It allows all end users on that computer to freely share data with other end users on the computer. However, there's an attribute on that directory called a sticky bit that prevents any end user from modifying the directories or files from other users unless they have admin privileges or have been granted privileges by the owner.

Another example would be the world writeable permission on each end user's home folder on a Mac. It's there to allow other end user's access to the DropBox folder. This is a way of sharing directories or files from one specific end user to another. It doesn't allow one end user to browse another end user's information.

Both of these are default permissions and are intentionally set.

Case in point, my security team did an audit that flagged a default configuration on macOS where /Library/Caches had permissions allowing group and other users to write to there. It was as simple as a policy scoped to the Macs we wanted to secure with a Files and Processes > Execute Command:

/bin/chmod -f o-w /Library/Caches

I'm not going to go into details on this particular command, that's a wealth of unix permissions experience there, and there are several variations that could accomplish the desired purpose (securing a world-writeable folder.)

Since I wasn't sure what the ramifications of locking down that folder might be I had a 2nd policy available in Self Service to allow users to unlock that folder again by reversing the command with /bin/chmod -f o+w /Library/Caches - but software updates and app installs and operations all seemed to be unaffected so we hid this away from most users but still have it just in case support staff need it.

In macOS Catalina however, there's a curveball... /Library/Preferences/Audio/Data was found to be world writeable, and it seems to be protected by SIP, so we tried to extend the functional command line above:

/bin/chmod -f o-w /Library/Caches /Library/Preferences/Audio/Data

However, while the command succeeds, SIP silently prevents the permissions change, since it still shows as world writeable:

% ls -al /Library/Preferences/Audio/Data
total 0
drwxrwxrwx@ 2 _coreaudiod  _coreaudiod   64 Jul  5  2020 .
drwxrwxr-x  5 root         _coreaudiod  160 Jan 21 10:11 ..

The solution? Convince the security team that locking down this folder via permissions is nearly impossible and implement a control to prevent unexpected binary execution from that location.

If I had to take a guess, I believe the OP is getting this directive because of entries in the CIS Benchmark document, which mentions checking world writable permissions for specific items and areas, not just anywhere. The guide mentions checking the main /Applications since technically speaking, most apps should not have areas of their folder structures with world writable permissions set. It could, in theory at least, lead to some type of modification to the app and lead to bad code execution. While I think the odds of this happening are pretty slim, it is a valid concern when talking about truly securing and hardening your devices.

I only know this is what this is likely in reference to, because I just had to go through a lot of work at my position to implement a similar check on Applications and also the main /Library folder, among many other things from the CIS Benchmark. Most other locations are not of concern, and as mentioned, SIP protects places like /System and /System/Library automatically, so unless something foolish is done, like disabling SIP, there's no need to check those locations.

This will do the job.