Implement user permission model

[ITAYC0HEN]

Description

I believe that implementing user management would be a good decision. Maybe something that is based on mwdb user permission model. This will help to make mquery suitable for big organizations. For example, some queries are too sensitive to share even with other people in the same organization

Similarly to mwdb, this will allow the user to choose whether they want all the users to view the newly added job or to submit it as a personal rule, visible only for them (and maybe for the system admin). In this case, the recent jobs page will show by default only the user's jobs, and with a toggle turn-on, it will show all the publicly available jobs.

In addition, currently mquery parser the "author" attribute from the Yara. But the author signed on a Yara rule isn't necessarily the person who executes the rule in mquery. Say, if someone is executing a rule from the internet written by a stranger. Later, it will be hard for the user to find this job since they don't remember the name of the stranger.

[msm-code]

I've been thinking about this for the past few days now.

I really don't add user management to mquery. This will only complicate simple deployments, and big companies that care already have their own user management systems.

I've discussed this with other mquery users, and oauth/openid seems to be a common denominator. What do you think about optionally reducing default permissions, and adding an openid login feature to grant additional permissions to selected users.

In other words, there will be option to restrict permissions of anonymous users in configs. More permissions can be granted to selected users logged in via OpenId.

Keep in mind that this will be an optional feature, so users that don't want to bother with OpenId won't have to.

In the unlikely case that a company using mquery doesn't already have an identity management server, it's easy to set up one with keycloak (https://www.keycloak.org/getting-started/getting-started-docker): docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:15.0.2.

Pinging @ITAYC0HEN as issue creator and @psrok1 as my guru on OpenID.

[ITAYC0HEN]

If I understand what you said, it sounds good to me. Just to verify, one - if they want to - can create their MQuery instance system like the following?

1. Nobody can access before logging in
2. Some logged in users would have limited permissions (i.e not all features\screens will be available)
3. Some logged in users will have all permissions (aka Admins)

Also, can a person limit a query and its results only to themselves? This scenario was mentioned in the original post

[msm-code]

Yes.

My (unspecified as of now) plan involves having some permissions grouped into three sets for simplicity (names subject to change):

• nobody - no permissions, can't access the system
• limited_user - can create jobs and see their results
• admin - can do everything the system allows

And finally, a way to:

• specify permissions for the "anonymous" (not logged in) user
• specify permissions for users that have logged in via OpenID (with option grant more or less permissions depending on username, or user groups)

So yeah, about what you've said.

(What mquery does right now will be equivalent to a "new model" mquery that grants "admin" permissions to the "anonymous" user).

[msm-code]

Closing, as it was already implemented and merged in the last version.

The user permissions feature is not 100% closed, but is working as described previously. Further improvements probably deserve their own issues.