ejabberd default permissions

I upgraded my ejabberd to 2.1.0-rc1 today and while doing so decided to start with a fresh ejabberd.cfg. This reminded me of something I noticed when I first switched to ejabberd but forgot to blog about. The default permissions in ejabberd are a bit surprising.

Before I go into details, I’m not arguing any of these problems are the end of the world but I think it would make lot of sense for ejabberd to ship with a safer configuration and allow administrators to open things up if desired.

MUC permissions

The default MUC (XEP-0045) access list is:

{access, muc, [{allow, all}]}.

This access list allows all JIDs, even those on remote servers. The default MUC configuration uses this access list for all operations.

{mod_muc [
    %%{host, "conference.@HOST@"},
    {access, muc},
    {access_create, muc},
    {access_persistent, muc},
    {access_admin, muc_admin}
]},

As a result, the default configuration allows users on other XMPP servers to create rooms on the local MUC server. Probably not that big of a deal but I don’t see a good reason why my server should be hosting channels for external users. Worse, would I be responsible if the channel was used for some nefarious purpose?

I created a new access list which only allows local JIDs and used this access list for access_create and access_persistent.

{access, muc_create, [{allow, local}]}.
{mod_muc [
    %%{host, "conference.@HOST@"},
    {access, muc},
    {access_create, muc_create},
    {access_persistent, muc_create},
    {access_admin, muc_admin}
]},

Pubsub permissions

The default Pubsub (XEP-0060) permissions are:

{access, pubsub_createnode, [{allow, all}]}.

Again, this allows all JIDs, even remote ones to create nodes on the Pubsub server. I changed this to the following.

{access, pubsub_createnode, [{allow, local}]}.

In-band registration

This really amazes me. In-band registrations (XEP-0077) allows users to connect to an XMPP server and create new accounts. This is enabled in the default configuration that ships with ejabberd.

{access, register, [{allow, all}]}.

I wonder how many ejabberd servers there are with unexpected users?

The solution is documented immediately above the register access list definition.

{access, register, [{deny, all}]}.

2 thoughts on “ejabberd default permissions

  1. Pingback: Dan Siemon (dsiemon) 's status on Sunday, 18-Oct-09 02:33:56 UTC - Identi.ca

  2. Badlop

    Hi,

    I’ve committed in ejabberd trunk SVN default configuration your proposal to restrict to local accounts MUC and Pubsub creations. It will be included in the incoming ejabberd 2.1.0-rc2.

    Regarding the third proposal (complete restriction of In-Band Registration), I’ve opened a ticket: https://support.process-one.net/browse/EJAB-1074

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *