monit status doesn't work

[Massimo Sala]

linux server, monit configuration, regarding http access:

#!

set httpd port 2812
    allow localhost
    allow 10.0.0.0/8
    allow guest:guest read-only
    allow @wheel

From client pc, the browser asks for the credentials; I use guest and it works.

From the server itself, command line, monit status replies with 'You are not authorized to access monit.'

I retry with strace

#!

strace -s 512 -e connect,write /opt/monit/bin/monit status  2>&1 |more

connect(4, {sa_family=AF_INET, sin_port=htons(2812), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)

write(4, "POST /_status HTTP/1.0\r\nContent-Type: application/x-www-form-urlencoded\r\nCookie: securitytoken=88521284dfbc7acea0521e16e11356d1\r\nContent-Length: 58\r\n\
r\nformat=text&securitytoken=88521284dfbc7acea0521e16e11356d1", 209) = 209

write(2, "You are not authorized to access monit..."

Why does monit command-line use the Cookie: securitytoken= ?

The HTTP request with the guest credentials works fine:

"GET /_status?format=text HTTP/1.0\r\nAuthorization:Basic Z3Vlc3Q6Z3Vlc3Q=\r\n\r\n"

[Massimo Sala]

The configuration listed guest:guest

From the server itself, this works:

#!

curl -u guest:guest http://localhost:2812/_status?format=text

So, what's the problem with monit status ?

[Tildeslash]

The CSRF protection is based on "double submit cookie" strategy: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie

It is most not related to the reported error - i have reproduced the problem, will fix.

[Tildeslash]

Fixed: Issue #769: Monit CLI status command doesn't work if only read-only credentials is present in the 'set httpd' statement.

→ <<cset c16158d2c308>>

[Tildeslash]

fix checked in, please can you test?:

wget https://bitbucket.org/tildeslash/monit/get/master.tar.gz
tar -xzf master.tar.gz
cd tildeslash*
./bootstrap
./configure
make

[Massimo Sala]

Hi. Thanks for your support.

I fear the new patch will disrupt something about the previous, non read-only, behaviour.

So before testing we need to understand the monit CLI access vs users and credentials.

NOTE: here I write monit as abbreviation of the executable command monit run from the linux command line

monit : should the commands (summary, status, unmonitor, start, stop, ...) depend on the user credentials ?

With the new patch, which commands does monit allow for read-only users? only passive, like summary and status ?

If I ask monit for a "active, change-things" command (like unmonitor, start, stop, etc...), does monit look for a user with full (non read-only) access ?

[Tildeslash]

Passive commands require at least read-only credentials, active commands require normal (read-write) credentials.

If normal (read-write) credentials are present, monit prefer it, so active commands will work.

If only read-only credentials are present, the active commands will return error.

[Massimo Sala]

Hi. Frantic days also for me.

I installed autoconf automake libtool

./bootstrap : ok

./configure : configure: error: Monit require bison, byacc or yacc

pls can you give me a hint, which package is your 1st choice ?

[Massimo Sala]

I installed bison, flex and zlib-devel.

Now I am stuck on configure: error: PAM enabled but headers or library not found

[Massimo Sala]

Fixed installing pam-devel

Now I am stuck at : Couldn't find your SSL header files.

The server is centos 5.11

I want to be sure to not pull-in the wrong ssl lib. Pls should I install openssl-devel ?

[Tildeslash]

Yes, unless you have ssl.h on your system in which case you should point configure to the directory openssl header files and library files are located:

configure -with-ssl-incl-dir=<DIR> --with-ssl-lib-dir=<DIR>

[Massimo Sala]

Compilation done.

#!

This is Monit version 5.25.3
Built with ssl, without ipv6, with compression, with pam and with large files

monit status : now it is working

monit monitor xxx

You do not have sufficient privileges to access this page

Our config:

#!

set httpd port 2812
allow localhost
allow 10.0.0.0/8
allow guest:guest read-only
allow @wheel

I dont' undertand, you wrote If normal (read-write) credentials are present, monit prefer it, so active commands will work.

Is it considering the group wheel ?

[Massimo Sala]

Please, I ask you for a moment to disregard this

#!

CSRF protection is based on "double submit cookie"

From a user perspective, if I am logged as root on the server, I expect the full usage of monit CLI.

In other words: I am root, what's the purpose of the http authentication ? IMHO the authentication is useful only for normal users.

[Tildeslash]

Regarding the "normal" credentials - it is related to the "allow <username>:<password>" option with no "read-only".

The Monit CLI fetches the status from the Monit daemon and sends commands to it via the HTTP interface. The "allow <username>:<password>" credentials are required for the CLI to work, evem if you're root user.

[Massimo Sala]

Our users are defined in the linux group wheel

In the monit.conf we have

#!

allow @wheel

Per your documentation, this is a definition for full accesss, without read-only.

monit CLI doesn't support it ? it is a bug.

We don't want to add a custom monit user for full access, it will be a set of credentials to manage other than the linux users.

[Massimo Sala]

Pls don't say "we need user:password to calculate the CSRF protection"

This is a mere limit of the internal logic you are using to communicate between the CLI and the running daemon.

From a user perspective:

• the above config line should be sufficient : allow [at]wheel

(here I use [at] otherwise the forum parses wheel as a user name...)

• anyway: if I am logged as root user, I expect to run monit CLI in full access mode, disregarding the configuration.

I think these suggestions fit the expectations of the users. What do you think ?

[Tildeslash]

I didn't mention any relationship between CSRF protection and user:password requirement - did i? These two are separate things.

The "allow @wheel" is not sufficient for CLI - the Monit daemon/server which provides the HTTP service can authenticate users from the wheel group, but the Monit CLI is an HTTP client in this case and it needs to know the user:password so it can pass it as part of the HTTP request to the server. If you set "allow @wheel" only in monit config, it's not possible to get the credentials for the CLI.

In order to use unix authentication without user:password it will be necessary to implement support for different IPC type between monit CLI and server => it's not bug, it's feature request

[Massimo Sala]

This is a mere limit of the internal logic you are using to communicate between the CLI and the running daemon.

I think my suggestions fit the expectations of the users. Call it bug or feature request, the song remains the same.