libsecureboot can tell us if the most recent file opened was
verfied or not.
If it's state is VE_UNVERIFIED_OK, skip if variable
matches one of the restricted prefixes.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 25289 Build 23953: arc lint + arc unit
Event Timeline
Comment Actions
How about the "chain" command?
Files loaded by it bypass verification, so we might to fix it by adding a hook to the veriexec instead.
Comment Actions
Sorry not familiar with that one.
Got a pointer?
Also that would be a separate change no?
Comment Actions
Take a look at i386/loader/chain.c, or for EFI version efi/loader/main.c:1418.
On EFI system I was able to chainload an EFI Shell without including any information about it in the manifest.
Accidentally the EFI version of chain command uses LoadImage/StartImage calls, which means that with Secure Boot enabled in firmware the binary will be verified there.
Comment Actions
Take a look at i386/loader/chain.c, or for EFI version efi/loader/main.c:1418.
On EFI system I was able to chainload an EFI Shell without including any information about it in the manifest.
Accidentally the EFI version of chain command uses LoadImage/StartImage calls, which means that with Secure Boot enabled in firmware the binary will be verified there.
Ok that chain.c must be more recent than stable/11. I'm not clear on where a verify_file check would make sense.
If you have a clue, feel free to have a go at it.
Comment Actions
If additional things are found necessary to be added to the list (or handled otherwise), they can be added after the fact. But this gets the ball rolling and is definitely needed.