NetBSD's veriexec port

[Stathis Kamperis-2]

Hello everyone!

Veriexec (from verify executable) is an in-kernel, file system
agnostic, signatures-based, file integrity subsystem for NetBSD[1].
I was wondering if people are or would be interested in it. If there
is enough interest, I could *try* to port it.


Best regards,
Stathis



[1]   http://www.netbsd.org/docs/guide/en/chap-veriexec.html

[Simon 'corecode' Schubert]

Stathis Kamperis wrote:
> Veriexec (from verify executable) is an in-kernel, file system
> agnostic, signatures-based, file integrity subsystem for NetBSD[1].
> I was wondering if people are or would be interested in it. If there
> is enough interest, I could *try* to port it.

I think there are various different ways of achieving this goal, so if you're interested in it you might want to do some research on why the other models are not so good.

I think that disk encryption is a much more important thing, but of course completely unrelated.

cheers
  simon

[Matthew Dillon]

    I'm only luke-warm on the concept.  I would much rather see improvements
    in the virtual kernel technology w/ regards to ease of use, features,
    and performance.  I think we risk serious fragmentation of the security
    space by implementing all these weird little security features that
    we are more likely to trip over then anything else.

    One thing that would be very cool would be a system call that locks out
    all new file descriptor-creating system calls (like open, socket, etc),
    and also locks out namespace functions like remove(), chmod(), and
    functions like fork() and exec*().  The idea being that you would be
    able to start a vkernel and the vkernel would make this system call
    after setting up its virtual network and disk, but before starting the
    init process.

    Another cool feature would be a similar system call which does a
    soft-chroot (I just made up that name)...  Modifying filesystem
    calls would only be allowed within the soft-chroot, but the real
    root of the filesystem would still be whatever it was before.  The
    idea here is that you might have an application which you'd rather
    not trust but which performs important functions on your behalf, and
    you want an easy way to run it without giving it the ability to mess
    around with your entire account.

                                                -Matt

[Stathis Kamperis-2]

2009/10/13 Matthew Dillon <dillon@...>:
>    I'm only luke-warm on the concept.  I would much rather see improvements
>    in the virtual kernel technology w/ regards to ease of use, features,
>    and performance.

I thought that the vkernel technology was mostly for development. Has
this changed or I got it wrong from the beginning ?

Do we aim at a "real" virtualisation solution to be used for
production purposes ?


Best regards,
Stathis

[Francois Tigeot-2]

On Tue, Oct 13, 2009 at 11:13:54PM +0300, Stathis Kamperis wrote:

> 2009/10/13 Matthew Dillon <dillon@...>:
> >    I'm only luke-warm on the concept.  I would much rather see improvements
> >    in the virtual kernel technology w/ regards to ease of use, features,
> >    and performance.
>
> I thought that the vkernel technology was mostly for development. Has
> this changed or I got it wrong from the beginning ?
>
> Do we aim at a "real" virtualisation solution to be used for
> production purposes ?

Well, I didn't know it wasn't ready for production -- it is used everyday by my
company to run a java-based pdf generation tool.

So far so good: there is no critical speed penalty and the legacy binaries are
nicely isolated from the main system by the VM environment.

Your mileage may vary.

--
Francois Tigeot

[Stathis Kamperis-2]

2009/10/13 Francois Tigeot <ftigeot@...>:

> On Tue, Oct 13, 2009 at 11:13:54PM +0300, Stathis Kamperis wrote:
>> 2009/10/13 Matthew Dillon <dillon@...>:
>> >    I'm only luke-warm on the concept.  I would much rather see improvements
>> >    in the virtual kernel technology w/ regards to ease of use, features,
>> >    and performance.
>>
>> I thought that the vkernel technology was mostly for development. Has
>> this changed or I got it wrong from the beginning ?
>>
>> Do we aim at a "real" virtualisation solution to be used for
>> production purposes ?
>
> Well, I didn't know it wasn't ready for production -- it is used everyday by my
> company to run a java-based pdf generation tool.

A few months ago I suggested at #dragonflybsd in EFNET to bring in
some kind of VM manager for vkernel instances, similar to -say- xend
for xen domains. And I've been told that vkernels are mostly used as
testing containers for dragonfly developers. Anyway, I'm glad that you
are using it succesfully for your production needs!

Regarding the fragmentation of the security space that Matt brought
up, I would call it compertmentalisation. For me, it is better to have
many layers of security that all need to be compromised than a single
central point of failure. I'm not a security expert (hey, I don't even
have a CS degree), so my opinion has ground-level importance.

In conclusion, since there is low interest for such a feature, I
withdraw my proposal and I'm looking into new adventures! Thank you
all for taking time to comment.


Best regards,
Stathis

[W B Hacker]

Matthew Dillon wrote:

>     I'm only luke-warm on the concept.  I would much rather see improvements
>     in the virtual kernel technology w/ regards to ease of use, features,
>     and performance.  I think we risk serious fragmentation of the security
>     space by implementing all these weird little security features that
>     we are more likely to trip over then anything else.
>
>     One thing that would be very cool would be a system call that locks out
>     all new file descriptor-creating system calls (like open, socket, etc),
>     and also locks out namespace functions like remove(), chmod(), and
>     functions like fork() and exec*().  The idea being that you would be
>     able to start a vkernel and the vkernel would make this system call
>     after setting up its virtual network and disk, but before starting the
>     init process.

'vkernsecurelevel' perhaps?

>
>     Another cool feature would be a similar system call which does a
>     soft-chroot (I just made up that name)...  Modifying filesystem
>     calls would only be allowed within the soft-chroot, but the real
>     root of the filesystem would still be whatever it was before.  The
>     idea here is that you might have an application which you'd rather
>     not trust but which performs important functions on your behalf, and
>     you want an easy way to run it without giving it the ability to mess
>     around with your entire account.
>

'anklebracelet'

;-)

> -Matt
>

There's plenty of prior art for the first.

The second? - is that akin to applying (v)kernel-class restrictions at a
userspace level? Restricting access to API's?  Snifing calls for safety?

Or?  (spawning an ephemeral vkernel on-the-fly?)

Bill

[Oliver Fromme-46]

Matthew Dillon wrote:
 >    Another cool feature would be a similar system call which does a
 >    soft-chroot (I just made up that name)...  Modifying filesystem
 >    calls would only be allowed within the soft-chroot, but the real
 >    root of the filesystem would still be whatever it was before.  The
 >    idea here is that you might have an application which you'd rather
 >    not trust but which performs important functions on your behalf, and
 >    you want an easy way to run it without giving it the ability to mess
 >    around with your entire account.

I think that's already possible, without the need for a new
system call.

Create a new mountpoint somewhere, nullfs-mount your normal
file systems (/, /usr, /whatever) read-only at that mount-
point, then nullfs-mount the "soft-chroot" directory (can
be even more than one!) at the proper place under that
mount-point with write access.  Then chroot into that
mountpoint, using the regular chroot() system call, or
even jail().

The effect should be the same as the proposed softchroot()
system call, but more flexible and extensible.

It should be easy to wrap it into a script, so you don't
have to do all of that mounting etc. yourself each time.

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd