View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004711 | unreal | ircd | public | 2016-07-03 21:57 | 2016-09-27 07:51 |
| Reporter | admin97 | Assigned To | syzop | ||
| Priority | high | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | wont fix | ||
| Product Version | 4.0.4 | ||||
| Summary | 0004711: quarantine local opers | ||||
| Description | I can't change to the 4.X branch just because it now doesn't allow `locop` type of oper at quarentined servers, while 3.X versions make it possible. Imagine a huge network with many leafs used as front-end servers and you want every server to have its admin as a local oper, while not allowing him to access netadmin privs due to security issues ( we don't want them to use gkline and other global stuff ). Please consider introducing some flexible workaround on the quarentine option, which would allow or disallow local opers on quarentined servers. | ||||
| 3rd party modules | |||||
|
|
I noticed that this problem exists because we can't set +O anymore, any oper-up flag, even localop's, come with +o flag by default. The possible workaround for the quarantine code would be checking if there is a :global permission anywhere in the operclass block, kill the user if it's set so. |
|
|
Related bug: usermode +O not fully removed from the source code https://github.com/unrealircd/unrealircd/blob/unreal40/src/s_conf.c#L3713 https://github.com/unrealircd/unrealircd/blob/unreal40/src/s_conf.c#L3732 https://github.com/unrealircd/unrealircd/blob/unreal40/src/s_conf.c#L7219 https://github.com/unrealircd/unrealircd/blob/unreal40/src/s_conf.c#L7269 https://github.com/unrealircd/unrealircd/blob/unreal40/src/modules/m_mode.c#L1664 Firstly, I would like to apologize for the inconvenience caused by the new fine grained operator privilege (operclass) system on unrealircd-4.x. Unlike unreal 3.2 versions, operator status (i.e. locop, globop, admin, netadmin, services-admin, co-owner, owner) have been broken up to at least 105 individual privileges (see https://www.unrealircd.org/docs/Operclass_block) With such architectural changes made, usermodes such as +OACN have been automatically become useless because they operator statuses no longer reflect their privileges and have since been removed. (i.e. a server owner can have netadmin privilege while disguising as a locop by simply renaming the operclass) It is also worth noting that the operclass architecture is designed such that remote servers and u-lined servers are always (blindly) trusted and operator permissions of opers from remote servers are not known by local server (https://github.com/unrealircd/unrealircd/commit/95667ca9b857ebfe60147c0ec3c41869c8929131) With that being said, I would like to conclude that it is unsafe to link an unrealircd 4 server to any untrusted server because of the reasons mentioned above. If you still wish to upgrade to unrealircd 4, I will discuss possible workarounds with syzop. Again I apologize for the inconvenience caused. I hope my explanation above helps. PS: I am convinced that remote opers are able to view your user's real IP, including yourself, hence exposing yourself to possible (D)DOS attacks. Another reason to only link to trusted servers |
|
|
Thanks for your reply. Firstly, of course I wish to upgrade to 4.X branch and I like the new op.priv. system, along with other features. Thanks for pointing me out at how operator permissions work, and I see now that the workaround mentioned by me above will not work because of that. While I understand that it's better to not link servers from untrusted people, sometimes there are cases when you trust a person, but suddenly he shifts into a threat agent due to some human factors. Or even just an accidental misconfiguration by this person may lead to network-wide problems (low tech skill, for example). Regarding exposing backend's and users IP, yes I am aware of this problem, thus, it doesn't affect me since I connect servers using an openvpn link through Tor, which is pretty stable. All operators are only able to see internal IP addresses of servers. Also all users connect via dedicated Tor hidden service addresses which are assigned to local static IP addresses (unique for each user), and required to be registered. When i need to ban a user, i simply remove his Tor address and he can't connect anymore. Anyway, I understand that this is a very special usage case of your product and I should handle this problem by myself, thus I would be very happy if you can find some workaround for this in a future. |
|
|
Another reason (besides simplification) behind the change is that a malicious server can take down your entire network / can cause huge havoc anyway. Server traffic is regarded as "trusted" (this is by design). So a malicous person could alter UnrealIRCd's source code and work around almost any restriction in 3.2.x anyway. As you said, the locop thing only helps against low-tech threats. (Or accidents, but accidents can be avoided by the new properly tuned oper blocks) Anyway, the locop thing has been taken out and is not coming back (see other answers above). I always like it when people use UnrealIRCd in various non-standard ways but not sure how we could help you otherwise hmmm. |
|
|
Is there a way you can live with current U4 and have other servers reject certain changes? For example ignoring TKL's (=spamfilter/gline/..) from other servers. I don't know if you have a huge list or if it are only a few things. Depending on that maybe something would be possible. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-07-03 21:57 | admin97 | New Issue | |
| 2016-07-04 04:05 | admin97 | Note Added: 0019350 | |
| 2016-07-06 08:19 | dboyz | Note Added: 0019351 | |
| 2016-07-06 19:38 | admin97 | Note Added: 0019352 | |
| 2016-07-09 21:58 | syzop | Note Added: 0019353 | |
| 2016-07-09 22:04 | syzop | Note Added: 0019354 | |
| 2016-07-09 22:04 | syzop | Assigned To | => syzop |
| 2016-07-09 22:04 | syzop | Status | new => feedback |
| 2016-09-27 07:51 | syzop | Status | feedback => closed |
| 2016-09-27 07:51 | syzop | Resolution | open => wont fix |
