Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: about veriexec

Elad Efrat, 12/15/08 01:44:

Cem Kayali wrote:


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.


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

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").




- Machine has already been up and I enabled veriexec by '/etc/rc.d/veriexec start' just after inserting veriexec=yes into rc.conf

- I edited veriexec sysctl parameters and they are as:
   kern.veriexec.verbose = 1
   kern.veriexec.strict = 2
   kern.veriexec.algorithms = RMD160 SHA256 SHA384 SHA512 SHA1 MD5

- I did following operations:
   localhost# cd /usr/pkg/bin
   localhost# cp kasteroids
   localhost# rm -rf kasteroids
   localhost# cp katomic kasteroids

- I tried to run ./kasteroids and it launched (it actually started katomic!)

- Signature file:
   localhost# grep kasteroids /etc/signatures
/usr/pkg/bin/kasteroids SHA512 3ca3929b49cff9eafdb2d644..................

- Original checksum:
   localhost# cksum -a sha512 /usr/pkg/bin/kasteroids
SHA512 (/usr/pkg/bin/kasteroids) = e2073b3f71885530cab84865f..............

- /var/log/messages does not contain any error message.

I really surprised nobody untill now has noticed the problem -if there is a problem really. This is 4.99.7X amd64 machine. Maybe problem is within 64 bit systems.

Note, there was no patch as attached to your previous email.


Home | Main Index | Thread Index | Old Index