Users can edit/delete pulled events

[h122015]

I open this issue so it doesn't get forgotten. Today I reported that on my instance, when doing a pull from misp-priv, the pulled events could be deleted/edited by normal users on my instance. This issue got solved with https://github.com/MISP/MISP/commit/98c1aadfa4b902eaeb6d8848f22da248d8366743

After applying the patch I did a pull from another remote instance and I noticed that events on that instance created with distribution "Community" where shown in my instance with distribution "Organisation" and all my users can edit/delete those events.

[iglocska]

I don't seem to be able to reproduce this. Are you sure you are on 2.4.7?

What I've tried:

Set up two instances, both running 2.4.7

Org 1 on Instance 1 creates and published an event with a few attributes, with the event set to "this community only" Org 2 on Instance 2 initiates a pull. Event gets transfered and becomes: Orgc = Org1, Org = Org2 and your organisation only Org 2's non site admin users can all see the event, but cannot edit it (tested by trying to edit it via the event index, event view, attribute edit, and by manually navigating to /events/edit/event_id).

Can you describe the steps that you've taken to be able to edit it and which edit method you used?

[h122015]

This is weird.

My instance's on 2.4.7, remote's on 2.4.5. Last Friday I clicked on "Pull all" from the remote instance and the job started but hung out at 48% in the process of pulling proposals, but all except one event were pulled onto my instance and the pulled events could be seen, edited and deleted by normal users. I could see the pulled events through "Global Actions -> Organisations -> Known Remote Organisations -> View"

For the event that wasn't pulled, I logged in onto the remote instance and clicked on that event and saw that at the bottom of the page there was a stack trace relating to an invalid threat, so I assumed that this error somehow avoid the completion of my job and reported this to the other instance's admin.

Today I arrived, did a git pull and saw that there was a mail from the admin stating that he regenerated the indexes and that the error related to the invalid threat is now gone. So I checked the list of jobs and saw that the job I started last Friday was still hung, so I deleted it from the database. I also saw your reply to my reported issue and wanted to make sure that a normal user could edit and delete the events pulled from that instance, so I logged in as a regular user and I didn't see any of the pulled events from the other instance. Last Friday I could see them but today they are not visible anymore. So I logged in as Admin, started a new "Pull all", the job completed this time but I don't see the events from that organisation via "Global Actions -> Organisations -> Known Remote Organisations -> View". If I browse through the event index, I see them eventually when I'm logged in as Admin, but as regular user I don't see them. I remember also that last Friday I entered the SQL statements, that Richie B2B documented on the issue #814 so probably is this the reason that I don't see them anymore?

[iglocska]

That is weird, the SQL statements that Richie B2B described are indeed correct and should not affect what you can see.

I am not sure I follow, so I'll try to describe it the way I understand it, please correct me if I am wrong:

1. You (as site admin of your_org) pulled an event (event_1) that was community only on the remote (from remote-org-1)
2. The event became Orgc: remote-org-1, Org: your_org, distribution: Your org only
3. When logged in as a normal user of local_org_1, you could see the event last week and you could edit it (which should not happen)
4. now when you log in, you correctly cannot view this event and you also cannot edit it

Is this correct?

Also, I am not sure how that threat level issue occurred, do you have any more info on that? That sounds new and wonder how they got into that situation.

[h122015]

1.- Correct 2.- Correct 3.- Correct 4.- Correct, but now that you use the word "correctly", I suppose then this is an expected behaviour? Only admins can see those pulled events that on my instance are viewable by my organisation, and normal users who are members of my organisation are not allowed to view them?

Regarding the threat thing. I misspelled, it should read "thread" instead of "threat" and I think this somehow has to do with the issue #768

[iglocska]

OK, I misunderstood then, I thought you meant that a normal organisation of a different organisation on your instance cannot see it (which would be correct as only members - but any member of your organisation should have access to it).

So you now have events that are:

1. Your organisation only
2. Locally owned by your organisation (org_id = your org's ID)
3. That are not visible to normal users of your organisation (same org_id as the event org_id)?

[h122015]

1.- Correct 2.- Correct 3.- Correct

Now that I think of it, I think I experienced this same behaviour with v2.3, but back then I thought it was so designed...

[iglocska]

3 sounds like a bug, that should definitely not be the case! I'll try to reproduce it, if a user is in the same organisation as the "org_id" of the event, then he/she should be able to see it, just not edit it.

[h122015]

but this is only for events pulled from other instances. If I create locally an event with distribution "Organisation", those events are viewable/editable by users in my organisation.

[iglocska]

Just tested it and for me it works.

What I did:

2 MISP intances (1. misp_local, 2. misp_remote) misp_local: 1 org: misp_local_org1 misp_remote 2 orgs: misp_remote_org1, misp_local_org1 (for the sync user)

1. User of misp_remote_org1 creates an event (event1) with the this community only distribution
2. misp_local_org1 initiates a pull
3. Event1 gets pulled and becomes your organisation only with Orgc = misp_remote_org1, Org = misp_local_org1
4. Non admin user of misp_local_org1 can see the event.

If this is not the case, I have a hunch: Could you check your organisation list whether the remote organisation exists twice from the upgrade (once in the local organisations and once in the remote organisations list) ?

[h122015]

I think I found the problem. In the server's list (Sync Actions -> List Servers) the column "org" was set to the remote organisation's name. On that same list, I have misp-priv defined and in "org" I see the name of my organisation, not CIRCL and the events pulled from misp-priv are properly displayed for my users. I set the org field in the database to my org id, so I hope this will solve the problem.

I want to test if this is actually the issue so on my instance I deleted one of the events pulled from the remote organisation and tried to pull that same event again, but for some reason it doesn't show up in my instance even though the job reports as being completed.

[iglocska]

The server object has 2 organisation fields attached to it:

1. The host organisation of the remote instance stored in remote_org_id (so in your case this would be CIRCL)
2. The organisation's ID that has added the server link (so in this case your own organisation) in org_id

1. gives the server link context, it shows you who is on the other end, and who will be the local owner of your events if you push data
2. gives sets the pulled events' org_id, so any community only event that you pull will become your organisation only to this organisation.

So indeed, that should definitely be your own org_id. Otherwise events pulled from that instance would not be visible to your users if they became your organisation only. What helps in this case is to check the org_id of the event.

[h122015]

yep, the org_id of the event is not set to my org's id, so that's why my users can't see them.

[iglocska]

Perfect, glad we could narrow it down. So this is indication of the sync mechanism not being obvious enough - something that we need to work on via documentation / in-GUI hints!