Subject: Re: Getting rid of /dev/veriexec
To: YAMAMOTO Takashi <>
From: Elad Efrat <>
List: tech-kern
Date: 12/02/2005 15:04:31
YAMAMOTO Takashi wrote:

> why?

Loading fingerprints to Veriexec is a two-phase process: first you
create a hash table with N entries, then you load file-by-file from

I think that doing this is cleaner by using sysctl(), much like
how we use sysctl() for the network PCBs, for example.

First we sysctl() to create a table, then we sysctl() to add a file
to the table; we can also sysctl() to remove a file from a table. It's
simply, to me, a cleaner and more logical interface to this kernel

Two issues were brought up wrt/device vs. sysctl:

1. An admin can chown a device to give a user a special role -- true,
   but Veriexec does an explicit suser() (and there's no, at the moment,
   intention to change that). This should be addressed by capabilities,
   if any.

2. If, some day, Veriexec would have the feature of returning the hash
   for a given file (or any other configuration inspection) it might
   be desired that a process with root privileges in a chroot cage (...)
   could be prevented from accessing that information.

   This is also a matter that should be addressed in the proper way, and
   not be used as an excuse to leave things as they are today. :)


Elad Efrat