Secondary group Admin assignement

[Developer]

Hello,

Currently none root admins with ACP access are unable to edit/delete root admin group users,but are able to add root group to mask to none root admin users.
They are also able to add root admin group mask to secondary group.
Is it a bug or intended to work that way ?

[bfarber]

Non-root admins cannot apply a root admin group, either as secondary or primary group. Permission masks, while you tie them to a group yourself, are not actually tied to a group, so we don't block forum permission masks in any way. It would be extremely difficult to do that with the flexibility of the permission sets presently.

[Developer]

So if i am a global moderator with ACP access,search for X user,then move him to root admin group(primary or secondary) and click edit,teh system will return error ?

Congrats with Zend certification.

[bfarber]

Yes, if you are an administrator (but not a ROOT admin) you cannot move any other user into the root admin group (this is, of course, assuming you are using 2.2/2.3 - I think this bug might have existed in early 2.1 versions, but don't remember exactly when the fix was applied).

In all honesty, root admin shouldn't even be an option in the drop down and multiselect menus. If you find as a non-root admin you can move someone into the root admin group, I'd recommend submitting a ticket so we can take a look.

[Developer]

I have opned ticket and reported another issue related to group change.
Ticket number 431190

[Jason H]

Think the whole point of this is something that I brought up in this bug report..

http://forums.invisionpower.com/index.php?...mp;bug_cat_id=4


Basically, if what I am thinking is the case here is actually the case.. This user has setup ACP restrictions on User A, which is a member of the "Admin" group (Making that group up, but..)... Because he ONLY wants that member to be able to edit other members profiles (move them between groups, etc).

BUT.. The problem is, that user could register a new account, promote that new account to the Admin group (same group he's in), and therefore use the newly promoted account to completely bypass the ACP restrictions in place.

So.. It all ties back to that bug report.. I think the Root Admin part is not part of this equation.. A non-root admin cannot promote to root admin.

The problem is, there's a gaping hole in the ACP restrictions. If you want to allow someone access to edit members profiles, that gives them access to change user groups, and therefore, the ability to promote a user into their own group, and therefore bypass ACP restrictions.


Now.. Don't ask yourself the question of why you would give someone you think might do that ANY access to the ACP.. Because that blows this whole thing out of the water.. But...


I think it's probably smarter to make it so that only Root Admins can promote users to any group that has access to the ACP.. This is going to be a mild problem for some admins, i'm sure. But it's far safer than what we have now.. Either that or allow ACP restrictions by group.

Which also brings up another gaping hole.. A standard administrator can make any other group an admin group. I don't think this should be allowed. Because there's another end-around.. If a standard admin is allowed to edit groups, the restrictions are useless. They could easily promote another group to ACP access and bypass the restrictions, -OR- they could just create an entirely new group with ACP access...


Now.. Anyone else reading this.. "Gaping hole" is a relative term. Calm down. You'd have to GIVE someone ACP access for this to happen.. So, I would consider this a security hole, but we're not talking about a hacking tool particularly. Because you have to give someone access to the ACP for them to pull this off. I'm being a bit overly dramatic about it, but in the grand scheme.. It's pretty bad if you rely on the ACP restrictions. So, this also tracks back to if you're worried about someone doing this.. Why the hell did you give them ACP access in the first place? But.. It should be addressed, IMO.

I say Root Admin is the board owner. They have full access. Only they can make admins or admin groups or promote users to those groups.

[Louis M.]

The other thing I see on this issue is that someone with group edit rights can make a group an admin cp allowed group. I ran a test and it clicked in my head that if they granted ACP access to a members group there would potentialy be a lot of admins I had no idea existed previously. I wholeheartedly agree with Jason and think that only an admin should be able to promote someone to an admin group or to assign ACP access to an existing group.

I also personally think that by default all new admins created have total restrictions in place and require an admin to grant access to a person. On the presumption of least amount of access to do what you need, not total access while removing stuff you don't want them to do.

[bfarber]

Think the whole point of this is something that I brought up in this bug report..

http://forums.invisionpower.com/index.php?...mp;bug_cat_id=4

Basically, if what I am thinking is the case here is actually the case.. This user has setup ACP restrictions on User A, which is a member of the "Admin" group (Making that group up, but..)... Because he ONLY wants that member to be able to edit other members profiles (move them between groups, etc).

Actually, this is partially wrong. If "User A" has restrictions, and they promote someone to an admin, that NEW admin has the SAME restrictions as User A.

That doesn't apply to changing a member group to admin, however.

The other thing I see on this issue is that someone with group edit rights can make a group an admin cp allowed group. I ran a test and it clicked in my head that if they granted ACP access to a members group there would potentialy be a lot of admins I had no idea existed previously. I wholeheartedly agree with Jason and think that only an admin should be able to promote someone to an admin group or to assign ACP access to an existing group.

I also personally think that by default all new admins created have total restrictions in place and require an admin to grant access to a person. On the presumption of least amount of access to do what you need, not total access while removing stuff you don't want them to do.

I'd like to overhaul the ACP restrictions a bit too. I'd like group-based ACP restrictions, and some more granularity, I suppose. Least -> Most instead of Most -> Least is a good idea too, however with the way the restrictions work now that would be a tad tricky (though not impossible).

[Jason H]

Actually, this is partially wrong. If "User A" has restrictions, and they promote someone to an admin, that NEW admin has the SAME restrictions as User A.

That doesn't apply to changing a member group to admin, however.

<Johnny Carson> I did not know that </Johnny Carson>

I wonder if Developer knows that. Because, I think that is the point of this whole thing.

I still think the better idea is to

1) Eliminate secondary Root Admin.. Confusing and a royal PITA
2) Only Root Admins can promote to any ACP group
3) Only Root Admins can allow/disallow a group to access ACP
4) Just in case... The Subscription system does not allow promotion to any ACP enabled group..? Off topic, but still a good idea. I think only Root Admins should have access to that system as well.
5) Only Root Admins can edit admin groups.


