Enable admin to send test OSSEC alert via the admin interface

[redshiftzero]

Status

Ready for review

Description of Changes

Implements #2770, enabling the sending of a test alert upon request to admins:

Testing

New tests should pass (and you can verify journalist-error.log is monitored in app OSSEC config)

If you have prod VMs, you can make build-debs, vagrant provision /prod/, and verify the alert is produced as expected following the documentation added in the PR

Deployment

No special considerations

Checklist

If you made changes to the app code:

• Unit and functional tests pass on the development VM

If you made changes to documentation:

• Doc linting passed locally

[ghost]

I'm concerned this may not be in the right place. Should an admin journalist know about OSSEC at all ?

[redshiftzero]

Hmm, true - let me move this to the System configuration page added in #2769, that's a better home for this feature

[ghost]

let me move this to the System configuration

Sorry to be a kill joy but ... what I wonder is if we should start exposing things the journalist (even one who is an admin trusted to handle users) should never have to worry about. The OSSEC alerts are for the admin to see and the journalist should never know about it. I'm insisting because I have a feeling that if we open this door it will be very difficult to close when and if we change our mind later.

That being said if you weighted the pros/cons already, I fully support your decision :-)

[redshiftzero]

Yep, I totally agree that we should not show this to a journalist user, and only to admins. In my view the purpose of the Admin Interface should be to provide a user-friendly place for an admin to do any app server tasks that would otherwise be done via securedrop-admin or SSHing into the server (both are obviously not particularly user friendly). So the question here is: do we have SecureDrop journalists that have "admin" accounts on the webapp i.e. they don't want to or need to know what OSSEC alerts (or other system config) information is? I'm not aware of users of this type, but if we do find that there is a need for this third role on the application - a middle-ground user that can add/remove users but not to do any other administrative tasks, then I think the right thing to do would be to create this additional user type.

Happy to discuss further, it's an important point :)

[kushaldas]

That also means we will have to maintain access details between 3 types of users, that will surely increase the chances of mistakes. Maybe in code, maybe in actual operations. I would love to have an option without making users and their access states more complex.

[ghost]

do we have SecureDrop journalists that have "admin" accounts on the webapp ... I'm not aware of users of this type

That was the information I did not have, thanks for clarifying. I was assuming journalists wiht admin permissions. In reality, as you observed in the field, the same person who uses the the journalist interface with the admin permission is also the the sysadmin that maintains the servers.

I'll approve the pull request and let you merge if my understanding is correct. If I misinterpreted your explanation, please correct me :-)