Since I apparently made a mistake by calling this a bug (sorry!) I’ll make another attempt and try real hard not to get my topic insta-closed by categorizing this as a “feature”, I guess? (There’s no “security” category.)
So it turns out that the above concerns were already raised, discussed, and agreed as something to be done in this also-locked the discussion Impersonation and reading private messages:
Unfortunately … the topic above drifted, and was locked after changes resulting in moderators no longer having access to private messages. Sadly it seems nothing was ever addressed regarding the auditing issue for admins (the original concern in the topic above).
I’m hopeful that other people (especially the gatekeepers) still strongly agree on this necessity, as much as they did last year before the topic was locked. But I don’t understand how this issue can stay on the TODO radar if it keeps getting pushed down the stack by closing off conversation about it, and thus my attempt to (re-)raise it.
As an admin you can download a copy of the site and query the DB. Only way to have honest-to-god Private messages is to share a gpg public key … period.
Admins also have access to SSH and can docker enter the container and run queries. Etc. Etc.
Mechanics of doing something like public/private encryption is very complex.
From reading, it seems the 2013-2014 consensus was pretty much along the lines of:
As alluded to in that topic, most people figure that Google can get to their Gmail account if someone tried hard enough. But they don’t expect a Google engineer to just be able to easily browse through their inbox without being detected or their boss knowing about it.
All access control systems can be circumvented. That doesn’t mean that none should be implemented.
We are fine with adding more audit trails, but removing the impersonate feature and removing the right of admins to … administrate, is not on the cards.
I don’t think that was ever suggested, or if it was back then, it was quickly dropped. The only liability right now is that PM’s can be viewed through the web UI without any auditable actions. If an admin wanted to view user johndoe’s PM’s, the idea is that he impersonates the user under “investigation”, then goes in and read them as necessary. That impersonation would be logged in the Staff Actions.
But what does that gain? Those logs are only viewable to an admin… so an admin can see that an admin impersonated someone?.. What does that help solve?
There’s a lot of literature out there on why audit trails are a key part of any information system’s security. Discourse already has an audit trail that logs all kind of important data access and changes to the system. What the community rather strongly agreed was that accessing a user’s “private”/“personal” information (PM’s) was important enough access that it should be logged. Why?
Identification of inappropriate admin behavior
Assistance in documenting incident response for an investigation
Most importantly, assurance to users that admins will be “on the record” if they have to access their personal information
A variety of other things that you can’t think of until you need documentation of it, just like all the other things in the staff actions log
Audit trails are generally seen as a middle-of-the-road balance between security and access. See Anderson’s Rule: “If you design a large system for ease of access it becomes insecure, while if you make it watertight it becomes impossible to use.”
So many words, so late at night… no wonder the old topic drifted.
Auditing any user who can SSH into the server and query the database is futile.
There are admin users without SSH access, therefore auditing their actions makes some sense.
As per Sam, devs are fine with adding more auditing, so there’s no point to continue moaning.
Admins were recently forced to click a button to reveal users’ email addresses which gets logged. Can’t we do the same with users’ PMs? Log all admin-accesses to users’ PMs and only reveal PMs on the user profile after clicking a button to avoid unnecessary audit spam… done, there’s your papertrail.
Any admin can download the database backup and browse the tables, one of which contains the PMs. It really is a waste of time to discuss this. Either you trust the admins or you do not. And in the latter case, you should not be using their site…
I think a better proposal is to change the wording
Right. As I said, it’s late; I was already one step ahead where only admins who are also developers can download backups. Basically, if you’re in the developer emails list, all bets are off. If not, Discourse might at least log what you do…
(Not that I’d care, I’m the only admin on my Discourse and I do trust myself. Usually. )
I think @downey has a point - introducing friction in the UI would not be a bad thing. Even if it’s just UI - even if the topic actually renders in the background.
Example: Have the client check if their admin-ness is what’s letting them see the topic, and throw up a warning click-through every 10 minutes. Log the click, don’t nag for another 10 minutes.
Are you saying you’ve changed your mind since the below comments and that you’re no longer in favor of auditing admin activities throughout the application?
Many web applications require an admin to re-authenticate every N minutes iff they’re doing privileged activities. This is a common, standard security pattern … and a useful one at that! It reminds the admin that what they’re doing is a privileged activity, it requires some additional “think before you X” reflection, and even prevents trouble from abandoned workstations in case a nefarious colleague wants to come by and snoop.
I feel like a broken record, but some people keep bringing up other means of accessing the data (terminal, database backups, etc.) For some reason @codinghorror even changed my title to reflect that idea . Those methods can (and should) have their own audit trails, but that’s another discussion. This topic isn’t about those other means, it’s about the auditing admin actions in the web UI, so let’s please stay on topic.
Although I don’t have anything against it, I just don’t see the value in some situations. Changing a setting or altering a user’s profile, sure. That is something that could be identified by any user on the forum (potentially).
Viewing a PM is not something that another user could figure out. No one would have a reason to ask if Admin X read their PM without any consent. There isn’t anything that would be obvious or indicate it was read.
Also, exactly how far does this have to go? Let’s say I impersonate user Y, and while impersonating that user, I open their Messages. Does that need to be logged under the admin account? As to my knowledge when you impersonate, you become that user and it doesn’t necessarily know you are an admin any more… (my understanding of this may be flawed).
A starting point is simply keeping records of when data was accessed to which a user as a reasonable expectation of privacy (where “privacy” means some information that isn’t already public).
If I have a home security system, I want to know that someone, even the landlord, opened the door to my flat, and that my expectation of privacy was breached (with or without cause). I don’t necessarily need a log of every single step they took while inside. Discourse Admins should want nothing less for its users.
If I share some secret via PM, which then happens to enter the knowledge of a 3rd party, and a subsequent investigation reveals that a Discourse admin just happened to be impersonating me (or reading my PMs) just before that “leak” occurred, well, that’s enough to focus suspicion on a breach of trust by that admin.
One doesn’t avoid putting locks on doors just because someone could possibly break the door down with a battering ram. Why would we not want to audit the viewing of private information by third parties?
Duplicate of previous discussions. Admins can download the database and view all content, this is how the admin role works. Downloading the database is logged in the server logs, so please look there.
Other clarifications
Moderators can’t see PMs (now called just “Messages”) at all, that was the outcome of previous discussions
Admins have full access to everything in the system. That is the design, that is the intent, and if you are uncomfortable with that, you should have as few admins as possible and switch in and out of the role only as needed, just like Unix “root”
Admins can always download the database, this is logged in the server logs. We can’t tell you what they do with the database.
Admins can impersonate other users, this is logged in the staff action logs.
There is record of read flags and read times by all users on all topics, so if you really wanted to know which admin read what, that’s available in the database. Go download it and have a look.
If you don’t trust the admins on a site you are using, you should not use that site
This topic is now archived. It is frozen and cannot be changed in any way.
Basically, if you’re in the developer emails list, all bets are off. If not, Discourse might at least log what you do…
)
. Those methods can (and should) have their own audit trails, but that’s another discussion. This topic isn’t about those other means, it’s about the auditing admin actions in the web UI, so let’s please stay on topic. 