System level notifications of policy failures

[pintomi1989]

• When policy failures occur, Fleet can fire off a webhook
• Fleet can also be integrated with Google Calendar to automatically create meeting blocks for end users to remediate policy failures
• Fleet desktop does not display system level notifications of policy failures to users

Problem

• Fleet does not offer an option to send out system level notifications when a policy failure occurs

Potential solutions

• Provide an option for system level notifications to be sent when a policy fails on Linux, MacOS, and Windows systems

[noahtalerman]

Noah: This is an enforcement mechanism.

Fleet is heading towards creating calendar events when end users are free to fix the issue as an enforcement mechanism.

Jason and Dave: Maybe the customer can use Tines to trigger a notification in another tool? (Slack)

[fleet-release]

Pop-ups alert, like Raindrops on glass city roofs, Security enhanced.

[noahtalerman]

Hey @pintomi1989, heads up, we discussed this issue during feature fest.

We decided not to draft this in the current design sprint (4.49).

Removing it from the feature fest board.

[nonpunctual]

@noahtalerman Since we are deploying the Fleet Desktop application it does makes sense for it to be able to use OS notifications as an option for admins. This would match a capability in Jamf as well. I think it would be the best solution to make this work on all computer platforms.

My original suggestion was going to be the same - maybe the policy webhook could be sent to something like Slack for a message.

Another way of handling this might be to use whatever is currently in Fleet Desktop that shows a policy failure / self-remediation to simply execute something like a SwiftDialog message that the admin has deployed (macOS only...) I don't think it would actually be any easier to do.

When https://github.com/fleetdm/fleet/issues/17129 is implemented, admins could use that capability to deploy their own notifications on Hosts based on policy results.

[noahtalerman]

@nonpunctual and @pintomi1989 the notifications are to ask the end user to resolve a failing policy, right?

Do we know exactly what policies the customer would trigger notifications for? (ex. Enable Firewall) I'm curious what the policies are is and what the remediation instructions are.

It would be helpful to understand this so we can understand whether or not system notifications are the best solution.

[nonpunctual]

@noahtalerman I think this kind of thing is not driven as much by the type event causing the notification as it is by the culture of the org. For some orgs with savvy users, the Fleet Desktop menu bar item might be enough. In some orgs that would be ignored forever.

The reason Nudge was created was because system notifications weren't enough to force users to update. In some orgs, they are enough.

Enabling this feature would just be giving admins another tool. If admins feel that notifications in the corner are where their users are trained to look, or, thay know users will be responsive to them, that's the tool they will use.

[noahtalerman]

@nonpunctual I hear you!

It's helpful for us to know exactly what policies each customer would trigger notifications for so that we can squish all these specific findings together and then consider solutions.

For example, if it's about reminding the user to turn on Slack notifications and a lot of customers/users are asking for that we might a flow specifically to solve that problem.

[noahtalerman]

cc @pintomi1989 ^

[nonpunctual]

@pintomi1989 can we track down the policies they are using & post them? Getting the queries or what the queries are for. Thanks.

[pintomi1989]

The purpose of this ask for one customer is to remind users when they are in violation of various device trust policies. Things like missing certs, incorrect OS versions, bios updates, and more items in the future. The goal is to have something like Toast notifications in Windows, but for Linux @noahtalerman @nonpunctual

[nonpunctual]

@pintomi1989 https://linuxconfig.org/how-to-send-desktop-notifications-using-notify-send

It is very easy on Ubuntu to use the notify-send binary. If it isn't installed the article above has commands for installing it on several Linux flavors.

If the customer has Tines or Okta Workflows or a webhook server, they could have policies in Fleet, that, on a failure, send a webhook to automation that runs a script in Fleet which executes a notify-send command.

[kaanwar]

@pintomi1989 https://linuxconfig.org/how-to-send-desktop-notifications-using-notify-send

It is very easy on Ubuntu to use the notify-send binary. If it isn't installed the article above has commands for installing it on several Linux flavors.

If the customer has Tines or Okta Workflows or a webhook server, they could have policies in Fleet, that, on a failure, send a webhook to automation that runs a script in Fleet which executes a notify-send command.

notify-send works for users on GNOME, or other distros that have that particular notification library, but one of the challenges is trying to do notifications that are as agnostic as possible. For instance, users on KDE have knotification, users on XFCE have xfce4-notifyd, etc. Then, you have some users on non-standard setups that aren't using full-fledged desktop environments, and are using window managers such as i3wm, qtile and others, which have different notification mechanisms altogether.

Unlike Windows and Mac, where there is a single ecosystem (and therefore single notification mechanism), the underlying challenge with Linux is the sheer choice in OS/DE/WM has created a fragmentation of solutions, and each group of developers has attempted to solve that in their own way.

The hope here is that some mechanism can be created such that Fleet desktop itself is actually managing/handling the notification service, thereby creating something that is cross-platform and OS-agnostic (understanding of course that means development for Windows, MacOS and some flavors of Linux).