Re: statement changes suggestions

[Martin Pala]

Martin Pala wrote:

> Jan-Henrik Haukeland wrote:
>
> > Martin Pala <address@hidden> writes:
> >  
> >
> > > We can recommend this setting for security reasons, but i think it
> > > is bad to have different behavior for alert statement in different
> > > tests.
> > >   
> >
> >
> > I take it you are in favor of 1) then? After rethinking I'm also
> > inclined to 1) (that is, do not change the checksum statement) since
> > the proposed changes will implement a not so obvious double-meaning
> > for the alert. Unless others have a better suggestion for using the
> > checksum statement with action I suggest then, that we leave it as
> > is. At least for now.
> >
> >  
> I preffer 2.), e.g. to change it. Reason is, that every statement now 
> allows to customize the behavior and it is not common, that 'stop' is 
> allways correct for all checksum cases => i think it was good point 
> from you and i'm +1 to change it as you proposed, for example:
>
> IF checksum /usr/bin/httpd and expect the sum 
> 4e5309d1956f003bcdff168748bea647 FAILED THEN [ALERT | STOP | RESTART | 
> EXEC]
>
> and keep such scheme for "boolean" tests in the future too. In the 
> case that we will agree on the change, i will modify 'permission' test 
> to reflect it too.
>
>
> Martin
I forgot to discuss new vs. present behavior.

As soon as checksum event will occure, monit will set has_checksum_error 
attribute, but not disable monitoring via do_monitor= FALSE attribute. 
The action is dependant on what user choosed - if used as:

IF FAILED checksum /usr/bin/httpd THEN STOP

it will behave exactly the same way as present:

IF FAILED checksum /usr/bin/httpd


For other actions (such as alert) it could be possible to use timeout 
statement as outlined to constrait number of alerts and disable 
monitoring too. In comparision with present behavior, probably it should 
be possible to reset has_checksum_error attribute in the case that the 
checksum is correct again.
Via such options it is possible to use checksum in insecure way, but 
this is users responsibility. To reach secure alert for checksum and 
stop monitoring, you can use "split" config with utilization of new 
monitoring service types - more complex examples:

1.) "secure" stop:

check process foo with pidfile /var/run/foo.pid
 start program = "/etc/init.d/foo start"
 stop program = "/etc/init.d/foo stop"
 depends foo_bin

check file foo_bin with path /usr/bin/foo_bin
 if failed checksum /usr/bin/foo and expect he sum 123456 then stop

=> in the case of 'foo_bin' checksum error, everything is stopped. 
However as you outlined it is possible security risk, because start/stop 
programs can be compromitted too. In such case following syntax is 
possible, which is based on "kill trust" (if pkill is compromitted, you 
have the same problem as in 1.):

2.) more "secure" stop:

check process foo with pidfile /var/run/foo.pid
 start program = "/etc/init.d/foo start"
 stop program = "/etc/init.d/foo stop"
 depends foo_bin

check file foo_bin with path /usr/bin/foo_bin
 if failed checksum /usr/bin/foo and expect he sum 123456 then exec 
"/usr/bin/pkill -TERM foo"


3.) secure alert

check process foo with pidfile /var/run/foo.pid
 start program = "/etc/init.d/foo start"
 stop program = "/etc/init.d/foo stop"
 depends foo_bin

check file foo_bin with path /usr/bin/foo
 if failed checksum /usr/bin/foo and expect he sum 123456 then alert
 if failed permission 700 then alert   # you can use other file 
specific options as well
 timeout(1,1)

It will send alert (which is secure) that the checksum (or permission or 
whatever failed). Timeout for optional 'foo' process protocol tests is 
independent of foo_bin. The result is, that appropriate person was 
notified about the problem, but monit didn't try to run any program 
which could make the problem worse.


4.) "ultra complicated example" :)

check process foo with pidfile /var/run/foo.pid
 start program = "/etc/init.d/foo start"
 stop program = "/etc/init.d/foo stop"
 depends foo_bin
 depends foo_rc

check file foo_bin with path /usr/bin/foo
 if failed checksum /usr/bin/foo and expect he sum 123456 then stop
 if failed permission 700 then stop
 depends foo_rc

check file foo_rc with path /etc/init.d/foo
 if failed checksum /usr/bin/foo and expect he sum 123456 then alert
 if failed permission 700 then alert
 timeout(1,1)


This is more demonstrates more complicated bindings - it is not 
absolutely secure (possible race condition), but allows to stop the 
program in the case that some other program which is used in stop method 
(rc script is not good example - you can sum for example pkill too which 
is probably better) has correct checksum.

Martin