A possibility is keeping the Root Admin secondary group, and allowing those secondary Root Admins to do the above. While still locking them out of the SQL Toolbox and components.

[bfarber]

I like all but #1 - a lot of admins put people as secondary root admins to hide the fact that they are root admins from the general public, while still allowing the member to do the administrative tasks. Everything else sounds good in my mind.

[Jason H]

How about 5a, then? The part where a secondary root admin can do all the things blocked in 2-5, but still doesn't have a TRUE root admin account?

Honestly, with the secondary group searching and List all Admins functions.. I'm not entirely sure why the secondary doesn't have full Root Admin privs.. Back in early 2.1, where you couldn't search by secondary group.. It made sense.. Not sure it does now. I still haven't quite figured out why non root admins cannot access the components tab.. Well, they can access it.. Just can't do much.. Things like chat, etc..

If the Secondary Root Admin is to remain a limited Root Admin.. I think there does need to be a notifiction that it is limited somewhere. That is in the top 5 problems that come in via tickets.. Either "I've deleted my only Root Admin" or "I set myself as a secondary Root Admin and now it doesn't work"

[bfarber]

Perhaps if it's a secondary root admin, they *should* have full root admin privileges?

[Jason H]

Wasn't there a big to-do about this back in 2.1.x?

As I recall, it was ORIGINALLY set like that(Full access.. Back in 2.1.0).. However, it was backed off to the current settings.. Now.. I THOUGHT it was done because there was no way to search for a secondary group in 2.1.. And until 2.1.6(?), if someone was added as a secondary admin.. There was no real way to tell short of a DB query. With 2.1.7 and the security center/list all admins, that limit went away. So, I thought the functionality was crippled due to that.

If that is indeed why it was crippled in the first place.. The reason for the crippling is gone, and I agree with you.. Make it fully functional. I just assumed that there was some Twilight Zoneish reason as to why it didn't have full function. With 2.2.x and higher having both the ability to search based on secondary group and the List All Admins feature.. No real reason I can think of to keep it as is..

It would probably be wise to include that it changes in a Release Note of some sort in whatever version it's put into.. Could be a nasty shock to some people who have someone as a secondary root admin and DON'T want them to access the SQL Toolbox.

