Veriexec

[Conrad Meyer]

Hi,

It's been two weeks since this went in broken. What's the status?
Has any progress been made on fixing the glaring issues?

(If any fixes have been committed since the initial code dump I
complained about two weeks ago, I must have missed them.)

I agree that perfect should not be the enemy of "good enough," but I
don't believe what's in the tree is "good enough."

Thanks,
Conrad

[Simon J. Gerraty]

Post by Conrad Meyer
It's been two weeks since this went in broken. What's the status?
Has any progress been made on fixing the glaring issues?

The userland tool has been removed - so only the kernel bits remain,
no chance of anyone hurting themselves with it.

I've been working on tweaks to libve to make it suitable for use for a
new loader that can verify the manifest signatures.

Almost ready to start fitting all that into the new stand/ environment
as discussed with Warner a while back.

Work get's in the way sometimes.

[Simon J. Gerraty]

Post by Simon J. Gerraty
I've been working on tweaks to libve to make it suitable for use for a
new loader that can verify the manifest signatures.

FYI this is done, and initial testing completed.
The manifest parser/lexer are derrived from the one in Junos.

The version of mac_veriexec in tree does not yet support storing
maclabels so the veriexec util has some ifdef's to deal with that
(same as Junos where we have to worry during upgrade about
all combinations of new kernel/old util and vice versa.)

I deally I'd like to see mac_veriexec up to date, so we can avoid
all those ifdef's.

Since it relies on the trust store and verification stuff in libve
(D16155) I'm not sure there's any point posting diffs until we close on
that, and in the meantime steve may find enough time to update
mac_veriexec, though as I mentioned before work has an anoying habbit of
getting in the way.

A follow-on effort might be to allow libve to use either BearSSL (needed
for loader due to size), or OpenSSL.

--sjg

[Stephen J. Kiernan]

Post by Conrad Meyer
Hi,
It's been two weeks since this went in broken. What's the status?
Has any progress been made on fixing the glaring issues?
(If any fixes have been committed since the initial code dump I
complained about two weeks ago, I must have missed them.)
I agree that perfect should not be the enemy of "good enough," but I
don't believe what's in the tree is "good enough."

The backout commits for the veriexecctl bits (r335681) and the hooks
into the build to compile the kernel modules (r335682) happened on
26 Jun 2018.

I never really liked veriexecctl to begin with, but wanted to give people
something to be able to load fingerprints with in order to try things out.
Especially since there was ongoing discussion about how provide a
signed manifest or similar method (which is what Simon is working
on) that folks could add their own trust store material to. The intention
was then to have veriexecctl go away. However, veriexecctl, as it was,
did not have much practical use and could provide a false sense of
security, so it was better to just purge it.

There's work in progress on fixing the issues with the meta-data store
and its use. However, family obligations and work has been taking up
time.

-Steve

[Conrad Meyer]

Post by Stephen J. Kiernan

Post by Conrad Meyer
Hi,
It's been two weeks since this went in broken. What's the status?
Has any progress been made on fixing the glaring issues?

The backout commits for the veriexecctl bits (r335681) and the hooks
into the build to compile the kernel modules (r335682) happened on
26 Jun 2018.

I'm familiar with these commits, but was asking more about the topic
you glanced on below. (Additionally, I don't really like the use of
"revert" (as used in the commit message) or "backout" (here) to
describe the kernel changes. The bad code is still present, but
disabled by default.)

Post by Stephen J. Kiernan
There's work in progress on fixing the issues with the meta-data store
and its use.

Ok. Can you elaborate on that progress? Is it happening in public?
Is there any kind of (loose) schedule in mind?

Thanks,
Conrad

[Stephen Kiernan]

Post by Conrad Meyer

Post by Stephen J. Kiernan

Post by Conrad Meyer
Hi,
It's been two weeks since this went in broken. What's the status?
Has any progress been made on fixing the glaring issues?

The backout commits for the veriexecctl bits (r335681) and the hooks
into the build to compile the kernel modules (r335682) happened on
26 Jun 2018.

I'm familiar with these commits, but was asking more about the topic
you glanced on below. (Additionally, I don't really like the use of
"revert" (as used in the commit message) or "backout" (here) to
describe the kernel changes. The bad code is still present, but
disabled by default.)

