In D34622#834000, @wma wrote:@sebastien.bini_stormshield.eu could you confirm if this changes still apply to HEAD? I was trying to find anything related to -oVERIFY in init.c but there is none such string. Is there anything missing which needs to be merged before this patch?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Sep 28 2022
Sep 28 2022
sebastien.bini_stormshield.eu added a comment to D34622: init: allow to start script executions with sh -o verify.
Sep 26 2022
Sep 26 2022
In D36678#833237, @sjg wrote:I should probably elaborate: if the manifest verifies ok - the manifest is legitimate.
We deliver our s/w in immutable iso images - which mitigates a lot of problems, but in general; upgrading a box after 10 years, provides lots of scope for innocent failure modes.
Being unnecessarily strict can do be counter productive.
Sep 23 2022
Sep 23 2022
Sep 19 2022
Sep 19 2022
@emaste Yes, it's good.
Sep 16 2022
Sep 16 2022
Sep 14 2022
Sep 14 2022
Sep 12 2022
Sep 12 2022
sebastien.bini_stormshield.eu added inline comments to D27364: mac_grantbylabel focused priv escallation via maclabel.
sebastien.bini_stormshield.eu added a comment to D36506: veriexec: add syscall to retrieve veriexec label.
In D36506#829337, @sjg wrote:Sorry, I already have a methon in mac_veriexec to provide access to label - part of the changes for mac_grantbylabel, which don't appear to be committed to main.
Hmm if I had a patch for main I seem to have lost it.
Will have to get that sorted first.
sebastien.bini_stormshield.eu added inline comments to D27364: mac_grantbylabel focused priv escallation via maclabel.
Sep 9 2022
Sep 9 2022
sebastien.bini_stormshield.eu updated the diff for D36506: veriexec: add syscall to retrieve veriexec label.
- code improvement
sebastien.bini_stormshield.eu updated the diff for D36506: veriexec: add syscall to retrieve veriexec label.
- fixed usage
sebastien.bini_stormshield.eu added reviewers for D36506: veriexec: add syscall to retrieve veriexec label: sjg, mw, wma.
sebastien.bini_stormshield.eu requested review of D36506: veriexec: add syscall to retrieve veriexec label.
Sep 7 2022
Sep 7 2022
sebastien.bini_stormshield.eu updated the summary of D36477: veriexec: fixed usage and getopt issue on armv6.
sebastien.bini_stormshield.eu requested review of D36477: veriexec: fixed usage and getopt issue on armv6.
Aug 23 2022
Aug 23 2022
- Code review comments
sebastien.bini_stormshield.eu added inline comments to D36311: MLD group state string conversion fix.
sebastien.bini_stormshield.eu retitled D36311: MLD group state string conversion fix from The ipv6 MLD group state string conversion function is broken (only used if KTR is turned on). to MLD group state string conversion fix.
Jul 15 2022
Jul 15 2022
Okay, thanks for the clarification.
Jul 11 2022
Jul 11 2022
On our systems ve_utc is set to a fixed constant timestamp, and certificate expiration is always checked against that fixed clock.
May 17 2022
May 17 2022
Looks good, thanks!
May 16 2022
May 16 2022
sebastien.bini_stormshield.eu added inline comments to D33246: Improve parameters handling in veriexec.
May 6 2022
May 6 2022
Thank you for the backport :) !
May 5 2022
May 5 2022
@markj could it be possible to backport this fix to the FreeBSD 13.1 while there is still time?
My FreeBSD 13.1 VM (virtualbox) freezes randomly during boot and this commit fixes it.
Mar 28 2022
Mar 28 2022
sebastien.bini_stormshield.eu updated the diff for D34622: init: allow to start script executions with sh -o verify.
Comments from sjg
Mar 21 2022
Mar 21 2022
sebastien.bini_stormshield.eu added reviewers for D34623: hardware: added Dell H840 raid support: mw, wma.
sebastien.bini_stormshield.eu updated the summary of D34622: init: allow to start script executions with sh -o verify.
Feb 28 2022
Feb 28 2022
sebastien.bini_stormshield.eu updated the summary of D34394: Fix mvneta driver that doesn't handle fixed link properly.
Feb 21 2022
Feb 21 2022
sebastien.bini_stormshield.eu retitled D34327: mac_veriexec: Authorize reads of secured sysctls from Writes to sysctls flagged with CTLFLAG_SECURE are blocked if the appropriate secure level is set. mac_veriexec does not behave this way, it blocks such sysctls in read-only mode as well. to mac_veriexec: Authorize reads of secured sysctls.
sebastien.bini_stormshield.eu requested review of D34327: mac_veriexec: Authorize reads of secured sysctls.
Feb 17 2022
Feb 17 2022
sebastien.bini_stormshield.eu planned changes to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
Thank you for your input, I believe we will think it over.
Feb 16 2022
Feb 16 2022
sebastien.bini_stormshield.eu added a comment to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
In D33926#776097, @sjg wrote:In D33926#775928, @sebastien.bini_stormshield.eu wrote:In D33926#775631, @sjg wrote:Also I'm curious; if you are ok embedding trust anchors in the loader, what is the problem with embedding them in veriexec?
Legacy build system basically :s
It's much more convenient for us to separate the program compilation from its cryptographic configuration. This way the program can be compiled once and be used with various (trusted) CA stores.
When I originally designed the trust model for veriexec's signed manifest, I end up with embedded trust anchors because I could not come up with an alternative that could not be compromised. Of course as an embedded vendor, the set of trust anchors required is quite small and virtually static, so it is an easy choice.
What about a pre-loaded kernel module to hold your initial trust anchor(s)? need only be a sysctl ? not bullet proof, but a bit harder to spoof than kenv?
Feb 15 2022
Feb 15 2022
sebastien.bini_stormshield.eu added a comment to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
In D33926#775630, @sjg wrote:Thanks for clarifying. The problem is; how does the kernel know/trust that the loader really verified anything ? rather than simply a loader.conf putting a hash into kenv?
It is one thing for the loader to verify the kernel before loading it (we also verify the kernel's rootfs) but the kernel cannot really verify the loader - or trust anything in kenv.
sebastien.bini_stormshield.eu added a comment to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
In D33926#775631, @sjg wrote:Also I'm curious; if you are ok embedding trust anchors in the loader, what is the problem with embedding them in veriexec?
sebastien.bini_stormshield.eu added inline comments to D33246: Improve parameters handling in veriexec.
Feb 14 2022
Feb 14 2022
sebastien.bini_stormshield.eu added a comment to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
In D33926#773586, @sjg wrote:The basic premise here is incorrect. There is a circular dependency.
veriexec cannot rely on O_VERIFY since veriexec is responsible for seeding mac_veriexec to enable O_VERIFY.
You would need to verify a detached signature of the archive - but then where do you get the trust anchors for that...
Jan 18 2022
Jan 18 2022
May 31 2021
May 31 2021
sebastien.bini_stormshield.eu added a comment to D30464: sh: Add -o verify to use O_VERIFY when sourcing scripts.
In D30464#686471, @imp wrote:$1 is a local variable to vdot. Who could possibly change it?
$1 does not change :) But it represents a filename and it may not be resolved to the same inode when passed to _rc_verify and to dot :/ I know it's probably hard to exploit, but it remains a race condition nonetheless.
sebastien.bini_stormshield.eu added a comment to D30464: sh: Add -o verify to use O_VERIFY when sourcing scripts.
In D30464#686275, @sjg wrote:vdot() { if test -s $1 && _rc_verify $1 > /dev/null 2>&1; then . $1 fi }
Besides I believe there is race condition here. The file $1 can be tampered with after the call to _rc_verify and before the source call (.)
sebastien.bini_stormshield.eu added a comment to D30464: sh: Add -o verify to use O_VERIFY when sourcing scripts.
In D30464#686275, @sjg wrote:Neat, but not going to be portable.
FWIW I use veriexec -x some/file to test whether the file is verified.
Eg. we modify rc.subr to provide a couple of functions is_verified and vdot which does . only after verify file.
This allows shell scripts to be careful about what they consume, while still being portable (not that big. a deal really ;-)
AFAIK mac_veriexec does not block the opening of files with O_VERIFY if inactive. (i.e. the new sh verify option blocks nothing if mac_veriexec is inactive / not loaded).
Could you elaborate more on the portability issue?