veriexec in OpenBSD?

2010-09-01 Thread Milin
Hi all,

I've just read about NetBSD's veriexec and I think it would be great
to have it in OpenBSD.
Is anyone working on porting/rewrite? If not, could you write why? Is
it because some caveat in veriexec's design, not enough time, or just
lack of developers' interest?

Thanks in advance,
Merlyn



Re: veriexec in OpenBSD?

2010-09-01 Thread Ted Unangst
On Wed, Sep 1, 2010 at 4:14 PM, Milin merlyn...@gmail.com wrote:
 I've just read about NetBSD's veriexec and I think it would be great
 to have it in OpenBSD.
 Is anyone working on porting/rewrite? If not, could you write why? Is
 it because some caveat in veriexec's design, not enough time, or just
 lack of developers' interest?

If you don't allow the system to be updated, it won't be updated.
Systems that aren't updated are bad.



Re: veriexec in OpenBSD?

2010-09-01 Thread Kenneth Gober
On Wed, Sep 1, 2010 at 4:14 PM, Milin merlyn...@gmail.com wrote:

 I've just read about NetBSD's veriexec and I think it would be great
 to have it in OpenBSD.
 Is anyone working on porting/rewrite? If not, could you write why? Is
 it because some caveat in veriexec's design, not enough time, or just
 lack of developers' interest?


it looks like an interesting idea, but I'm not sure what vulnerability it
protects you from.  if you don't want users to replace system files, it
seems like a better idea to prevent them from being replaced, rather than
allowing replacement but then preventing access.

not that the 'preventing access' problem is much of an obstacle.  the
article I found via google didn't have a lot of details, but it seems like
if you have rights to replace the files, you probably also have rights to
write an updated signature to /dev/veriexec.  if you're not going to require
the signatures to themselves be signed I really don't see the point.

still, if some developer were interested enough to write a diff, there's
nothing stopping them.

-ken



Re: veriexec in OpenBSD?

2010-09-01 Thread Brett Lymn
On Wed, Sep 01, 2010 at 05:24:21PM -0400, Kenneth Gober wrote:
 
 it looks like an interesting idea, but I'm not sure what vulnerability it
 protects you from.

Stupid things as dumb as someone diddling your path to run a trojan
instead of ls, replacing a library file (or doing the same with
LD_LIBRARY_PATH) or someone slipping trojans into system files.

  if you don't want users to replace system files, it
 seems like a better idea to prevent them from being replaced, rather than
 allowing replacement but then preventing access.
 

Partially but veriexec will prevent unknown binaries running if you
set the right flags so you are protected from running things that are
not part of the validated file set.

 not that the 'preventing access' problem is much of an obstacle.  the
 article I found via google didn't have a lot of details, but it seems like
 if you have rights to replace the files, you probably also have rights to
 write an updated signature to /dev/veriexec. 

The signatures are loaded at a low securelevel and once the
securelevel is raised new signatures are not allowed to be loaded so
you cannot just overwrite signatures.

 if you're not going to require
 the signatures to themselves be signed I really don't see the point.
 

Sure, but this requires crypto in the kernel.  There are not many
respected crypto implementations with an acceptable licence for
incorporating into the kernel.

 still, if some developer were interested enough to write a diff, there's
 nothing stopping them.
 

Go look for openbsd stephanie, it existed but was never integrated.

-- 
Brett Lymn
Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer.