Re: [2nd opinion pls] Re: Shall I make an OpenBSD port of F3? (f3write, f3read)

On 2022/10/29 11:24, Alexander A. Klimov wrote:
>
>
> Am 22.10.22 um 13:54 schrieb Alexander A. Klimov:
> >
> >
> > Am 18.10.22 um 11:57 schrieb Stuart Henderson:
> > > On 2022/10/16 14:51, Alexander A. Klimov wrote:
> > > > Hello OpenBSD devs!
> > > > Hello Michel!
> > > >
> > > > I'd like OpenBSD to have a package of Michel's software "F3".
> > > >
> > > > https://github.com/AltraMayor/f3
> > > >
> > > > Today I checked out the snapshot ports tree, but didn't find F3
> > > > even there,
> > > > nor anything in the ports@ archive.
> > > >
> > > > Is anyone of you (going to) porting it in the near future?
> > > >
> > > > If no, I'm gonna give it a try.
> > > >
> > > > I'm looking forward to hear from you.
> > > >
> > > > Best,
> > > > A/K
> > > >
> > >
> > > I've attached a skeleton port for it, but it needs more work, OpenBSD
> > > doesn't have posix_fadvise() or clock_nanosleep().
> > >
> > > There is some code to emulate posix_fadvise for MacOS but it uses various
> > > fcntl(2) commands that we don't have.
> > >
> > As you already mentioned, F3 includes MacOS support which emulates
> > missing stuff present on other *nixes. I've submitted patches which do
> > the same for OpenBSD:
> >
> > https://github.com/AltraMayor/f3/pull/186
> >
> > Ideally Michel accepts them and I'll continue with the Security
> > Recommendations of the Porting Guide.
> >
> Both of these are done. Well, almost done. Before considering
> https://github.com/AltraMayor/f3/pull/187/files
> ready to merge I'd like to get a second opinion.
>
> Those hardenings (on top of the already merged basic OpenBSD support) in a
> nutshell:
>
> first of all in main() parse args
> then briefly introduce the program to the caller
> + the program needs exactly one dir at runtime, chroot(2) to it
> + (if allowed)
> + unveil(2) only that dir
> + pledge(2), stdio and *path
> do actual F3 things
>
> I'm not 100% sure whether I shall not include "error" in pledge(2).
> I guess it may ease debugging, especially if there's no kdump (despite
> ktrace!), but on the other hand for debugging one has gdb which btw. works,
> i.e. properly shows what exactly violates pledge(2):
>
> Program received signal SIGABRT, Aborted.
> chroot () at /tmp/-:3
>
> And as far as I get pledge(2) the philosophy is:
> Permit as less as possible.
> (Well, no "error" in pledge(2) IS possible, as well as btw.
> execpromises="".)

AFAIK "error" is only meant for use during development and shouldn't
be in final code.

And I think the current thinking is that execpromises isn't really
usable, so AFAIK set that to NULL.

> Oh, and: What's better? (The already present) Explicit unveil(NULL, NULL) or
> only (the already present) pledge(2) forbidding unveil(2)?

If one were better than the other, I'd expect the manual to advise,
so since it doesn't I think either will do.

btw, re your mention in https://github.com/AltraMayor/f3/pull/187 of
https://www.openbsd.org/faq/ports/guide.html, while the advice in there
is generally sound, it hasn't been touched in a long time, and we've had
various problems from botched conversions of string functions in ports
to size-limited variants, so it's not really done as a matter of course
in ports these days. (and your comment about uids - we trust pledge;
given a strong pledge a separate uid is often not needed, and, it
doesn't make much sense to require that software is started as root
just so that it can setuid, it's more useful for root-started daemons
or software that needs to bind to low network ports).