New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve msfdb to work with pg_createcluster, pg_ctlcluster and other Debian-specific tools #11369

Open
rhertzog opened this Issue Feb 7, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@rhertzog
Copy link

rhertzog commented Feb 7, 2019

The msfdb script that you provide does not run out of the box on Debian/Ubuntu/Kali (see #10939) because the Debian packages do not provide pg_ctl and initdb in the default PATH. Those binaries are only available in the versioned directories /usr/lib/postgresql/XX (eg /usr/lib/postgresql/11 for PostgreSQL 11).

The reason for this is that the Debian packages provide some higher level helper tools to manage multiple instances of the database:
https://manpages.debian.org/stretch/postgresql-common/pg_createcluster.1.en.html
https://manpages.debian.org/stretch/postgresql-common/pg_ctlcluster.1.en.html
https://manpages.debian.org/stretch/postgresql-common/pg_lsclusters.1.en.html
https://manpages.debian.org/stretch/postgresql-client-common/pg_wrapper.1.en.html

Due to this, in Kali we are still using our former "msfdb" script (see discussion https://bugs.kali.org/view.php?id=4374). But we are thus missing the features to control the webservice server.

It would be nice if your msfdb script could work in a Debian-based environment by leveraging the above tools instead of trying to use pg_ctl directly. They can be used to create user-specific PostgreSQL instances (which is likely the main reason why you want to use pg_ctl and initdb directly) and they are manageable through systemd units.

$ pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
10  main    5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
$ systemctl list-units postgresql*
UNIT                       LOAD   ACTIVE SUB     DESCRIPTION               
postgresql.service         loaded active exited  PostgreSQL RDBMS          
postgresql@10-main.service loaded active running PostgreSQL Cluster 10-main
postgresql@11-main.service loaded active running PostgreSQL Cluster 11-main

At a personal level, I find the end-to-end management of the database service questionable. Kali's version of msfdb just assumed that there was a "postgresql" service that we can start and stop through systemd and would initialize the metasploit database in the pre-existing PostgreSQL instance and it would be nice if your msfdb allowed us to continue doing that without requiring a supplementary PostgreSQL instance.

On a related note, this cluster management system is already managing dynamically the port numbers above 5432 for alternate clusters and it is thus likely that your own allocation logic in msfdb would conflict with this one.

cc @sbrun @busterb

@mkienow-r7

This comment has been minimized.

Copy link
Contributor

mkienow-r7 commented Feb 7, 2019

@rhertzog I recently looked into the postgresql-common package included in Debian / Kali and manually reproduced the setup steps currently performed by msfdb except using the postgresql-common tools. When creating a new cluster one must provide the PostgreSQL version. If more than one version is installed would you prefer to use the latest version?

In your preferred use case, how is Metasploit configured to use pre-existing PostgreSQL instance?

@rhertzog

This comment has been minimized.

Copy link
Author

rhertzog commented Feb 7, 2019

When creating a new cluster one must provide the PostgreSQL version. If more than one version is installed would you prefer to use the latest version?

I guess so. Usually when there are two versions, it's because an upgrade is needed/planned and we are better creating the metasploit cluster using the latest version. That said a point can be made that if the ugprade did not happen yet, we might be better using the default version (i.e. the one which runs on port 5432). The difference is rather minimal and both approaches are OK.

But somehow it depends on how you envision the use of the cluster... do you want a single metasploit cluster on the system shared by all users or do you want to setup a cluster for each metasploit user?
Right now the database configuration in Kali is stored system wide (/usr/share/metasploit-framework/config/database.yml) and thus shared by all users. But if we really want to support multiple users, the better design would be to have a dedicated database for each user but all managed in a shared cluster (instead of having multiple clusters).

In your preferred use case, how is Metasploit configured to use pre-existing PostgreSQL instance?

In Debian/Kali, if you install postgresql (which we do by way of dependencies) you can assume that there will be an instance configured to run on the default port 5432 and that it will be started with "systemctl start postgresql". From there on, our current msfdb just creates a dedicated user and database in that instance (by relying on the fact that the "postgres" unix user is the super user for that instance).

See https://git.kali.org/gitweb/?p=packages/metasploit-framework.git;a=blob;f=debian/extra/msfdb;h=a480a03faaf46d44f3787a4f1dccb61b8e50fa97;hb=refs/heads/kali/master for how we handled that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment