OperClass Restriction on linked servers

These are old archives. They are kept for historic purposes only.
Post Reply
n0kS
Posts: 15
Joined: Sun Oct 05, 2008 12:16 am

OperClass Restriction on linked servers

Post by n0kS »

Hello, I'm very interested in a module that can restrict the maximum allowed operclass on linked servers (like the quarantine option in the link form).

For example, I have a hub, and I connect 2 leaf servers to my hub. I want the maximum allowed operclass on that leaf servers to be Server Admin. I just don't want them to be able to become Network Admins.
A nice module that mods the quarantine option (or something similar will be perfect).

Example:

link server {
options {
quarantine::admin
//quarantine::global
//quarantine
<--- this, without ::<operclass> works as normal, allows only local opers
};
};


Thanks in advance.
Stealth
Head of Support
Posts: 2086
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US
Contact:

Re: OperClass Restriction on linked servers

Post by Stealth »

Unreal's link::quarantine used to work, but has never been a fully functioning feature.

HOWEVER, since you are looking to block ONLY netadmin access you're asking for a pointless feature. You MUST narrow this down to a list of abilities you do not want those opers to do. The reason for this is the main differences between netadmin and server (co)admin is the title shown in WHOIS, and the ability to use usermode +q (as shown in the documentation http://www.vulnscan.org/UnrealIrcd/unre ... #operblock). Server admins can still do everything a netadmin can, which includes: rehashing, can globop, can wallop, can global kill, can manipulate klines, can global notice, etc.

The only thing you can do is have your server ignore usermode +q, although you would have to do that for every user (a remote server will accept and process a KICK command regardless of the target's umodes and the source's abilities).

So since netadmin and server admin are so similar, it makes this proposed module useless, UNLESS you have a list of specific abilities you wish to restrict.

As mentioned in #Unreal-Support, and the thing that no one likes to hear: DON'T LINK IT IF YOU DON'T TRUST IT! Honestly, there is a lot more damage someone on a network can do if they only have the power to affect just their own server than if they have global abilities.
katsklaw
Posts: 1124
Joined: Sun Apr 18, 2004 5:06 pm
Contact:

Re: OperClass Restriction on linked servers

Post by katsklaw »

This is very easy to fix. First and foremost as mentioned, if you don't trust the new admin, don't link them. A truer statement does not exist.

However, it's very easy to tell what flags an oper has. Do /stats o <servername>. If the N flag appears for the oper in question, they have granted themselves NetAdmin. In such a case, /squit their server and deny them reconnection as they are not trustworthy and thus not of the highest quality in maturity and they do not deserve to link to your network.

No one said being a NetAdmin is all fun and games and sometimes you just have to do things you don't want to do in order to succeed.
n0kS
Posts: 15
Joined: Sun Oct 05, 2008 12:16 am

Re: OperClass Restriction on linked servers

Post by n0kS »

Stealth wrote:Unreal's link::quarantine used to work, but has never been a fully functioning feature.

HOWEVER, since you are looking to block ONLY netadmin access you're asking for a pointless feature. You MUST narrow this down to a list of abilities you do not want those opers to do. The reason for this is the main differences between netadmin and server (co)admin is the title shown in WHOIS, and the ability to use usermode +q (as shown in the documentation http://www.vulnscan.org/UnrealIrcd/unre ... #operblock). Server admins can still do everything a netadmin can, which includes: rehashing, can globop, can wallop, can global kill, can manipulate klines, can global notice, etc.

The only thing you can do is have your server ignore usermode +q, although you would have to do that for every user (a remote server will accept and process a KICK command regardless of the target's umodes and the source's abilities).

So since netadmin and server admin are so similar, it makes this proposed module useless, UNLESS you have a list of specific abilities you wish to restrict.

As mentioned in #Unreal-Support, and the thing that no one likes to hear: DON'T LINK IT IF YOU DON'T TRUST IT! Honestly, there is a lot more damage someone on a network can do if they only have the power to affect just their own server than if they have global abilities.
Okay, I was expecting something like this so I could truly extend the description of what I want.
As you say, there is no difference between the abilities NetAdmin and ServerAdmin has, the real difference (and restriction I want) comes with ServerAdmin and Global. I'll try to explain with examples:

