search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.3k stars 1.11k forks source link

Make Superuser remain accessible even through bans #3898

Open Stefan-comkmits opened 4 years ago

Stefan-comkmits commented 4 years ago

Why is Possible Ban Superuser?

2019-11-16 17:29:48.897 1 => Ignoring connection: 127.0.0.1:1581 (Global ban) I think there is more Information needet,about Ban status to the User, and SuperUser Should ever Connnecting to the Server.
Krzmbrzl commented 4 years ago

Who banned the SuperUser? What permissions did that user have?

Stefan-comkmits commented 4 years ago

I have Admin Rights,and Ban a UnregistretUser,on Local Maschine (127.0.0.1). And then Not Only the User is Banned,also the IP is Banned.

Make sense for StandartUsers,but the SuperUser is then even unable to connect from a Banned IP.

Krzmbrzl commented 4 years ago

Ah okay now I think I understand. Let me summarize to make sure, we are on the same page:

Is that correct?

Stefan-comkmits commented 4 years ago

I ban with my Real User (Admin/on Client1) the Unregistret (on Client2/Multi Mumble),yes.

And i think its Possible not Only on Local Maschine (its of course a esoteric Mode). But whats when i behind a NAT?

I Think when i am behind a NAT,and i Banned a User behind the same NAT, i can not Connecting with any User,to Remove that Mistake.

Krzmbrzl commented 4 years ago

Without looking into the code I assume that a ban is always registered for a certain IP address which makes sense because what else should you ban for an arbitrary client. One should however distinguish between an unregistered user an a registered one. In the former case you should ban the IP and in the latter that specific user.

And when a client is connected the checking should be done in the same fashion. Check the IP for an unregistered user to see if it has been banned but for a registered one, check the user itself, regardless of the IP.

@davidebeatrici @Kissaki thoughts on this?

davidebeatrici commented 4 years ago

We could also add a prompt, asking the user whether he wants to ban the IP address in addition to the account.

Kissaki commented 4 years ago

The bans can contain any one or multiple of:

From the ban list / ban editor:

image

Doesn’t the add ban dialog already provide choices for this? I can't test here without users.

Kissaki commented 4 years ago

@Stefan-comkmits So what you are saying is an ip-banned user should be able to log in to the superuser account?

I don’t think I agree with that. A ban is a ban, and for a reason.

Stefan-comkmits commented 4 years ago

@Kissaki In a IPv6 world who have every User his own IPv6 adress,you have right. The Problem is,NAT is Real in the World.

Its sad a Moderator can Block the Owner. And if wand,you can change the IP in multiple way. For this Reason a ip Ban should hav a lower priority,as a Superuser Login.

Kissaki commented 4 years ago

Would you want or expect user certificate bans to be ignored on SuperUser logins as well?

Feel free to create a feature request for that with your reasoning.

I think this ticket is a bit too unspecific. It was useful to find a common understanding, but probably did its job now and can be closed?

You also said

I think there is more Information needed, about Ban status to the User

which was not specified yet. Where do you want more information? The login deny explicitly states that it is a global ban that denies it.

Stefan-comkmits commented 4 years ago

From my Point of View the SuperUser is to Overwrite Everything. I Make a Mistake(in my case i Ban User for Testing,and cannot Login with my User),and then i can Repair it with Login as SuperUser.

I think this ticket is a bit too unspecific. It was useful to find a common understanding, but probably did its job now and can be closed?

Yes,fell free to Close it. I think you have Understand my Point a little bit.

Thank you,for your Work. :1st_place_medal:

Krzmbrzl commented 4 years ago

From my Point of View the SuperUser is to Overwrite Everything.

I think I have to agree with Stefan on this one. I mean what is the point of a SuperUser if not having special privileges others don't have. And presumably the SuperUser is the one responsible for the server (if not the owner) so denying him/her access to it seems very weird...

Kissaki commented 4 years ago

That is assuming authentication is valid and non-destructive. Suppose your superuser password got leaked, for one reason or another, but the user or malicious participants ip network is banned, then disregarding bans on superuser authentication would be a big problem.

Another thing to consider is that banning could be an effective counter-measure for specific types of DoS attacks; if the aggressor were spamming authentication requests. Again, disregarding bans on superuser authentication would open that door again.

Krzmbrzl commented 4 years ago

If the SuperUser password is leaked, there are problems in any case. Don't really see that as an argument against the case here...

For the DoS-part: The server has to check whether the user is banned on connect anyways. Thus previously checking whether it is the SuperUser (with the correct password), shouldn't hurt much (I think). I don't see how that would make a DoS attack more potent :thinking:

Kissaki commented 4 years ago

I was thinking that root access (or a provided web access by a hoster) where you would also set or disable the superuser would be acceptable, or possibly preferably.

But I agree now that we should probably also allow a workflow where that access is not available. In that case the superuser password is set and the login needs to remain accessible in all cases as the fallback.

Kissaki commented 4 years ago

We may want to provide a configuration setting to disable that though. But maybe in those cases simply disabling the account (unsetting the password) would be preferable and acceptable. That would save us the configuration setting and its implementation.