Veriexec

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Veriexec

Conrad Meyer-2
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Simon J. Gerraty
> 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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Stephen J. Kiernan
In reply to this post by Conrad Meyer-2
On Tue, Jul 3, 2018 at 7:09 PM, Conrad Meyer <[hidden email]> wrote:

> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Conrad Meyer-2
On Thu, Jul 5, 2018 at 10:48 AM, Stephen J. Kiernan <[hidden email]> wrote:

> On Tue, Jul 3, 2018 at 7:09 PM, Conrad Meyer <[hidden email]> wrote:
>>
>> 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.)

> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Stephen Kiernan
On Thu, Jul 5, 2018 at 2:06 PM, Conrad Meyer <[hidden email]> wrote:

> On Thu, Jul 5, 2018 at 10:48 AM, Stephen J. Kiernan <[hidden email]>
> wrote:
> > On Tue, Jul 3, 2018 at 7:09 PM, Conrad Meyer <[hidden email]> wrote:
> >>
> >> 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.

> 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. 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Conrad Meyer-2
Hi Stephen,

On Fri, Jul 6, 2018 at 1:09 PM, Stephen Kiernan <[hidden email]> wrote:
> On Thu, Jul 5, 2018 at 2:06 PM, Conrad Meyer <[hidden email]> wrote:
>> (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'.

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

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

Ok, that's great.  Thanks.

Best,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Stephen Kiernan
On Fri, Jul 6, 2018 at 4:29 PM, Conrad Meyer <[hidden email]> wrote:

> Hi Stephen,
>
> On Fri, Jul 6, 2018 at 1:09 PM, Stephen Kiernan <[hidden email]>
> wrote:
> > On Thu, Jul 5, 2018 at 2:06 PM, Conrad Meyer <[hidden email]> wrote:
> >> (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'.
>
> > 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Veriexec

Simon J. Gerraty
In reply to this post by Simon J. Gerraty
Simon J. Gerraty <[hidden email]> wrote:
> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"