Current-Users archive

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

Re: about veriexec

On Mon, Dec 15, 2008 at 01:44:22AM +0200, Elad Efrat wrote:
> >
> >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.
> >

At strict level 1, that is correct.  You should get warnings in the
syslog that the signatures mismatch.  The whole idea of this mode is
to check your policy works correctly without risking locking yourself
out of the machine.

> >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 think the documentation needs a bit of an update unless I am

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

You should just see notifications...

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


Brett Lymn
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."

Home | Main Index | Thread Index | Old Index