[Developer]

As far as i remember yes there was a bug in previous versions of IPB and one of my none root admins promoted himself to root admin group and performed tasks which i didnt obliged him to.

[Louis M.]

Jason and Brandon,

Maybe I am reading this thread wrong (or at least part of it), but if there is a concern of taking the Root Admin out of the Root Group, why don't you hardcode it for Admin 100% of hte time or make it so there is no possibility of him getting changed. I know hard coding for user 1 in queries is not a safe thing but on the user edit you could put a check in to stop the group permissions edit on user 1. I would also suggest that you do something similair on the group Root Admin itself.

@Jason,

I really like having the Secondary Admins group. It does make life a lot easier for me. I use the root admin group for my first user (install user) and then I use the administrators group for 2 people, myself and one other person. I did add ACP to one other group but I added restrictions to every single one of the members in the other group.

@bfarber,
I am thinking here about the Root Admin and Administrator groups. I operate quite well as I explained to Jason. do we NEED to have more than one person in Root Admin group? Administrators can accomplish almost everything that they need to with out issues. If there is something that Root needs to , then dust him off and put him back away when done. If we are assigning everyday use accounts to Root Admin group, its like running on Linux with root access. It doesn't make much sense to me. This may help cut back on tickets with users accidentally locking out the root accounts and it will defiantly help limit the possibility of Root Admin Hijacking.

[Jason H]

Jason and Brandon,

Maybe I am reading this thread wrong (or at least part of it), but if there is a concern of taking the Root Admin out of the Root Group, why don't you hardcode it for Admin 100% of hte time or make it so there is no possibility of him getting changed. I know hard coding for user 1 in queries is not a safe thing but on the user edit you could put a check in to stop the group permissions edit on user 1. I would also suggest that you do something similair on the group Root Admin itself.

That's part of what we're dealing with.. You would be shocked at the number of people who do this.. Mainly new users.. But i've had long-term users who have pruned the Root Admin account accidentally. That is what we're basically brainstorming here. I don't think you hardcode a root admin account, because it does need to be flexible.. But there probably needs to be a warning before deleting that account. And, really.. That was only part of this.. We've really branched this topic out. It's almost becoming a full security audit of the ACP the path we're going.

@Jason,

I really like having the Secondary Admins group. It does make life a lot easier for me. I use the root admin group for my first user (install user) and then I use the administrators group for 2 people, myself and one other person. I did add ACP to one other group but I added restrictions to every single one of the members in the other group.

We're talking about secondary Root Admin. Right now, if you program someone as a secondary root admin, they only have standard admin abilities. No access to the SQL Toolbox and logs and other features. What we're talking about is either eliminating the secondary ROOT admin, or making it actually a FULL root admin. Likely the second option.

Main point of this is if you set a user as an Admin, and only give them access to the "manage Users" section of the ACP.. They could promote a group to admin status, create a new user, put it in that group, and bypass the ACP restrictions. That's the crux of the matter here. What we're talking about is how to lock down standard admins a bit better.. Standard admins, IMO, should not have access to the subscriptions system (because $ is involved) and they should not be able to promote or demote anyone to/from admin status, nor should they be able to make a group or demote a group from admin status. That is something that only a Root Admin should be able to do.

@bfarber,

I am thinking here about the Root Admin and Administrator groups. I operate quite well as I explained to Jason. do we NEED to have more than one person in Root Admin group? Administrators can accomplish almost everything that they need to with out issues. If there is something that Root needs to , then dust him off and put him back away when done. If we are assigning everyday use accounts to Root Admin group, its like running on Linux with root access. It doesn't make much sense to me. This may help cut back on tickets with users accidentally locking out the root accounts and it will defiantly help limit the possibility of Root Admin Hijacking.

Absolutely there needs to be the option of more than 1 Root Admin. Various reasons.. From support to co-owners of forums. And if you have multiple people sharing a login, if 2 people tried to do something in the ACP at once, one would constantly be booted out.

[Louis M.]

