Re: git: 4826396e5d15 - main - security/vuxml: correct last SA's affected range

On 2023-12-12 17:45:14 (+0800), Felix Palmen wrote:
> * Philip Paeps <philip@freebsd.org> [20231212 17:34]:
>> The issue described by FreeBSD-SA-23:17.pf only affects the pf kernel
>> module, not the rest of the kernel.  Consequently, freebsd-update 
>> only
>> rebuilt pf.ko.  kernel was not rebuilt.
>
> Thanks! That was the missing piece of information (for me) all the 
> time!

It's a very subtle distinction.  And we could try to be a bit clearer 
about what exactly freebsd-update updates under different circumstances. 
  In practice, this category of vulnerabilities doesn't come up very 
often.  And when it does, it usually affects device drivers and not 
kernel modules that a substantial fraction of our users can reasonably 
be expected to be using.

>> - <package>FreeBSD</package> with the version reported by 
>> freebsd-version:
>> this incorrectly presents the vulnerability as affecting userland.
>
> Wouldn't this be the "least wrong" approach for now then? Because:

My reasoning for <package>FreeBSD-kernel</package> is that this gives 
users the hint that they probably need to reboot.  And considering that 
kernel modules are part of the kernel, this feels the least incorrect to 
me.

On the other hand, putting this category of vulnerabilities under 
<package>FreeBSD</package> may actually be the "least bad" (which is not 
the same as "least wrong").  At least "pkg audit" will cry if 
freebsd-version is behind.

>> - <package>FreeBSD-kernel</package> with the version reported by 
>> uname -k:
>> this is how it is currently documented.  Users who have not upgraded
>> anything will not realise they are affected, because uname -k has 
>> been at
>> -p4 since October.  (As you correctly point out.)
>
> And yes, this is pointless, and I still think somehow dangerous when
> people expect to be warned by periodic.

Yeah ... I follow your reasoning.  I will sleep on this.

>> The security-officer team is trying to come up with a way to forcibly
>> rebuild the kernel for this category of vulnerabilities.  This is not 
>> a
>> great solution either though.  It requires users to reboot the system
>> whereas (in theory, in many/most cases), unloading and reloading the 
>> kernel
>> module would address the vulnerability.
>
> This sounds like a "better than before" kind of approach as well,
> thanks.
>
>> The good news is that pkgbase will solve this problem to some extent.
>> Kernel modules are distributed in the FreeBSD-kernel package.  While 
>> "pkg
>> audit" won't be able to determine if the correct module is loaded, at 
>> least
>> it will be able to see that the correct package has been installed.
>
> Sounds nice as well. Then I'll shut up for now. Still "wrong"
> unfortunately, but good to know there's at least progress :)

Sorry for not replying earlier.  I wasn't trying to quietly wait for the 
problem to be overcome by events.  I started typing my reply earlier and 
... then ... got ... distracted. :-)

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises