Am 01.11.22 um 13:30 schrieb Stuart Henderson:
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.
Interesting... Any objections if I keep it ""? So I explicitly
disallow everything rather than not changing the default:
Passing NULL to promises or execpromises specifies to not change the
current value.
-- pledge(2)
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.
You know what, I'll keep both. Safe is safe. :)
For the same reason as execpromises="" and no error in pledge(2).
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;
Actually I'm already done. I've read the source of f3write, f3read
and the subroutines they use and didn't find anything to change.
(I.e. I'm done with doing actually nothing. :D)
@Michel Machado
I've just marked my PR as ready as I think the discussion about WHAT
I've done is basically done. So let's discuss HOW I've done it on GH.
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).
I was just inspired by all the ported servers, each w/ its own user. But
yes, F3 is a sysutil after all. The user shall just call it not as root.
