This is a result from the p2k17 hackathon in Berlin actually...
Sometimes these things take some time to complete.
Some time ago, I implemented privilege separation in dpb, and it was good:
you could run dpb as root, have it drop its privilege to either _pbuild
or _pfetch before building/fetching anything, and it would work.
Thus making ports building somewhat less insecure, to the great benefit of
bulk-builders.
As usual, security is a trade-off, this gave us two worlds: one where people
would work on ports, and one where people would bulk-build ports...
Try to fix an issue on a port that failed with dpb run in privsep mode,
and you will understand the pain: you can write nowhere as a normal user.
So, most of us took the lazy way, and ran a few fixes as root. Ouchie. Not
a good idea.
I had a nagging failing this was a bad idea, and talking with pirofti@, we
decided it might be fixable somehow.
A few days after p2k17, I committed some undocumented feature, PORTS_PRIVSEP,
that would make this less painful: it would allow your average user (with doas
rights, obviously) to switch to _pbuild/_pfetch for common directories such
as distfiles or packages.
It's not my habit to commit undocumented features. The main reason for that
was that the feature was somewhat unfinished, the main part of the ports
tree, aka the BUILD part, was still run as normal user.
After a much more extensive patch, and some painful checks (turned out to
not be that trivial), I've finally committed (and documented) the second
part of PORTS_PRIVSEP.
So ports/dpb builds should now be somewhat better integrated.
Let me explain what's going on.
- PORTS_PRIVSEP defaults as No, so business as usual.
- If you turn PORTS_PRIVSEP=Yes, then the ports tree will sprinkle
doas -u _pbuild and doas -u _pfetch in many, many places in bsd.port.mk,
so that a build will be mostly identical to what dpb does when run as root.
- you can of course override _pbuild and _pfetch as BUILD_USER or FETCH_USER.
- This gives some amount of security to the ports tree. bsd.port.mk is still
run as you (obviously), but almost anything in individual makefiles will be
run as _pbuild, or _pfetch.
Those two users should *never* have any doas capabilities. And _pbuild no
longer has any kind of network access (we fixed this in default pf.conf)
So, yes, it is privilege separation. Not perfect. But better than before.
- The most important part is that *this allows people to run dpb and to
do manual fixes in the ports tree* without compromising on permissions.
Thus making things simple again.
A few "small details (or not so small) remain:
- WRKDIR should be (mostly) readable. I introduced FIX_EXTRACT_PERMISSIONS
to fix that, and I've fixed over half the ports tree by now. This makes things
waaay less painful in general.
- most dpb privsep run are from within a chroot... where often doas is not
configured... and which are mounted nosuid... so this doesn't QUITE work.
I've figured out that doas works when run as root even when notsuid, but it
still needs a configuration. I have no idea how to make this simpler.
(the clunky security way I have is a single directory within a very small
mountpoint with a doas setuid binary, along with a doas.conf for the chroot)
Now for a bit of gloating. In order to test this, I had to go back to build
ports manually again, to make sure I didn't miss any part. And boy, is it
painful and slooow compared to dpb. Nothing makes it as obvious that a tool
is cool and useful and fast than having to go without it and realize how
much you miss it. :)
