seatbelt-sandboxer

Generate minimally-permissioned allowlist-based Seatbelt sandbox configurations for applications. Determine what the application needs across these resource categories: For each category, determine: Needed? and Specific scope (paths, services, etc.) If the application has multiple subcommands that perform significantly different operations, such as build and serve commands for a Javascript bundler like Webpack, do the following: Begin with deny-all and essential process operations, saved in a suitably-named Seatbelt profile file with the .sb extension. Use file-read-data (not file-read* ) for allowlist-based reads: Why file-read-data instead of file-read* ? Three levels of network access: Network filter syntax: After you generate or edit the Seatbelt profile, test the functionality of the target application in the sandbox. If anything fails to work, revise the Seatbelt profile. Repeat this process iteratively until you have generated a minimally-permissioned Seatbelt file and have confirmed empirically that the application works normally when sandboxed using the Seatbelt profile you generated. If the program requires external input to function fully (such as a Javascript bundler that needs an application to bundle), find sample inputs from well-known, ideally official sources. For instance, these example projects for the Rspack bundler: Common failure modes: File operations:...