A globally-available filesystem is a security liability

Virtually every non-trivial program pulls in third-party libraries. As we, as software/security engineers, have no time to carefully review every third-party library (and its dependencies, and transitive dependencies), we implicitly put a lot of trust in these third-party libraries.

This doesn’t always work out well: think of the event-stream disaster.

If an application can access the filesystem, then the third-party libraries can too, because the filesystem is virtually always globally available.

It is typically not possible to give restricted access to a third-party library.

Sandboxing doesn’t solve this problem, because if your application has access to the filesystem, all (transitively) dependent packages automatically have access to the filesystem as well.

Dependency injection as a possible solution

A solution would be to not make the filesystem globally available, but only in the application’s entry point, and allow a reference to the filesystem to be passed to functions (including ones in third-party libraries) that need it.

This is dependency injection used from a security angle.

This way, a third-party library would only be able to access the filesystem when it is explicitly passed in. A third-party library wouldn’t by default be able to encrypt your hard drive or read your Bitcoin wallet.

This could be made more fine-grained: rather than injecting a reference to the entire filesystem, a reference to a directory or to a specific file could be injected. This way, a third-party library could be granted limited access to exactly what it needs to operate properly.