Hi,
Cem Kayali wrote:
Hello!
I have enabled veriexec support and then created signature file
including /usr/pkg/* binaries and libraries. I see signature file
under etc. After rebooting, sysctl shows
kern.veriexec.verbose = 0
kern.veriexec.strict = 1
To test veriexec strict=1 level, i *updated* some of softwares ie;
lynx and then noticed that system allows to replace monitored
binaries and then execute them although their sha signatures mismatch.
I would expect kernel not to replace those files and not to execute
since man veriexec mentions:
IDS mode (strict level 1)
IDS (intrusion detection system) mode provides an adequate
level of
integrity for the files it monitors. Implications:
- Monitored files cannot be removed********
- If raw disk access is granted to a disk with monitored
files on
it, all monitored files' fingerprints will be invalidated
- Access to files with mismatched fingerprints is
denied**********
- Write access to monitored files is allowed
- Access type is not enforced
Well, maybe someone clarify, probabaly i mis-understand something.
Thanks
Cem
I wonder if it's because of veriexec_renamechk().
Can you please try doing the same thing you did, and either watch the
logs (/var/log/messages), or try doing it in strict level 2? If the logs
show messages about an allowed rename of (a) monitored file(s), or you
can't reproduce the problem in strict level 2, it's probably the rename
policy.
If this is really the case, the attached patch should fix it. IMHO, it
should go in regardless, but I might be forgetting a rationale behind
the current behavior. ;)
If none of the above work, I'll take a closer look. FWIW, local tests
show that Veriexec correctly enforces strict level 1 wrt/modified
monitored files ("cp evilfile goodfile && ./goodfile") and removal of
monitored files ("rm goodfile").
Thanks,
-e.