RFC Services Access and Bahamut Interaction
I thought I'd give this mailing list a much-needed kickstart. More coming to the helpers mailing list after Christmas (maybe after new years). This is meant to be an unofficial RFC (request for comments) pertaining to the information posted here, so post away. ;p TOPIC: ChanServ/NickServ access and Bahamut/Services interaction. OBJECTIVE: Potential enhancements to be explored by services coders, and to provide helpers with information. * NickServ Access NickServ ACC 3 = Nick is ID'd to NickServ NickServ ACC 2 = Nick matches an access entry NickServ ACC 1 = Nick is registered NickServ ACC 0 = Nick is not registered Special thanks to " phnx " for providing the following info for NickServ ACC 1... Either the person using the nick isn't the owner, or the owner is using it and they registered the nick before Jan 1, 2003 (and they never turned Enforce On). The owner, under this scenario, had to AUTH via the web link (not through services). Else, the nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and never set Enforce On. * ChanServ Access ChanServ ACC 5 = Founder access via ChanServ identification ChanServ ACC 4 = Founder access via NickServ identification ChanServ ACC 3 = Founder access via Founder access entry ChanServ ACC 2 = Channel SOp, or matches an SOp access entry ChanServ ACC 1 = Channel AOp, or matches an AOp access entry ChanServ ACC 0 = All Other users/channel guests ChanServ ACC -1 = Akick'd users ChanServ ACC -2 = Channel has been Frozen or Closed * NickServ Access Entries Adding access entries (to channel founder, SOp and AOp nicknames) has many implications to proper channel management and security. ChanServ ACC 3/2/1 can be obtained by matching AOp or above access entries. SECTION 1: GENERALITIES * Ident > Access Matches > OpGuard 1.1 The ChanServ Ident feature is set on, by default, upon new channel registrations for very good reasons. This does two things: a. It negates access matches (and potential problems for channel managers/founders). b. It negates ChanServ's Unsecure feature (which requires access matches to function). 1.2 The ChanServ OpGuard (Secured Ops) feature is negated by access matches (ChanServ ACC 3/2/1). Only Ident can negate access matches; not OpGuard. 1.3 The ChanServ Unsecure feature is superceeded by Ident, and has no bearing on OpGuard. With Ident off, unsecure does nothing more than what access matches do by themselves. Basically, unsecure is now obsolete. SECTION 2: OP LISTS & ACCESS RULES 2.1 Only founder can be added to two op lists (by nickname only). Founder and AOp or SOp list. If the founder wants to be on all 3 lists, they must be added by address to the third. AOps and SOps can only be on one list by nickname. To be on both AOp/SOp lists, the second list must be added by address. 2.2 Access Rules 2.2.1 ChanServ Ident must be switched off for access matches to function. 2.2.2 Founders (ChanServ ACC 5/4/3) can be akick'd, but AOps/SOps cannot. ChanServ ACC 3 founders can ADD/DEL SOps. 2.2.3 AOps/SOps cannot be added if their nick/address is on the akick list. 2.2.4 Akicks (ChanServ ACC -1) can be bypassed if the akick'd matches founder/SOp/AOp access entry (or they are founder). Akick'd users can send channel memos (as long as they match the memo level set for the channel). 2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 or higher (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) access list. Note: Must be SOp or higher to add/del akicks. =============================================================== Services Coders: With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why? 1. SOps cannot add the founder to the akick list (because the founder is on the SOp list). 2. Adding founder to the AOp list is pointless; SOps can delete the AOp entry then akick the founder at will. 3. If the founder wants off the SOp list (to use his/her 100 max SOp-entry quota) they can do so after channel registration. 4. If founder is the founder, what would it matter if the founder is akick'd? ANSWER: The founder changes founder name, but still uses the original founder name (to visit the channel). The new founder doesn't have an access entry (or Ident could be on). SOp adds the original founder nick to akick. Founder, using original founder nick, gets banned upon re-entry into the channel. Ultimately, founders get a truer sense of being top dog (without the hassle of adding their other ID to the SOp list). =============================================================== 2.2.6 With Ident switched on, ChanServ ACC 3 doesn't exist. SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0) 3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the same as an expired nick. 3.2 A founder purposely drops his founder nick. He/she will continue to have ChanServ ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take over C) anyone else doesn't set themself as founder. 3.3 Such a founder can do all channel-related management they could before with two exceptions: A) They cannot send channel memos (a registered nick is required to send/read memos). B) They cannot drop the channel (ChanServ memos the drop code). 3.4 They can bypass Ident/Restrict/Opguard/etc features. SECTION 4: BAHAMUT IRCD/SERVICES INTERACTIONS 4.1 Not much is known of the interation between services and bahamut IRCd. I believe this matter needs to be explored more by helpers/coders, and the information needs to be shared (on this mailing list, or by updating http://docs.dal.net/ with proper information). 4.2 Examples of interactions: 4.2.1 ChanServ mkick and channel excepts. Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process. 4.2.2 ChanServ restrict and channel excepts. When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest. 4.3 Excepts, like all channel modes, are IRCd command features. The bond bahamut and services share is more apparent than what we think we know. This avenue needs to be explored more. Maybe we can get this mailing list kickstarted with said chatter (pertaining to findings resulting from testing any and all interactions). Well, happy holidays to all. tchin tchin! PapaSmurf
On Fri, Dec 18, 2009 at 11:05 AM, PapaSmurf <freedried@yahoo.com> wrote:
2.2.2 Founders (ChanServ ACC 5/4/3) can be akick'd, but AOps/SOps cannot. ChanServ ACC 3 founders can ADD/DEL SOps. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It sounds like a bug. if AOP/SOP have that protection, founder should too.
2.2.3 AOps/SOps cannot be added if their nick/address is on the akick list. 2.2.4 Akicks (ChanServ ACC -1) can be bypassed if the akick'd matches founder/SOp/AOp ^^^^^^^^^^^^
It would seem that 2.2.3 is counterproductive and probably unwanted then. If AKICKs can be bypassed due to an AOP or SOP match, it is conceivable, the Founder might want to add someone as AOP in order to allow them to bypass akick. An example would be: AKick *!*@*.aol.com but give a 'friend from AOL' AOP access. In addition to setting a channel mode +e except. Actually an '/ChanServ AKEXCEPT' or '/ChanServ EXCEPT' list would be more proper here.
2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 or higher (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) access list. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm not sure what was meant here.. I don't think someone with ACC -1 can set any akicks. Assuming the channel has IDENT enabled, I believe identification to a SOP or higher nickname is required, and ChanServ ACC 2 or higher is required...
ANSWER: The founder changes founder name, but still uses the original founder name (to visit the channel).
In that case, (of course), the original name is no longer Founder. ChanServ doesn't currently allow multiple founders. ---------
4.2.1 ChanServ mkick and channel excepts.
Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process.
I would suggest that this a bug, as it defeats the purpose of the MKICK command, as we originally recommended it, as it was proposed, that is, and as it got implemented... And it stands as a significant reduction in MKICK's usefulness. MKICK is meant to completely purge a channel, as the "sledgehammer" against takeover and desync situations. Purging even +e users is imperative for MKICK to really be useful in the most extreme circumstances, as +e users are still members of the channel... Obviously the channel won't be emptied and reset, if some people are left in the channel after a MKICK. And most importantly, special channel modes such as "+k" could be left in place, leaving the SOPs and FOUNDER locked out of their channel. --------- -- -J
PapaSmurf wrote:
NickServ ACC 1 = Nick is registered
ACC 1 = User is not online or is not recognized by NickServ as the true owner.
Either the person using the nick isn't the owner, or the owner is using it and they registered the nick before Jan 1, 2003 (and they never turned Enforce On). The owner, under this scenario, had to AUTH via the web link (not through services). Else, the nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and never set Enforce On.
The dates are incorrect but it is really irrelevant if enforce is enabled or not, ACC 1 simply means the user is registered but either is not recognized as the real owner or is not currently online.
1.1 The ChanServ Ident feature is set on, by default, upon new channel registrations for very good reasons. This does two things:
a. It negates access matches (and potential problems for channel managers/founders). b. It negates ChanServ's Unsecure feature (which requires access matches to function).
Unsecure is currently broken but it'll make sense to let unsecure override ident (for the founder nick only).
Services Coders:
With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why?
Easier to simply prevent sops from being able to akick founders. This will probably be added on the next services upgrade.
SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0)
3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the same as an expired nick.
3.2 A founder purposely drops his founder nick. He/she will continue to have ChanServ ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take over C) anyone else doesn't set themself as founder.
Users can identify to ChanServ if they have the correct password for channels with dropped/expired founder that is still registered, the only difference is that they cannot drop it.
3.3 Such a founder can do all channel-related management they could before with two exceptions:
A) They cannot send channel memos (a registered nick is required to send/read memos). B) They cannot drop the channel (ChanServ memos the drop code).
ChanServ doesn't memo drop codes. Users cannot drop channels with dropped/expired nick like you said, though.
4.2.1 ChanServ mkick and channel excepts.
Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process.
ChanServ does kick everyone.. they may re-join right after they get kicked which is bad. I consider it as a bug, we should get it fixed (by either temporary sqlining the channel or having ChanServ remove the invites/excempts lists before starting a masskick).
4.2.2 ChanServ restrict and channel excepts.
When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest.
4.3 Excepts, like all channel modes, are IRCd command features. The bond bahamut and services share is more apparent than what we think we know. This avenue needs to be explored more. Maybe we can get this mailing list kickstarted with said chatter (pertaining to findings resulting from testing any and all interactions).
While only the founder can set restrict on and only sops/founder can add akicks, invites/excempts can be added by any op (sometimes even during netsplits) which is why excempts aren't trusted by ChanServ and are removed if ChanServ needs to enforce a restrict/akick. I don't know how many people will like a services invites/excempts list that will let founders/sops override restrict/akicks. It may or may not be added in the future. -Kobi.
Kobi Shmueli wrote:
While only the founder can set restrict on and only sops/founder can add akicks, invites/excempts can be added by any op (sometimes even during netsplits) which is why excempts aren't trusted by ChanServ and are removed if ChanServ needs to enforce a restrict/akick.
I don't know how many people will like a services invites/excempts list that will let founders/sops override restrict/akicks. It may or may not be added in the future.
-Kobi.
I'd love to see this functionality, myself. I know if I let chanserv set the ban, then I set the exempt things will work out as I want them to, however someone will invariably clear the banlist or a bot running a timer will remove the ban. Which means the next time the akick is triggered, there goes the exempt. I think a strong case could be made for the situation where you want to akick *!*@baddomain.com yet still allow *!gooduserident@baddomain.com -- Kevin -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Hey everyone, Just a quick clarification from myself, chanserv does prevent everyone from joining back the channel for some time. I think the time is also adequate for chanserv to allow users to re-join back. Perhaps Kobi meant to say something else in regards to temporary sqlining ? Example: ________________________________________________________ [10:11:45] -ChanServ- Masskick of #****** is complete. [10:11:48] -ChanServ- The channel #****** is currently being masskicked, preventing you from using the UNBAN command. [10:11:49] -ChanServ- Please wait a few moments and try again. [10:12:10] * Attempting to rejoin channel #****** [10:12:10] * Rejoined channel #****** ________________________________________________________ Regards, White`Shark On Thu, Dec 31, 2009 at 3:56 AM, Kobi Shmueli <kobi@dal.net> wrote:
ChanServ does kick everyone.. they may re-join right after they get kicked which is bad. I consider it as a bug, we should get it fixed (by either temporary sqlining the channel or having ChanServ remove the invites/excempts lists before starting a masskick).
-Kobi. _______________________________________________ DALnet-services mailing list DALnet-services@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services
Omar Khan wrote:
Just a quick clarification from myself, chanserv does prevent everyone from joining back the channel for some time. I think the time is also adequate for chanserv to allow users to re-join back. Perhaps Kobi meant to say something > else in regards to temporary sqlining ?
Example: ________________________________________________________ [10:11:45] -ChanServ- Masskick of #****** is complete. [10:11:48] -ChanServ- The channel #****** is currently being masskicked, preventing you from using the UNBAN command. [10:11:49] -ChanServ- Please wait a few moments and try again. [10:12:10] * Attempting to rejoin channel #****** [10:12:10] * Rejoined channel #****** ________________________________________________________
While you cannot use ChanServ UNBAN/INVITE right after a masskick, you could still just join the channel after getting kicked by ChanServ if you were +e and you do it fast enough. -Kobi.
ACC 1 simply means the user is registered but either is not recognized as Even if enforce is enabled, a non-recognized user should be 'ACC 1' for the 60 second grace period to ID, until enforcement forces a nick collide.
Unsecure is currently broken but it'll make sense to let unsecure override ident (for the founder nick only).
Ignoring what it does currently. And it's hard to say for sure, as the detailed design documentation for services, like formats/design of channel access records, has never been made known to us. But... Logically, turning on "UNSECURE" should provide access to every ChanServ command to the founder (except special ones like drop / set founder,). When UNSECURE is on and one of these are true: *If IDENT is disabled, when the channel is currently registered to an address mask instead of a NickServ nickname , and the online user matches the Founder address mask/pattern that was set. *If IDENT is _disabled_ , an actual NickServ nickname is listed as founder, and the online user is ACC 2 or higher to the founder nickname (through an access list match or identify). *OR: If IDENT is enabled, and the user is identified to the founder nickname If UNSECURE is off, then all founder-level commands, such as 'SOP', 'SET', , etc, should require identification with ChanServ, regardless of NickServ ACC level. We already have an 'IDENT' option for dealing with nickname identification level issues. It is good for IDENT to be on by default. Perhaps there should simple be a 'SECURE' option enabled by default and discard both IDENT and UNSECURE options, and then, matters would be simpler. I suggest that all channels be forced to either enable IDENT or turn off UNSECURE, by making UNSECURE automatically disabled for any channel with IDENT disabled, "ACC 2 to a founder nickname to utilize founder commands" is asking for trouble. We should be clear on what additional protection channels have when UNSECURE is off. In the above implementation, the benefit of having UNSECURE disabled: * Someone who guesses a founder's NickServ password only gains effective SOP access. The worst possible thing they can do is /NickServ DROP the nickname; which does not delete the channel. * Someone who gains access to the founder's computer with an idle IRC session identified to the nickname, will only have effective SOP access to the channel. -This would be more effective if ChanServ and NickServ 'time out' password identifications. For example: If you identify as founder to a channel, then leave your IRC session idle for a long duration, ChanServ and NickServ should ideally "forget" about your identification, or require you to re-identify, before you may issue further services commands at your current ACC level. -It would be more effective if SOP commands were treated the same way. For example, if a user's last ChanServ or NickServ command was more than a few hours ago, a new identify command with NickServ should be necessary before sending more SOP-level ChanServ commands.
With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why?
Maybe i'm mistaken... but wasn't this the case at one point? I suppose it would be a reasonable quick fix, but truly.. there are enough use-cases for having 'Co Founder' users.. That a new list, or rather, 'founder flag or level' for the access list of some sort should be in order. I would suggest a /ChanServ MANAGER command. which would work the same way as the SOP, AOP commands. But provide most founder commands to a person identified with NickServ on the list, and have all other SOP properties. Auto-add the founder to the MANAGER list on registration, require password identification to change the list. This would also eliminate any current need for "/ChanServ set #channel UNSECURE" By definition 'all channels' are UNSECURE by the old definition. Perhaps the new definition of 'unsecure' would be "All managers are just SOPs, whose only additional privilege is to manage the SOP list." Whereas with unsecure disabled, MANAGERS may use SET commands (other than SET founder)
ChanServ does kick everyone.. they may re-join right after they get kicked which is bad. I consider it as a bug, we should get it fixed (by either temporary sqlining the channel or having ChanServ remove the invites/excempts lists before starting a masskick).
Seems reasonable. Perhaps a 'MODEFLUSH' and 'MKICK' ircd command for U:lined clients only would be in order (the name of the commands isn't important), to assist services, and reduce its need to track new types of state information, regarding new/future IRCD features that might impact MKICK, MDEOP, etc. Could also help assure that a channel can be consistently MKICKed, even if the actual channel userlist has somehow become desynced on some server(s). :chanserv MKICK <channel> :<reason> <- The local server receiving this message forces all local users in the channel to part the channel with the given reason, and propagates ala sendto_serv_butone. :chanserv MODEFLUSH <channel> [<modeset>|*] [<nickname>] <- Reset the specified channel modes to the default (off) state, and propagate the message to all servers but source, * for all modes :chanserv modeflush #channel :be -- clear all bans -- clear all excepts :chanserv modeflush #channel :o -- clear all ops (useful for MDEOP) :chanserv modeflush #channel +* -- clear all modes, ops, bans, excepts, voice, etc So two commands modeflush #channel :e mkick #channel Would be fine for /ChanServ MKICK And the work of tracking except-like things is offloaded from services.
4.2.2 ChanServ restrict and channel excepts. When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest.
Maybe the founder wanted the except? Still... the channel could have just been MLOCK'ed +i with manual invites used. Perhaps we should have a /ChanServ EXCEPT command. With syntax similar to the AKICK command. Otherwise, it makes sense to override EXCEPTs. Or at least a way to 'provide a list of allowed members' without giving them OP access. Still, I doubt this is helpful for most restrict'ed channels, the excepts should simply be removed. -- -J
James Hess wrote:
ACC 1 simply means the user is registered but either is not recognized as Even if enforce is enabled, a non-recognized user should be 'ACC 1' for the 60 second grace period to ID, until enforcement forces a nick collide.
That's what I said, it doesn't matter for services if the nick is [being] enforced or not.
Unsecure is currently broken but it'll make sense to let unsecure override ident (for the founder nick only).
Ignoring what it does currently. And it's hard to say for sure, as the detailed design documentation for services, like formats/design of channel access records, has never been made known to us.
It doesn't do anything at all (besides showing "UnSecure" on ChanServ INFO). It was supposed to do what the help text says (/ChanServ HELP SET UNSECURE).
But... Logically, turning on "UNSECURE" should provide access to every ChanServ command to the founder (except special ones like drop / set founder,). When UNSECURE is on and one of these are true: *If IDENT is disabled, when the channel is currently registered to an address mask instead of a NickServ nickname , and the online user matches the Founder address mask/pattern that was set. *If IDENT is _disabled_ , an actual NickServ nickname is listed as founder, and the online user is ACC 2 or higher to the founder nickname (through an access list match or identify). *OR: If IDENT is enabled, and the user is identified to the founder nickname
If UNSECURE is off, then all founder-level commands, such as 'SOP', 'SET', , etc, should require identification with ChanServ, regardless of NickServ ACC level.
That's an intersting idea, although if people don't trust themselves with founder access, they can add their secondary nick as SOP/AOP (I know a few founders are already doing it).
That a new list, or rather, 'founder flag or level' for the access list of some sort should be in order.
I would suggest a /ChanServ MANAGER command. which would work the same way as the SOP, AOP commands.
But provide most founder commands to a person identified with NickServ on the list, and have all other SOP properties.
Interesting idea, what do others think about it?
Perhaps a 'MODEFLUSH' and 'MKICK' ircd command for U:lined clients only would be in order (the name of the commands isn't important), to assist services, and reduce its need to track new types of state information, regarding new/future IRCD features that might impact MKICK, MDEOP, etc.
Bahamut 1.8.4's old trunk used to have CHANKILL that did the same but it never came into the official release, I'll see what we can do to bring it back. -Kobi.
--- On Thu, 12/31/09, Kobi Shmueli <kobi@DAL.NET> wrote:
From: Kobi Shmueli <kobi@DAL.NET> Subject: Re: [DALnet-services] RFC Services Access and Bahamut Interaction To: "James Hess" <mysidia@gmail.com>, dalnet-services@lists.dal.net Date: Thursday, December 31, 2009, 11:19 AM
But... Logically, turning on "UNSECURE" should provide access to every ChanServ command to the founder (except special ones like drop / set founder,). When UNSECURE is on and one of these are true: *If IDENT is disabled, when the channel is currently registered to an address mask instead of a NickServ nickname , and the online user matches the Founder address mask/pattern that was set. *If IDENT is _disabled_ , an actual NickServ nickname is listed as founder, and the online user is ACC 2 or higher to the founder nickname (through an access list match or identify). *OR: If IDENT is enabled, and the user is identified to the founder nickname
If UNSECURE is off, then all founder-level commands, such as 'SOP', 'SET', , etc, should require identification with ChanServ, regardless of NickServ ACC level.
That's an intersting idea, although if people don't trust themselves with founder access, they can add their secondary nick as SOP/AOP (I know a few founders are already doing it).
That a new list, or rather, 'founder flag or level' for the access list of some sort should be in order.
I would suggest a /ChanServ MANAGER command. which would work the same way as the SOP, AOP commands.
But provide most founder commands to a person identified with NickServ on the list, and have all other SOP properties.
Interesting idea, what do others think about it?
I'd suggest getting rid of the "unsecure" command altogether. I like the ChanServ "manager" idea. Maybe have a new level of op status added ChanServ MOp (Manager Operator), or alter Successor to be automatically added to the SOp list (and give them access to commands to act upon in the absence of the channel founder; such as getting rid of unruly SOps). Limit the altered Successor or MOp entry to one nickname, so a founder knows exactly who changed their channel. Perhaps an access entry match could be dangerous with such a status level, but so is a founder access match. Then you'd have to get into power level between altered successor/MOp and founder access matches. PapaSmurf
Replying to my own post? Oh well, just a couple points... --- On Fri, 12/18/09, PapaSmurf <freedried@yahoo.com> wrote:
From: PapaSmurf <freedried@yahoo.com> Subject: [DALnet-services] RFC Services Access and Bahamut Interaction To: dalnet-services@lists.dal.net Date: Friday, December 18, 2009, 9:05 AM
2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 or higher (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) access list.
I believe it was James Hess , on this mailing list, who stated he was unsure what I meant by section 2.2.5.... Someone is akick'd. The akick'd is on a SOp's (or the founder's) access list. That akick'd user can akick the founder, under current services, if the founder is not concurrently added to the SOp list (as well as being named founder).
4.2.1 ChanServ mkick and channel excepts.
Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process.
4.2.2 ChanServ restrict and channel excepts.
When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest.
4.3 Excepts, like all channel modes, are IRCd command features. The bond bahamut and services share is more apparent than what we think we know. This avenue needs to be explored more. Maybe we can get this mailing list kickstarted with said chatter (pertaining to findings resulting from testing any and all interactions).
Kobi: Couldn't it be added to ChanServ's mkick to unset +e entries like ChanServ's restrict does already? PapaSmurf
On Fri, Jan 1, 2010 at 12:00 PM, PapaSmurf <freedried@yahoo.com> wrote:
I believe it was James Hess , on this mailing list, who stated he was unsure what I meant by section 2.2.5.... Someone is akick'd. The akick'd is on a SOp's (or the founder's) access list. That akick'd user can akick the founder, under current services, if the founder is not concurrently added to the SOp list (as well as being named founder). As far as I know, if the founder is identified to their nickname, or to ChanServ, then ChanServ will not enforce an akick against them, and they will always be able to use the /CS UNBAN command, so they can't be "akicked" in any case..
It is possible to akick *!*@*.*, even though some SOps' last address would clearly be matched by the pattern (unless the SOp list is empty). So is there now something that prevents a mask that matches a current online SOp's host from being added to the list? As far as I know it is (or used to be possible) to SOp *!*@*.*, and still akick *!*@* although this is not recommended for obvious reasons. Apparently adding an akick by nickname doesn't work for a SOP. It's probably more a side-effect of the nickname already existing in the list though (with different flags). Observe, you can't add an AOP listed by nickname to the akick listed by nickname either. In general, using MASKs instead of NICKNAMEs in OP lists is deprecated, or SHOULD have been deprecated a long time ago. New channels can only be registered to NickServ nicknames now... It's not possible to forego NickServ registration and register your channel to a MASK or Set Founder to an address mask anymore. SOp list (and perhaps AOp list) should join the party, and new entries by NickServ nickname only. Except on "legacy" channels registered prior to some date, that have Ident disabled, and already use address masks to list some ops. -- -J
/cs akick #test add *!*@* Notice[ ChanServ [ *!*@* has been successfully added to the AKick list of #test ] /cs sop #test add *!*@* [11:36.43] Notice[ ChanServ [ *!*@* already exists on the AKick list of #test ] /cs sop #test add *!*@*.* [11:37.00] Notice[ ChanServ [ *!*@*.* is too wide a mask ] ChanServ won't allow you to add entirely wildcarded entries to the SOp list. I still think the ability to add access list entries by hostmask is valid. If I own a channel, and I know my ops don't always identify before joining, but I want them still opped when they join, I can give them hostmask entries. Or if I own an ISP or whatnot, and I have a channel for it on DALnet, and I want anyone who is from my domain to have ops on join, there we go.
On Sat, Jan 2, 2010 at 10:43 AM, Vin King <vin.king@gmail.com> wrote:
/cs sop #test add *!*@* [11:36.43] Notice[ ChanServ [ *!*@* already exists on the AKick list of #test ] Well, this kind of strongly suggests the refusal to add something on another list is not a security feature, but more like a "quirk" or mere side-effect of the underlying implementation. .
ChanServ won't allow you to add entirely wildcarded entries to the SOp list. It's probably just naively comparing the mask you type, to exclude that one special case.
I still think the ability to add access list entries by hostmask is valid. If I own a channel, and I know my ops don't always identify before joining, but I want them still opped when they join, I can give them hostmask
The functionality is redundant. If you have IDENT ON, the entries by mask don't grant ops. If you have IDENT OFF, the individual channel operators can use their NickServ Access lists for this, and there is no need to list the mask on the channel itself. In either case, in the present internet, it's a huge security risk, much larger than it was 16 years ago, and the AOP/SOP functionality has stayed basically the same all through this time, despite changes in the threat environment; present day prevalence of botnets, zombies, and proxies-for-hire, listing access by IP address is like hanging a "pwn me please" sign on your channel. The default behavior at least should protect channels against simple spoofing, and not encourage insecure practices. We don't need to give users the equivalent of a POP3 mail account that only authenticates you by IP address, to access your e-mail, or whatnot.
entries. Or if I own an ISP or whatnot, and I have a channel for it on DALnet, and I want anyone who is from my domain to have ops on join, there we go.
This opens the channel to similar types of abuses that occur when *!*@* is AOP'ed One bad kid using the ISP, or one open proxy, can result in a real mess, that can't easily be mitigated (without removing the overly broad mask, anyways). -- -J
James Hess wrote:
The functionality is redundant. If you have IDENT ON, the entries by mask don't grant ops. If you have IDENT OFF, the individual channel operators can use their NickServ Access lists for this, and there is no need to list the mask on the channel itself.
In either case, in the present internet, it's a huge security risk, much larger than it was 16 years ago, and the AOP/SOP functionality has stayed basically the same all through this time, despite changes in the threat environment; present day prevalence of botnets, zombies, and proxies-for-hire, listing access by IP address is like hanging a "pwn me please" sign on your channel.
I disagree with you, just because someone may use it too widely or incorrectly doesn't mean it's a security risk to all channels. Static IPs do exist and people can have legitimate reasons to use them on AOP/SOP lists and we should let them do it if they so wish.
The default behavior at least should protect channels against simple spoofing, and not encourage insecure practices.
Furthermore, ChanServ SET IDENT is enabled by default so masks on AOP/SOP lists won't affect anything unless the founder specifically turns IDENT off. -Kobi.
I've seen a case where a malicious user was using a nick close to the target nick, on an ISP that appeared to be close (but wasn't) ask a channel op (who was an IRCop) in an official help channel for ops, explaining that they didn't want to ident due to another malicious user. What followed was the channel being promptly script kicked. Moral of the story: Security always fails at some point. Rather than restricting every possible avenue for abuse (which will only limit what legitimate users can actually do), we should provide the options, and have a balanced set of defaults which permits ease of beginner use, and provides flexibility for users who understand the system better. We're doing a fairly decent job of that now, but there's always some room for improvement. P.S. IRC itself can be considered a huge security risk, but I for one still love it. On Mon, Jan 4, 2010 at 6:36 PM, Kobi Shmueli <kobi@dal.net> wrote:
James Hess wrote:
The functionality is redundant. If you have IDENT ON, the entries by mask don't grant ops. If you have IDENT OFF, the individual channel operators can use their NickServ Access lists for this, and there is no need to list the mask on the channel itself.
In either case, in the present internet, it's a huge security risk, much larger than it was 16 years ago, and the AOP/SOP functionality has stayed basically the same all through this time, despite changes in the threat environment; present day prevalence of botnets, zombies, and proxies-for-hire, listing access by IP address is like hanging a "pwn me please" sign on your channel.
I disagree with you, just because someone may use it too widely or incorrectly doesn't mean it's a security risk to all channels. Static IPs do exist and people can have legitimate reasons to use them on AOP/SOP lists and we should let them do it if they so wish.
The default behavior at least should protect channels against
simple spoofing, and not encourage insecure practices.
Furthermore, ChanServ SET IDENT is enabled by default so masks on AOP/SOP lists won't affect anything unless the founder specifically turns IDENT off.
-Kobi.
On Mon, Jan 4, 2010 at 5:36 PM, Kobi Shmueli <kobi@dal.net> wrote:
I disagree with you, just because someone may use it too widely or incorrectly doesn't mean it's a security risk to all channels. Static IPs do
I believe it's probably a security risk to most channels that try to use it. Services' online documentation doesn't explain to users the actual differences and side-effects of placing a mask VS placing a nickname on the AOP or SOP list. No amount of "some users have static IPs" justify SOp patterns like *!*sopusername@*.ipt.aol.com And yet, those sorts of patterns have been popular at times (in my estimation). It's easy to make poor decisions, when the documentation doesn't make the implications of certain decisions obvious. Different people arrive at a different understanding of services' features. A consistent, user-friendly interface is often better, than one that provides more features in an inconsistent way.
exist and people can have legitimate reasons to use them on AOP/SOP lists and we should let them do it if they so wish.
Can you explain what it is about your use case, that prevents a NickServ access list from being used instead of a mask on the SOp list? There actually is just 1 use case, where listing by mask in the SOp or AOp list is superior... in a SOP list you can specify nickname!*username@*.host.com In a NickServ access list, you can only specify username@*.host.com (**I suggest that should be changed also, so that you cannot be ACC 2 for ChanServ purposes to a nickname that you are not currently using) Keeping in mind, the NickServ access list can be serviced more easily. For example, if the user's static IP changes, they can delete the entry, without waiting a few days for the founder to come by and fix it. Listing the nickname in the ChanServ list provides better accountability, than a huge list of masks, 3 years ago, when nobody remembers which OP each mask belongs to.
Furthermore, ChanServ SET IDENT is enabled by default so masks on AOP/SOP lists won't affect anything unless the founder specifically turns IDENT off.
Yes... I suppose they may give up with masks in frustration and try nickname.. or keep tinkering around with the settings until they figure out about this strange 'IDENT' setting, and how it's "stopping their ops from getting opped" (for some reason) -- -J
James Hess wrote:
No amount of "some users have static IPs" justify SOp patterns like *!*sopusername@*.ipt.aol.com And yet, those sorts of patterns have been popular at times (in my estimation).
It's up to each channel founder to decide that for their channel.
Can you explain what it is about your use case, that prevents a NickServ access list from being used instead of a mask on the SOp list?
I was talking about SOP/AOP lists in general and not about SOP list in particular. An example would be an events channel run by 5 people from the same company with no regular nicknames. Rather than having them register 5 nicknames (they will never really use) just for the sake of holding op access (or a bot to automatically op them), they could just add *!*@A.B.C.* to the AOP list (or SOP list, if they want to permanently ban people too).
Listing the nickname in the ChanServ list provides better accountability, than a huge list of masks, 3 years ago, when nobody remembers which OP each mask belongs to.
In the past, services let people add un-registered nicks to AOP/SOP by *automatically* converting the entries to *!*ident@*.isp if they were online but not registered. This behaviour has been changed years ago and it is no longer happens automatically like it used to.
Furthermore, ChanServ SET IDENT is enabled by default so masks on AOP/SOP lists won't affect anything unless the founder specifically turns IDENT off.
Yes... I suppose they may give up with masks in frustration and try nickname.. or keep tinkering around with the settings until they figure out about this strange 'IDENT' setting, and how it's "stopping their ops from getting opped" (for some reason)
Then perhaps services should tell users they can't add masks to SOP/AOP lists while ident is enabled and why instead of letting them add it and "ignoring" it. -Kobi.
participants (6)
-
James Hess -
Kevin Buley -
Kobi Shmueli -
Omar Khan -
PapaSmurf -
Vin King