That's part of what we're dealing with.. You would be shocked at the number of people who do this.. Mainly new users.. But i've had long-term users who have pruned the Root Admin account accidentally. That is what we're basically brainstorming here. I don't think you hardcode a root admin account, because it does need to be flexible.. But there probably needs to be a warning before deleting that account. And, really.. That was only part of this.. We've really branched this topic out. It's almost becoming a full security audit of the ACP the path we're going.

We're talking about secondary Root Admin. Right now, if you program someone as a secondary root admin, they only have standard admin abilities. No access to the SQL Toolbox and logs and other features. What we're talking about is either eliminating the secondary ROOT admin, or making it actually a FULL root admin. Likely the second option.

Main point of this is if you set a user as an Admin, and only give them access to the "manage Users" section of the ACP.. They could promote a group to admin status, create a new user, put it in that group, and bypass the ACP restrictions. That's the crux of the matter here. What we're talking about is how to lock down standard admins a bit better.. Standard admins, IMO, should not have access to the subscriptions system (because $ is involved) and they should not be able to promote or demote anyone to/from admin status, nor should they be able to make a group or demote a group from admin status. That is something that only a Root Admin should be able to do.

Absolutely there needs to be the option of more than 1 Root Admin. Various reasons.. From support to co-owners of forums. And if you have multiple people sharing a login, if 2 people tried to do something in the ACP at once, one would constantly be booted out.

Wow Jason,

Lots of good stuff in there. As I am sitting here getting yelled at by the wife for not getting dressed to go grocery shopping I can't help but write this.

Maybe this is my idea of computer security in general wearing off on this topic but just looking at this from the admin accounts side, there needs to be one user who is the "god" or "root"; ultimatly its the person who owns the hosting account. but on the forum side of the house or nexus side, I REALLY think that there should be only one root admin, and he is above everyone else. No one should be able to ater him (even if its a query against the member ID and disabling certain features in group and member edit screens).

I am a tad confused. It is very early here and I have had 0 caffene. I will play with this on my ubuntu box once it finishes installing. if i put_joe_user in secondary group of root admin its not a true root admin or are you talking secondary group being set to administrator?

Either way I agree with what you said on the subs system. I mentioned it earlier and after talking with a few friends (also IPB admins) we all agree we want to see when someone (other than root admin - the account from install) is granted ACP access its 100% locked down. the root admin himself has to go in and add the access to specific areas. Brandon was looking into this if I recall correctly. The other thing we want to see is a finer control areas of IPB. Again I believe Brandon was looking into this, but in its current state we could use some more flexability in assigning rights.

I think I may have been misunderstood. When I was talking about root admins I was asking if we need more than 1 root admin. Currently my site has only one. I know the account info for it, but rarely use it. I use my "administrator" group account for my daily admin life. This may be military though process, old school admin thoughts, etc. but I really don't know if i like more than 1 root admin. After all one person bought the software, one person bought the hosting service, etc.

Oh well. Wife aggro.....

Louis Markham

[atomicknight]

Quite a number of administrator group checks are only based on primary group membership, so setting a user as only a secondary root admin will make him/her essentially just a standard admin. Seems kind of silly really since it's horribly inconsistent in terms of what "root admin-only" tasks can be performed with only a secondary group and what tasks need a root admin primary group membership - root admins should just be root admins regardless of which type of group is being used.

My take on the matter is that admins should start out with no privileges on promotion and should not be able to change their own privileges (or those of any other admins). That way, the root admin(s) can allow only what needs to be allowed without allowing any sort of "self-promotion" that could cause such issues.

[Jason H]

Maybe this is my idea of computer security in general wearing off on this topic but just looking at this from the admin accounts side, there needs to be one user who is the "god" or "root"; ultimatly its the person who owns the hosting account. but on the forum side of the house or nexus side, I REALLY think that there should be only one root admin, and he is above everyone else. No one should be able to ater him (even if its a query against the member ID and disabling certain features in group and member edit screens).

