Skip to content
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

Should secure Rust programs protect pointers to FFI? #30

Open
polazarus opened this issue Jan 31, 2020 · 1 comment
Open

Should secure Rust programs protect pointers to FFI? #30

polazarus opened this issue Jan 31, 2020 · 1 comment

Comments

@polazarus
Copy link
Contributor

After PR #29 and following up discussions:

  • should secure Rust programs protect pointers to FFI?
    • when? level (rec/rule)?
  • should stack pointers be considered more sensitive than heap pointers?
  • and how?

For the how, see @danielhenrymantilla's example in #29 (comment)

@polazarus
Copy link
Contributor Author

IMO, for some particularly critical (paranoid?) software, it makes sense to protect pointers transmitted to a foreign language. Is it in the scope of this guide? as a rule, I don't think so... it's not pragmatic enough.

With respect to the stack/heap divide, it is still sensible today to consider stack pointers more dangerous. Again, not always possible for various reason.

For the how, it really depends on what you're trying to protect:

  • A transparent object that the foreign side will manipulate,
  • A pointer to an opaque type that the foreign side may manipulate through a C API to Rust.

In the former, without OS support, canary seems the way to go.
In the latter, signed pointers (or tagged pointers) makes more sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant