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.
No comments:
Post a Comment