And this is mainly what we're talking about.. I understand that YOU feel there should be only 1 Root Admin user, but the fact is that some users want to have 5 or 6 people who have that ability. I set mine up so that Brandon has a Root Admin account while some testing is happening.. So.. There does need to be the ability to have mutliple "Root Admin" accounts. But, I also agree with you that the people doing 5 or 6.. I don't agree with that. but if we don't give the option, then they share 1 user/pass.. And that's a worse idea.

I am a tad confused. It is very early here and I have had 0 caffene. I will play with this on my ubuntu box once it finishes installing. if i put_joe_user in secondary group of root admin its not a true root admin or are you talking secondary group being set to administrator?

joe_user would NOT be a true root admin. Put him as a secondary Root Admin, primary of standard admin.. He will be able to edit users (though not the Root Admin user) and he will not be able to access logs or the SQL Toolbox.

That's another thing we're discussing. The reason that functionality is crippled is because of what I mentioned in Post #13. Back when secondary groups were introduced, a secondary Root Admin DID have full abilities.. But then it was realized that there was no way to search for a user based on secondary group membership, and THAT was a problem. Solution was to cripple the account. Bad news to have a hacker set themselves up as a secondary root admin and have no way to find them.

Either way I agree with what you said on the subs system. I mentioned it earlier and after talking with a few friends (also IPB admins) we all agree we want to see when someone (other than root admin - the account from install) is granted ACP access its 100% locked down. the root admin himself has to go in and add the access to specific areas. Brandon was looking into this if I recall correctly. The other thing we want to see is a finer control areas of IPB. Again I believe Brandon was looking into this, but in its current state we could use some more flexability in assigning rights.

I think I may have been misunderstood. When I was talking about root admins I was asking if we need more than 1 root admin. Currently my site has only one. I know the account info for it, but rarely use it. I use my "administrator" group account for my daily admin life. This may be military though process, old school admin thoughts, etc. but I really don't know if i like more than 1 root admin. After all one person bought the software, one person bought the hosting service, etc.

I don't know about the ACP being on lockdown and rights being enabled. Seems the majority of users, you want them to have full access (with certain exceptions.. Such as Subscriptions, Logs, SQL Toolbox, etc)..

And.. I agree with you about 1 Root admin, for the most part. but.. There are times where you need more than 1 Root Admin account. Most folks, if they open a support ticket, and we need ACP access to look, would prefer to create a new account rather than give their ACP details.. And that's fine. But, if they can't create a new root Admin account...

Quite a number of administrator group checks are only based on primary group membership, so setting a user as only a secondary root admin will make him/her essentially just a standard admin. Seems kind of silly really since it's horribly inconsistent in terms of what "root admin-only" tasks can be performed with only a secondary group and what tasks need a root admin primary group membership - root admins should just be root admins regardless of which type of group is being used.

My take on the matter is that admins should start out with no privileges on promotion and should not be able to change their own privileges (or those of any other admins). That way, the root admin(s) can allow only what needs to be allowed without allowing any sort of "self-promotion" that could cause such issues.

Right. That's basically what we're getting at here.. Though I don't think the ACP should be locked by default. Generally, i'm with you on you start with max security and the user can loosen it.. But I don't see it in this case. But.. ONLY the Root Admins should be able to promote users to admin, create admin groups, etc. Should a standard admin be able to create a moderator? Most likely. Honestly.. If Global Mods were able to change user groups from the forum itself.. Would they even need ACP access? So.. Maybe there's another angle to this?

Part of the good news is that until I opened my big mouth here.. Noone really probably thought about this being an end-around of ACP restrictions.. Brandon had the foresight to block one of the methods that I thought could be used to bypass them, but missed another.. Which takes a warped mind to think of in the first place. Which is why I thought of it.

I'm so close to totally agreeing with you on the non-root admin groups being locked down by default.. But then I just think "Crap.. I'm going to have to go through and unblock everything for my admin group when I upgrade?" And I just think of the PITA that would be.

One more thing that should be addressed.. You NEVER want to promote to an admin group based on posts. That functionality should be checked. If a group is an ACP group, you cannot select it in the promotion dropdown. One bad click and after 5 posts a member becomes an admin. You can't promote them to Root Admin that way, but still.. You could promote them to an ACP group by accident.

[Louis M.]

