Page MenuHomeFreeBSD

dma-mbox-create: Restrict with Capsicum
ClosedPublic

Authored by cem on Sep 21 2016, 5:32 AM.

Details

Summary

The restriction here is pretty late and pretty minimal. We need a lot
of authority to open password databases, and don't do much after that
point.

Test Plan
  • sudo truss /usr/libexec/dma-mbox-create cmeyer

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

cem retitled this revision from to dma-mbox-create: Restrict with Capsicum.
cem updated this object.
cem edited the test plan for this revision. (Show Details)
cem added reviewers: emaste, allanjude, oshogbo.

Hi! Do we want to ifdef the capsicum part? We share this code with DragonFly, https://github.com/corecode/dma (which is where our port comes from), and the latter is used in Debian. I also pull this code and build it for CentOS.

Hi! Do we want to ifdef the capsicum part? We share this code with DragonFly, https://github.com/corecode/dma (which is where our port comes from), and the latter is used in Debian. I also pull this code and build it for CentOS.

It's definitely best if we can share an unmodified version of this with other operating systems, so #ifdefing the Capsicum-specific chagnes seems reasonable to me.

FYI we #ifdef'd bspatch as FreeBSD is upstream and other software may pull from us,
https://svnweb.freebsd.org/base/head/usr.bin/bsdiff/bspatch/bspatch.c?view=markup
having the small refactoring here (the maildirfd) upstream should be useful in other operating systems with some sandboxing technology

cem edited edge metadata.

Ifdef Capsicum support (FreeBSD-only for now) for code-sharing with DragonFly
and Linux.

FYI we #ifdef'd bspatch as FreeBSD is upstream and other software may pull from us,
https://svnweb.freebsd.org/base/head/usr.bin/bsdiff/bspatch/bspatch.c?view=markup
having the small refactoring here (the maildirfd) upstream should be useful in other operating systems with some sandboxing technology

Right. Most of these changes are not FreeBSD-specific, so I only ifdef'd the Capsicum-exclusive bits.

contrib/dma/dma-mbox-create.c
178–185 ↗(On Diff #20584)

do we still need fn?
I think it would be fine to print just the user (e.g. open mbox for user '%s'", or if we want the path do %s/%s.

Considering sending this as a pull request for upstream: https://github.com/emaste/dma/commit/6748bdd435e6287cb36ea278fec2a1f7281be6bf

Yeah, that looks fine to me. Go ahead. (Can you CC me on the PR?)

Rebase over Ed's maildirfd patch.

Use capsicum helpers for tz and nls caching.

Is this too useless to commit? Nothing beyond sandbox entry seems even remotely exploitable.

This revision was automatically updated to reflect the committed changes.