-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
taint untrusted data #269
Comments
This commit adds the Purebred.Types.IFC module for information flow control (IFC) types and functions. We begin with a trivial taint mechanism. A single aspect of the implementation - tryRunProcess - is updated to use it, for demonstration and review purposes. Part of: #269
@romanofski POC commit: 7e2b74c. LMK what you think. It doesn't have to be a big bang, we can do it progressively. |
Yep I like this very much. So the deal is basically that we use |
Cool, so I'll push forward with this on the subprocess side and make that the first deliverable. Afterwards I'll turn focus to taint on mail bodies / parts. |
Taint sendmail stderr. Also re-export some typed-process ProcessConfig-related types and functions from Purebred.System.Process. This is a move to avoid importing System.Process.Typed anywhere in purebred, except this one module, ensuring that all the "run process" functions that are available taint the process output. Part of: #269
Create tainting version of readProcess and update Storage.Notmuch.getDatabasePath to use it. Part of: #269
Re-export 'shell' from Purebred.System.Process so that we can avoid directly importing System.Process.Typed anywhere (except the aforementioned module). We want to avoid using typed-process directly; instead we want to ensure we use our own variants that taint the process output. Part of: #269
This commit adds the Purebred.Types.IFC module for information flow control (IFC) types and functions. We begin with a trivial taint mechanism. A single aspect of the implementation - tryRunProcess - is updated to use it, for demonstration and review purposes. Part of: #269
Taint sendmail stderr. Also re-export some typed-process ProcessConfig-related types and functions from Purebred.System.Process. This is a move to avoid importing System.Process.Typed anywhere in purebred, except this one module, ensuring that all the "run process" functions that are available taint the process output. Part of: #269
Create tainting version of readProcess and update Storage.Notmuch.getDatabasePath to use it. Part of: #269
Re-export 'shell' from Purebred.System.Process so that we can avoid directly importing System.Process.Typed anywhere (except the aforementioned module). We want to avoid using typed-process directly; instead we want to ensure we use our own variants that taint the process output. Part of: #269
Btw @frasertweedale was wondering whether is might use the plugin system too or should we just apply what we already have? |
No, this is built-in behaviour. It is a good question whether data from plugins should be trusted or not. In general, because the user explicitly enables the plugin, there is no need to taint data from plugins. But perhaps there will be a use case. |
Purebred handles several kinds of untrusted data:
We should use types to demarcate these untrusted data and force (or at least "strongly encourage") the programmer to sanitise the data properly before handling it. This is especially relevant when:
The specific deliverables are grouped by the kinds of data we want to taint:
The text was updated successfully, but these errors were encountered: