Page MenuHomeFreeBSD

Add -S option to veriexec
ClosedPublic

Authored by sjg on Jul 8 2022, 6:47 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 22, 11:10 AM
Unknown Object (File)
Mon, Apr 22, 11:09 AM
Unknown Object (File)
Mon, Apr 22, 11:09 AM
Unknown Object (File)
Mon, Apr 22, 10:55 AM
Unknown Object (File)
Sun, Apr 7, 4:19 PM
Unknown Object (File)
Mar 7 2024, 1:59 AM
Unknown Object (File)
Mar 7 2024, 1:59 AM
Unknown Object (File)
Mar 7 2024, 12:53 AM

Details

Summary

During software installation, use veriexec -S to strictly
enforce certificate validity checks (notBefore, notAfter).

Otherwise ignore certificate validity period.
It is generally unacceptible for the Internet to stop working
just because someone did not upgrade their infrastructure for a decade.

Sponsored by: Juniper Networks, Inc.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sjg requested review of this revision.Jul 8 2022, 6:47 PM

This is just to align better with Junos usage.

bcr added a subscriber: bcr.

OK for the manpage part.

Typo is minor enough to fix at commit without another round of reviews unless something else justifies it.

sbin/veriexec/veriexec.8
59
sjg marked an inline comment as done.Jul 11 2022, 2:25 AM

On our systems ve_utc is set to a fixed constant timestamp, and certificate expiration is always checked against that fixed clock.

If I got this right, the -S option lives for a single veriexec call. As such, nothing would prevent users from calling veriexec again without -S and skip the date check?

If this is a security feature, then wouldn't it be better to make it so that calling veriexec -S (or some sysctl) would turn on certificate validity checks until the system is rebooted? This would work similar to other security features in FreeBSD (like mac_veriexec states that cannot removed or secure level that cannot be lowered).

Doing so would allow to boot the kernel and verify the base system even with an outdated system (so users that do not upgrade still get something that works). More security sensitive features can be loaded at a later stage, with certificate validity checks enforced until reboot?

On our systems ve_utc is set to a fixed constant timestamp, and certificate expiration is always checked against that fixed clock.

If I got this right, the -S option lives for a single veriexec call. As such, nothing would prevent users from calling veriexec again without -S and skip the date check?

Correct, that is exactly the idea.
As I think I mentioned, in Junos for various certifications (FIPS/Common Criteria) we need to strictly enforce all certificate restrictions - during s/w install.
Once software is installed we have a compelling requirement that it NOT stop working just because a certificate has expired - yes people do run 10yo s/w on Internet core routers.

If this is a security feature, then wouldn't it be better to make it so that calling veriexec -S (or some sysctl) would turn on certificate validity checks until the system is rebooted?

Per above, this is not necessary. Our s/w install process always uses the -S option, and we do not want it at any other time.

This would work similar to other security features in FreeBSD (like mac_veriexec states that cannot removed or secure level that cannot be lowered).

Very different situation.

Doing so would allow to boot the kernel and verify the base system even with an outdated system (so users that do not upgrade still get something that works). More security sensitive features can be loaded at a later stage, with certificate validity checks enforced until reboot?

I believe this is already what we have, via -S.

Okay, thanks for the clarification.

This does not break anything on our end and we could actually benefit from it. I'm good with it.

This revision is now accepted and ready to land.Jul 15 2022, 7:50 AM
This revision was automatically updated to reflect the committed changes.