Date: Wed, 20 Jun 2018 14:22:49 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: <cem@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>, <sjg@juniper.net> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl Message-ID: <32898.1529529769@kaos.jnpr.net> In-Reply-To: <CAG6CVpXtK1uRow3=R=n6i82bhHKBB_3qGvCB0SxctsMLb=RDjQ@mail.gmail.com> References: <201806200108.w5K18sIR050132@repo.freebsd.org> <CAG6CVpV124ze%2BY6xX2ZFqbM%2B3hJNEJWR2qpnChpey=PmiW6qXg@mail.gmail.com> <96021.1529475664@kaos.jnpr.net> <CAG6CVpXtK1uRow3=R=n6i82bhHKBB_3qGvCB0SxctsMLb=RDjQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Conrad Meyer <cem@freebsd.org> wrote:
> The signing of manifests does not exist in the patch series committed.
Nor will it, the singing of manifests is a build thing.
But as I mentioned earlier I think the loader verification code can be
leveraged for a verifying userland veriexec tool similar to that in
Junos.
> (If NetBSD does something broken, that is not an excuse to copy it.)
How about we backout the veriexecctl tool - which is the only bit your
comments apply to - and which we do not use.
All the signing etc discussion is orthogonal to the kernel part.
> > A veriexec loader that leverages signed manifests requires some signing
> > infra. That's a big topic all by itself.
>=20
> It *may* require that. However, even without that, admins could
> reasonably manage their own PKI in some fashion, independent of
There still needs to be a tool that they can use.
The work I've done on the loader should make this simple since it
provides for OpenPGP signatures as well as X.509 based certs.
> FreeBSD's infra. But it requires the support code to verify
> signatures, as in the "verify" part of veriexec, which is wholly
> absent.
Yes. As above, reverting the veriexecctl tool would be fine,
I'll commit a proper verifying tool along with the loader bits.
I have to do some tweaking of one of my libs first.
> Again =E2=80=94 this is a discussion for arch or phabricator, with the se=
ries
> reverted first.
For code that's off by default why is reverting a requirement?
> many other glaring performance problems. If you care about MAC
> performance in a secure algorithm in 2018, perhaps look at any of
> these great options:
>=20
> * SHA-3 (Keccak)
> * Blake2-b
> * Poly1305-{AES,Salsa,ChaCha}
The framework allows folk to add any hashes they like.
For us, anything which is not NIST approved is of little interest.
Obviously many people have the luxury of not haveing to bow to NIST,
so again the framework provides.
> FreeBSD has had this code for 0 years. It's a novel feature here.
> There is no reason to introduce SHA-1 in novel security features in
> 2018.
As mentioned earlier (in this thread? hard to say), no reason it needs
to be enabled by default.
FreeBSD.org if they are going to sign the packages they ship, need to
make a decision about the hashes they want to support.
> And no, upstreaming the signature verification code is completely
> orthogonal to implementing signing infrastructure.
Not really since one dictates the other.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32898.1529529769>