Cleared out the huge reply.... read up one post if you want :D

Jason I agree wiht you a lot. I do see the need for more than one admin, and I can see what a PITA it would be to have to give the access to people. Here is an idea. Make it only the root can change admin group memberships. Make it so new admins are at 0 privvies. Now for ACP Restrictions let us have the power to set GROUPS up for access. I have 4 people on a small board that all are in the same group and all share the same access. Let it base off of either secondary or primary. Add in the restrictions a Deny. If there are conflicting permissions then the least access (or deny) is granted. I know that is getting a lot more complex, but kinda midel it off of Windows 2k+ security guidelines (not trying to start an MS vs Linux war). If there is a grant permmission and a deny then the deny takes priority.

One thing I want to touh on again real fast... give a user acp access and access to manage groups. Log on as that user. have the user edit the members group (or what ever you call it) and give them ACP access. In my eyes this is a HUGE security risk as you now have some rogue admins out there. I tried it on a test board here at my house and it worked great (from a hacker POV). If you want access to my test board let me know and I can give the info.

As atomicknight said there should NEVER be an option to auto promote to admin. It should be banned from the start as a safe guard against new people to the software.

Jason you and I agree on a lot here and I was thinking on a lot of this stuff. Just no idea why I never opened my mouth. Thanks for getting this going. I am sure whatever comes out of this IPS is going to make some changes to the ACP system because of this. I look forward to more talk on this matter!!!!

Louis Markham

[Will L.]

I have always thought it should be like so

if you are a:

• ROOT ADMIN: you can promote anyone to any group
• non-root admins: should promote people to any team (if you do not waant them promoting people to admin team then open restriction for that use so that they have no access to edit users)
• also I say there should be an option where forum owner upon install sets what root admins be SUPER-ADMINS that can do everything remove/ban/suspend/demote other root admins, this way here if you as member #1 is site owner you do not want other admins root or non-root touching your account you are protected as super-admin

[Jason H]

[*]

non-root admins:

should promote people to any team (if you do not waant them promoting people to admin team then open restriction for that use so that they have no access to edit users)

The point that you're missing is that most people give people access to the ACP for the simple reason that they want a moderator/admin to be able to change member groups. Something that cannot be done outside of the ACP.

And the further point is, if you open that up, and you restrict the ACP to just those actions.. It is possible to bypass the restrictions by making a different group an Admin group. Or by promoting another user to the admin group (though restrictions are copied in this instance)

And as for all the suggestions of a "Super User" on installation... If you give access to the SQL Toolbox.. All that is moot. Because the SQL toolbox allows you to change yourself to that group. So, whatever user is the "Super User".. I can edit through the toolbox and make them no longer the super user. Whether I have to change their member number or group number or whatever. So.. This idea is pretty much not possible.

This has really devolved (or evolved) into a How to Secure the ACP topic from what it was originally. But, that's not a bad thing. What areas should ONLY Root Admins have access to? And you go from there to saying basically that if you WANT someone to have access to those areas, then make them a root admin.. And if you're not comfortable making them a root admin, then why would you want them accessing such a secure area anyway?

Would you really trust someone to access the Subscription system, where they can see how much money the forum makes on subscriptions, but don't trust them to edit the chat settings?

[Developer]

Agree..

[Louis M.]

Jason,

I can see instances where I might want someone to have access to the subs but not other things, but I'm not trying to start splitting hairs either :P.

Why can't we give the the mods or admins a limited user manager outside of the ACP. It could easily be limited to not a llow the users access to "privileged groups" that the root sets in the group options in the full ACP. This would eliminate a lot of people requiring ACP access (from my experience) as once the settings are in place not a whole lot changes, the exception being member.

Not start derailing this thread again but let's take a quick look at what we could put in a limited form in the "MCP" (ModCP) to make the job easier. An option could be added to the group membership saying "Can Access MCP" right below the "Can access ACP" line.

I think this might actually blend in better with giving mods the access to manage members more efficiently. However this does NOT fix the issue of once someone has ACP-> member edit access they can still circumvent the system. This just gives us a work around in the mean time.

Louis