What would you prefer? It helps to provide an alternative if you wish to
see someone potentially use it in the future. You simply stated you didn't
like the use without providing an alternative.

Note that the commit message for r335682 says "Partial revert of
r335399 <https://svnweb.freebsd.org/base?view=revision&revision=335399> and
r335400 <https://svnweb.freebsd.org/base?view=revision&revision=335400>"
which is exactly what it is. It wasn't a full revert
of the commits, it was only partially reverting them.

Post by Conrad Meyer
There's work in progress on fixing the issues with the meta-data store

Post by Stephen J. Kiernan
and its use.

Ok. Can you elaborate on that progress? Is it happening in public?
Is there any kind of (loose) schedule in mind?

My goal was to have something by the beginning of next week, but
work and life got too busy to be able to make much headway. Work
has been around clocks in VMs, specifically with FreeBSD running
under KVM. I'm resurrecting brianv's https://reviews.freebsd.org/D1435
review, with modifications, and have been in discussions with him since
last week.

As for the veriexec changes, I will be posting them as they are available
to the following branch on GitHub:
https://github.com/hackagadget/freebsd/tree/hackagadget/veriexec
(Note this branch is currently out of date.)

So right now my tentative schedule is to have first cut available for
people to look at around 23 Jul 2018. Also, I want to put up a design
overview on my website once I get all the maintenance done this
weekend.

-Steve

[Conrad Meyer]

Hi Stephen,

Post by Stephen Kiernan

Post by Conrad Meyer
(Additionally, I don't really like the use of
"revert" (as used in the commit message) or "backout" (here) to
describe the kernel changes. The bad code is still present, but
disabled by default.)

What would you prefer? It helps to provide an alternative if you wish to
see someone potentially use it in the future. You simply stated you didn't
like the use without providing an alternative.

It's a minor language quibble — don't worry about it too much. I
would suggest "disable by default," for example. "Revert" and
"backout" have a specific meaning that is approximately 'svn merge -c
-NNNNNN'.

Post by Stephen Kiernan
Note that the commit message for r335682 says "Partial revert of
r335399 and r335400" which is exactly what it is. It wasn't a full revert
of the commits, it was only partially reverting them.

It removes 7 lines out of 2856 lines added in the two commits. I
agree that you're technically correct — it is a partial revert. But I
think it would be more clear and accurate not to describe it as any
kind of revert, given how little (0.25% of lines) was actually
removed.

Post by Stephen Kiernan

Post by Conrad Meyer

Post by Stephen J. Kiernan
There's work in progress on fixing the issues with the meta-data store
and its use.

Ok. Can you elaborate on that progress? Is it happening in public?
Is there any kind of (loose) schedule in mind?

My goal was to have something by the beginning of next week, but
work and life got too busy to be able to make much headway. ...
As for the veriexec changes, I will be posting them as they are available
https://github.com/hackagadget/freebsd/tree/hackagadget/veriexec
(Note this branch is currently out of date.)
So right now my tentative schedule is to have first cut available for
people to look at around 23 Jul 2018. Also, I want to put up a design
overview on my website once I get all the maintenance done this
weekend.

Ok, that's great. Thanks.

Best,
Conrad

[Stephen Kiernan]

Post by Conrad Meyer
Hi Stephen,

Post by Stephen Kiernan

Post by Conrad Meyer
(Additionally, I don't really like the use of
"revert" (as used in the commit message) or "backout" (here) to
describe the kernel changes. The bad code is still present, but
disabled by default.)

What would you prefer? It helps to provide an alternative if you wish to
see someone potentially use it in the future. You simply stated you

didn't

Post by Stephen Kiernan
like the use without providing an alternative.

It's a minor language quibble — don't worry about it too much. I
would suggest "disable by default," for example. "Revert" and
"backout" have a specific meaning that is approximately 'svn merge -c
-NNNNNN'.

Post by Stephen Kiernan
Note that the commit message for r335682 says "Partial revert of
r335399 and r335400" which is exactly what it is. It wasn't a full revert
of the commits, it was only partially reverting them.

It removes 7 lines out of 2856 lines added in the two commits. I
agree that you're technically correct — it is a partial revert. But I
think it would be more clear and accurate not to describe it as any
kind of revert, given how little (0.25% of lines) was actually
removed.

Fair enough.

Thanks.
-Steve