Page MenuHomeFreeBSD

sebastien.bini_stormshield.eu (Sébastien BINI)
User

Projects

User does not belong to any projects.

User Details

User Since
May 31 2021, 8:33 AM (55 w, 4 d)

Recent Activity

May 17 2022

sebastien.bini_stormshield.eu accepted D33246: Improve parameters handling in veriexec.

Looks good, thanks!

May 17 2022, 7:34 AM

May 16 2022

sebastien.bini_stormshield.eu added inline comments to D33246: Improve parameters handling in veriexec.
May 16 2022, 8:20 AM

May 6 2022

sebastien.bini_stormshield.eu added a comment to D33956: clockcalib: Fix an overflow bug.

Thank you for the backport :) !

May 6 2022, 7:34 AM

May 5 2022

sebastien.bini_stormshield.eu added a comment to D33956: clockcalib: Fix an overflow bug.

@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.

May 5 2022, 4:01 PM

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 28 2022, 3:29 PM

Mar 21 2022

sebastien.bini_stormshield.eu added reviewers for D34623: hardware: added Dell H840 raid support: mw, wma.
Mar 21 2022, 2:52 PM
sebastien.bini_stormshield.eu requested review of D34623: hardware: added Dell H840 raid support.
Mar 21 2022, 2:51 PM
sebastien.bini_stormshield.eu updated the summary of D34622: init: allow to start script executions with sh -o verify.
Mar 21 2022, 2:32 PM
sebastien.bini_stormshield.eu requested review of D34622: init: allow to start script executions with sh -o verify.
Mar 21 2022, 2:17 PM

Feb 28 2022

sebastien.bini_stormshield.eu added reviewers for D34394: Fix mvneta driver that doesn't handle fixed link properly: mw, zbb, mkm_semihalf.com, bsz_semihalf.com.
Feb 28 2022, 3:35 PM
sebastien.bini_stormshield.eu updated the summary of D34394: Fix mvneta driver that doesn't handle fixed link properly.
Feb 28 2022, 3:28 PM
sebastien.bini_stormshield.eu requested review of D34394: Fix mvneta driver that doesn't handle fixed link properly.
Feb 28 2022, 3:27 PM

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.
Feb 21 2022, 10:23 AM
sebastien.bini_stormshield.eu requested review of D34327: mac_veriexec: Authorize reads of secured sysctls.
Feb 21 2022, 10:21 AM

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 17 2022, 8:50 AM

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#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 16 2022, 1:20 PM

Feb 15 2022

sebastien.bini_stormshield.eu added inline comments to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
Feb 15 2022, 9:20 AM
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.

Feb 15 2022, 9:18 AM
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?

Feb 15 2022, 9:13 AM
sebastien.bini_stormshield.eu added inline comments to D33246: Improve parameters handling in veriexec.
Feb 15 2022, 8:46 AM

Feb 14 2022

sebastien.bini_stormshield.eu added inline comments to D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
Feb 14 2022, 8:49 AM
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...

Feb 14 2022, 8:46 AM

Jan 18 2022

sebastien.bini_stormshield.eu requested review of D33926: This change allows the veriexec binary to (optionally) load its CA store from a verified tarball..
Jan 18 2022, 4:27 PM

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.

May 31 2021, 1:42 PM
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 (.)

May 31 2021, 10:03 AM
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?

May 31 2021, 9:17 AM