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

Sandbox elftool #387

Open
cfcs opened this issue Aug 27, 2019 · 0 comments
Open

Sandbox elftool #387

cfcs opened this issue Aug 27, 2019 · 0 comments

Comments

@cfcs
Copy link

cfcs commented Aug 27, 2019

Since mfttool (EDIT: now elftool) is designated to be used as the default means of learning about a unikernels MFT (from an orchestration system perspective, for example) (see discussion in #372 (comment) ), it will be parsing untrusted input in the host.

Sandboxing this with seccomp/pledge/capsicum/whatever would seem to make sense to me.

While I would of course prefer a high-level implementation doing this, using the C executable has two benefits:

  • It's using the exact same code as the actual loader, which means parser discrepancies are less of an issue.
  • Incidentally(?), a stand-alone executable is a lot easier to sandbox than the tender, or library function, since its scope of operation is pretty limited (can basically be reduced to read/write/flush/exit). That means mfttool can be our first line of defense against malicious input. An exploit targeting the MFT handling code would have to be written to not trigger during the first (sandboxed) mfttool stage (or at least not crash that), while also exploiting the actual (less sandboxed) tender.
@cfcs cfcs changed the title Sandbox mfttool Sandbox elftool Sep 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants