Admin Restrictions?

admin

(Dylan) #1

Anyway to restrict admin privileges rather than giving them access to everything? For example in most other platforms you can add a user to the admin panel solely for the design permissions without having to give them access to every feature or allow people administrator access for the vast majority of features but prevent a complete forum backup from being downloaded or created, major system settings from being changed, etc.

At the very least on Discourse official hosted installations I’d highly prefer the “Account Management” section not be open to every administrator as it contains payment information and the ability to modify subscription settings for the hosting.

I know it’s been mentioned in similar topics before "don’t make someone an admin/mod if you don’t trust them" – in some communities it’s harder than others to do that. For example ones run by volunteers compared to paid staff. However that argument isn’t the main point, if someone’s account is compromised (Could be anything from their email address being social engineered, their password being captured by malicious software, they reuse a password from another breached site, etc) which isn’t all that difficult without multi-factor authentication in place, then they’d have a whole lot of access.

In designing the security architecture we go by the popular principle of least privilege being the safest way to operate and to always assume a breach is possible so do your best to mitigate the fallout as well, not just look only at preventing the breach from happening. That way you’re more prepared. So by that principle you want users to have access only to the abilities they need to perform their job. (You don’t need a retail clerk to be able to download software to the POS system, they should only have access to the actions necessary for their job)

Once the forum settings have been decided, they rarely need to be changed/updated, so it’s not a privilege most administrators would need on a regular basis, once a design is implemented and tested it’s unlikely to change often so not a setting either that people would need often, payment details (especially last four digits and expiration date which are sensitive records, and enough to social engineer accounts with) are also not something every administrator would need access to. Could go on and on I’m sure.

An example of what we’d do in Xenforo would be have a super administrator account, set the privileges to each admin suited to their roles, even for the main ones that normally would have full access, if it’s not being updated we disabled access for any administrator to it, including myself. Then disabled the super admin access (it is something you had to update in the config.php on the server) so it could not be changed via the admin panel. That way, even in the event of a an admin’s account being breached, it wouldn’t have huge repercussions as they wouldn’t get full access to everything. They’d need to compromise the server as well to make themselves a super admin, and at that point they’d have access to the database anyway so it’s the worst case scenario there.

On Discourse though if any administrator is compromised (at least how I understand it, haven’t added an administrator since I last used it a year ago, current one still waiting on migration) then they’d be able to do a full backup of the forum, install a test version of Discourse, and compromise all the users. Disable SSL, change the CSS/templates to capture login information of members. Cancel subscription, disable the site.

Granted, keeping recent backups would mitigate data loss, but having administrator restrictions in place would help limit the scope of the damage greatly. These aren’t all hypothetical situations, it’s based breaches that have occurred on many forums in the past, both big and small.


LDAP sensible data hidden to admins?
(Tobias Eigen) #2

That’s super interesting - I self-host discourse so haven’t seen the hosted admin options which look different.

It does seem to me that out of the box roles might be required at some point if the admin is also going to be in charge of billing - this is definitely not the same person in my organization.

I suspect this is not going to be high priority for the discourse team, so likely plugin territory.

Do a search for ACL or roles based permissions and you’ll see there’s some ongoing conversations already about this.


(Dylan) #3

Slightly, it’s just some small additions related to options specific to the hosting.

However, there is certainly a need for role based permission sets, it’ll become more apparent later on as Discourse grows, but the sooner it’s implemented the better.

For now I at least would like to have that payment information further redacted from the admin panel, it’s pretty revealing and that’s something that should only be shown to the company and the specific person paying the bill, not every single administrator, especially when most forums have volunteer admins.

Without role based permission sets it’s a vulnerability and target for any forum. If someone compromises ANY administrator they compromise the ENTIRE site. Just by getting a single password or stealing an email address, both are relatively trivial tasks for most forums, and there are little to no layers of added security in Discourse that could prevent that.

Right now the closest secondary security layer is an IP whitelist for the admin panel, which causes more issues than solves problems as many people don’t have static IP’s and would like to be able to manage it from multiple locations in case of emergency. I’ve certainly had times where I’ve had to use the admin panel on my phone, which the IP will change regularly except when I use a specific VPN, which most forums won’t have a company VPN to handle that.

Multi-factor authentication would limit the risk to a great extent as it would prevent the vast majority of account compromises, but it’s still highly preferred to solve the real problem by limiting access to important aspects of the site to those that will directly, regularly interact with those settings. Many settings won’t even be changed for months if at all after the initial setup, so it’s something that should be able to be locked down.


#4

The case explained in this topic would be another good example.

Especially in company-related forums, we must make a difference between the admin who sets up the platform, with low-level access to company strategic data, and the staff who will administer the community on a regular basis, following the evolution of the forum and adapting its interface and configuration in consequence.


(Joshua Rosenfeld) #5

This discussion has come up numerous times before (only found 2 topics, but it has definitely been discussed more).


My opinion on this is mixed. On the one hand, I like that Discourse is trying to avoid an overly complicated permissions system, that only one person (whoever created it) actually understands. On the other, 2 roles doesn’t seem to be enough for the growing variety of Discourse sites out there. Category Specific moderators are coming, but that role has less power than the current moderator and doesn’t address the issues brought up here. What seems to be needed is a “site-owner” type role. Moderators keep the current permission set, Admins lose access to sensitive site settings, the ability to download the entire site, and maybe a few other things I can’t think of, and Site-owners have full permissions (current Admin set).


(Dylan) #6

Really this could be solved by only adding two new roles:

1. SysAdmin/Site Owner - Gets access to the settings/configurations, download backups, sensitive aspects that only the person(s) managing the server-side should see/modify. Normal admins wouldn’t have access to all of these settings, nor would these settings (other than backups) need to be regularly accessed, if it’s something that isn’t changing at least weekly or monthly, then it would be for this role.

2. Designer - Gets access only to the site customization tab, nothing else from the administrative aspect.

Those would cover just about every use case until people get to extremely specific and custom setups.


(Joshua Rosenfeld) #7

Curious here. Are you proposing that an Admin (in your system) would have no access to any site setting (just remove the tab from their dashboard), or removal of access to sensitive site settings?


(Tobias Eigen) #8

These look good to me at first glance - but ask 10 different admins and you’re going to get 10 different new roles that are needed. :wink:

Just yesterday I found myself wishing for the ability to give an intern access to update the data of birth for 80 community members. I had to do it myself which is not a great use of my time.

As much as I hate it, the drupal roles and permissions system (just looking at it makes my heart race) might be something to look at. It lets admins be very granular in giving access to various functions to different people.


(Dylan) #9

Really the entire settings tab is something that should rarely ever change once it’s all be setup. So I wouldn’t see an issue with that. Especially since you’d have the ability to give SysAdmin/Site Owner roles to multiple individuals if needed.

That role could be the only one with the settings, email, API, backup, update, or plugin tabs. So they’re the only one that can bulk export user data or make sensitive changes to the system.

True, but this is in a way simplify it and keeping more sensitive data only used by those that need it. While I’d actually enjoy a complex, detailed role system – that would be a long way off, this is something practical, simplified in comparison and has very common, wide reaching use cases.


(Joshua Rosenfeld) #10

If you remove the entire setup tab (and email, API, backup, update, and plugin), what exactly is left for the Admin role? From what I can tell, that leave Group management, view all PMs, impersonate users, and a few post related actions (like change ownership). Writing that out, that sounds like a good bit of stuff they can do while protecting the site by decreasing who has access to API, backups, and critical site settings.


(Tobias Eigen) #11

It sounds to me like your own use case could be addressed by setting up a sandbox site and give your designer access to that. Then when you’ve got everything set up as you want it to be you copy the customizations to your live site. Probably a good way to operate in any case.

And as regards billing information - that really shouldn’t have been included in the discourse admin in my view… the discourse team should have separated that out into a separate billing account center. I don’t want to be able to see my organization’s official credit card, and don’t particularly like the idea of it being backed up to S3 every day.

But then they probably have their own very good business reasons for doing it, probably to do with dogfooding and not wasting developer time building out another account center that they have to take care of apart from discourse. :slight_smile:

So maybe there is a case to be made for the discourse team to add at least one more permission level for billing, which then opens the door to adding more, perhaps via community-contributed plugins?

Could be:

  • super-admin = god privileges on the site
  • admin = everything but backups, settings, sensitive data
  • moderator = same as now
  • billing = new billing tab? only on hosted discourse sites
  • designer = access to customizations tab

(Dylan) #12

For the design aspect that’s what we intend to do (development board with non-sensitive data to use for testing).

I completely agree. Or at least blank out the current card/payment data completely. I know which card I’m using, I see the bill and receipts, no one else needs to be able to see that data other than the individual paying and the company processing it.

The billing would be strictly on their paid hosting plans, it’s only needed because they handle the display through the client’s admin panel and the payments from payments.discourse.org (that’s where it takes you when you want to update payment info).

Agreed, design wouldn’t even be necessary as the development board solves that (can cost just a buck or two via AWS/Rackspace/Google/GoDaddy/etc when doing hourly billing to test design changes on a development build).

The billing wouldn’t be necessary either if they managed payments/subscriptions through Discourse.org instead of the client’s board, or at least blanking out sensitive payment information completely. Currently it shows type of card, last 4 digits, expiration date, email. Too much information really.


(cpradio) #13

Can’t that be done with Moderator privileges? As a moderator I can alter the preferences of any user, does the date of birth show on the preference page?


(Dylan) #14

Either none of the Discourse staff accounts on my hosted board have that field as an option or it’s something you have to do via the admin panel. Not sure since I don’t have a production discourse currently running (will once the import finishes :slight_smile: )


(cpradio) #15

I think date of birth is a custom user field. And if it is checked “Show on Profile”, it should be in the preferences (I think). But date of birth is definitely not a core field packaged in Discourse.


#16

@codinghorror Is there a way we can limit some abilities to certain Admin?

For super admin, we can have a checklist to check or uncheck which power is granted to a specific admin. It can be a modal popup.

Example:
Admin 1 - Can do everything, except impersonate, see logs, API, or Backup.
Admin 2 - Can do all design changes only.

The list of power can be based here:
Dashboard, Settings, Users, Badges, Groups, Emails, Flags, Logs, Customize, API, Backups, Plugins, Impersonate

So if I set up one Admin and check only Customize. The only tab he/she will be seeing is the Customize tab on his admin panel.

I think this is a solution to all the Admin Restriction problems, temporarily. Because if they can’t see the tab, they won’t know that it’s possible for them to do it.


(Griff Wigley) #17

I’ve got a new self-hosted site and would like the super-admin option. I know this discussion is pretty old but I’m wondering if anything was ever implemented. I’ve poked around and it seems not, but thought I’d check.


(Joshua Rosenfeld) #18

Nope, never implemented. Admins have full ability to do anything on the site. The only restriction is impersonating other admin users.