Since I started using veriexec very recently on 4.0_STABLE and that
the documentation did not explain this, I thought this would be a
right place to ask:
I initially used veriexecgen to index the default system binaries as
a test. I then loaded the hashes into the kernel and activated
veriexec by setting the sysctl variable kern.veriexec.strict to 1.
The system continues to work fine. I also noticed that the value can
continue to be raised but not be lowered until next reboot, as
expected, which is nice. Also as expected, I am unable to delete a
veriexec managed file. However, I noticed that I can move those files
as wanted. Is this expected behavior, or could it be considered a
bug? At this time, I didn't try overwrite a binary file or to move a
file over another.
Also, I tend to constantly get these in kernel logs (a few examples
taken from dmesg | tail):
Veriexec: Incorrect access type. [/bin/sh, pid=11314, uid=0, gid=0]
Veriexec: Incorrect access type. [/usr/bin/true, pid=11314, uid=0,
gid=0]
Veriexec: Incorrect access type. [/bin/sh, pid=26712, uid=0, gid=0]
Veriexec: Incorrect access type. [/usr/bin/true, pid=26712, uid=0,
gid=0]
Veriexec: Incorrect access type. [/bin/sh, pid=967, uid=0, gid=0]
Veriexec: Incorrect access type. [/bin/sh, pid=4750, uid=0, gid=0]
Veriexec: Incorrect access type. [/bin/sh, pid=17683, uid=0, gid=0]
Veriexec: Incorrect access type. [/usr/bin/true, pid=17683, uid=0,
gid=0]
Veriexec: Incorrect access type. [/bin/sh, pid=18068, uid=0, gid=0]
Veriexec: Incorrect access type. [/usr/bin/true, pid=18068, uid=0,
gid=0]
As the system continues to work fine, I guess that these are only
warnings, but what does "Incorrect access type" exactly mean in this
context?
Although I also have a -current box I did not compare with veriexec
on it yet to see if this also occurs.