quarantine::admin
* The maximum rank is Server Admin, so no usermode flag +q will be allowed (it won't show Network Admin in whois for example), all other abilities will still be allowed.

quarantine::global
* The maximum rank here would be Global, so even if the leaf server puts netadmin in their config, the maximum "powers" the oper will have, would be of a Global operator (<--- here is the list of restricted commands you wanted Stealth).

quarantine::global or quarantine (which already exists)
* This will do what it does at the moment.

The following is something I'm not looking for, and will be very difficult to code, so don't pay much attention to it:
quarantine::custom
command1;
command2;
command3;
// list of restricted commands for the irc operators of the leaf server (doesn't matter if they're netadmin, admin, global, local...) the command is forbidden for all

Example:
quarantine::custom
rehash;
kill;
gline;
....

Thanks for your fast response. It may seem useless but I think it will add a huge configurable power to Unreal's config.
Btw, I repeat, the ::custom block is something I'm not looking at, something I'm not truly interested in.
katsklaw
Posts: 1124
Joined: Sun Apr 18, 2004 5:06 pm
Contact:

Re: OperClass Restriction on linked servers

Post by katsklaw »

n0kS wrote:
quarantine::admin
* The maximum rank is Server Admin, so no usermode flag +q will be allowed (it won't show Network Admin in whois for example), all other abilities will still be allowed.
This is not true. +q is granted by oper flag q/can_setq, it has nothing to do with Server/Network Admins. Plain old Global opers can use +q if they have the oper flag.

You can still use: /stats o <server> and it will show you which oper flags they have. If you don't want them to set +q, then look for operflag q. Please see: http://www.unrealircd.com/files/docs/un ... #operblock for a list of individual oper flags and a list of grouped flags and which individual flags are granted with the group flag.

The NetAdmin group oper flag includes q/can_setq automaticlly, but is not limited to Netadmin. You can have an oper that is a global IRCop that can set +q by setting their flags to oq or can_setq; global; Admin is not required.
n0kS
Posts: 15
Joined: Sun Oct 05, 2008 12:16 am

Re: OperClass Restriction on linked servers

Post by n0kS »

n0kS wrote: quarantine::admin
* The maximum rank is Server Admin (it won't show Network Admin in whois for example), all other abilities (which are for server admins) will still be allowed.
Fix'd.
Stealth
Head of Support
Posts: 2086
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US
Contact:

Re: OperClass Restriction on linked servers

Post by Stealth »

Again, you're failing to provide a specific list.

1) You can't block a title without having every server loading a module, or your own services package to take unauthorized flags off people when they try to use them. This is more of a services item anyway (services are there to regulate who can do what when and things and stuff).

2) You cannot just arbitrarily block commands coming into your server, you would need to perform some sort of counter-action. For G/K/Z:lines and spamfilters, simply ignoring them would create a desync on the network and cause MAJOR problems on the propagated lists. As for forceful commands such as KILL, ignoring one of those would probably crash servers when the client to be killed starts sending commands across the network (when a KILL is sent, the target is to be disconnected immediately, no ifs/ands/buts/whatever). Also remember that sending commands back to the server to undo whatever you do will cause wars between servers and services because they will try to redo it!

3) MODES! The best and only logical way to manage modes is again through services. If you want to block a flag that grants modes, then use your services! Also, oper ranks are issued through modes (see docs), and can be removed by services but not set by services. This should also be done with the proper s2s commands (see protocol docs).

EDIT: Forgot to mention that if you are going to block commands you need some way of knowing if the source of the command is authorized. Don't want to block something that is coming from the internal IRCd process or services! That would make things unstable for sure.
Stealth
Head of Support
Posts: 2086
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US
Contact:

Re: OperClass Restriction on linked servers

Post by Stealth »

I also have no idea why you are so insistent in linking to servers you don't trust. Again, admins can do just as much if not more damage if they are limited than if they are not limited!
warg
Posts: 63
Joined: Mon Jul 12, 2010 8:12 am

Re: OperClass Restriction on linked servers

Post by warg »

This would require communication between the hub and leaf(s). The leaf would have to ask the hub for rules and enforce them through and true. While this may seem like a simple handshake, it's extremely easy to exploit or bypass.

To have this communication between a hub and a leaf, you would need to explicitly define what a hub is. Why can't we do this? We know what a hub is.. a server with many servers connected to it. Therein is the problem.

While we can literally define the purpose of a hub, and what a leaf is, we can't define or enforce how our users route their networks. If every server has many servers connected, then what is the hub? Who then to ask?

The server would then need to ask all it's server questions, "What is the oline inhibition?" You could accept the most restrictive response, yes? ... NO

How do you prevent other servers from setting this configuration themselves, whether by a unrealircd.conf configuration parameter, or a compile-time option?

I believe this would be an easily exploitable feature. Even if you had some way to define who your hub is, there's no way to prevent the Admin from changing that configuration.
"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." — Ralph Waldo Emerson
katsklaw
Posts: 1124
Joined: Sun Apr 18, 2004 5:06 pm
Contact:

Re: OperClass Restriction on linked servers

Post by katsklaw »

#3, A centrally governed system, such as only a ulined server can set a mode, like +r, offers certain benefits. One such benefit is that if an Admin cannot set umode +q via a configuration file, but services can set umode +q on the user definitely prevents rogue admins from setting the mode. I'm currently writing a couple modules that will centralize such access for any user that will set oper flags as well as user modes upon identification.

I've already started this process with my modified 3.2.8.1 by simply removing the ability to give ones self +Nq, but services can still set them. When I'm happy with them I'll release them via Anope's module site.

Anope already sets usermodes:
.:16:31:. <@ChanServ> Now setting umodes +Nq on katsklaw [ID for Nick]

setting oper flags is coming ;)
n0kS
Posts: 15
Joined: Sun Oct 05, 2008 12:16 am

Re: OperClass Restriction on linked servers

Post by n0kS »

Okay I got all your points. Here's the list of commands NOT allowed.
Image
So if quarantine::admin is set, even if netadmin is defined in leaf's config, the oper will have access only to the commands defined in the admin/coadmin column.
Also, for this to work, the linked server MUST be defined as leaf, if it's defined as hub, this won't work. For the simple reason that warg said.

This would work:
hub.server.com
-|
--\
--- leaf1.server.com (quarantine::admin and set as leaf)
--- leaf2.server.com (quarantine::global and set as leaf)
(both leaf connected to one hub)

This would NOT work:
hub1.server.com
-|
--\
--- hub2.server.com (quarantine::global and set as hub) <--- if this server links another server, it must not work
-----|
------\
------ leaf1.server.com (quarantine::admin) <--- hub2 with ::global giving powers to leaf1 as ::admin? must not be possible.
(leaf2 connected to leaf1, leaf1 connected to hub)

===========================
Aside from this, I don't know of services forbidding admin powers or just usermodes? Which services do that?
Post Reply