Feature Request: Allow clients/agents to enforce confirmation settings

[aksdb]

The new confirmation and notification feature allows an admin to define for a group of agents, if they should be notified about remote actions and if they are required to accept them first.

This leaves one possible problem though: if someone gets access to a MeshCentral (or an admin goes rogue), these settings can simply be turned off and the foreign machines can be controlled or monitored without the user(s) noticing.

Scenario: I support machines of friends, parents, etc. and want to give them confidence, that I don't mess with their privacy.

Solution

Allow agents to enforce these settings. The windows installer could offer graphical options, the other ones could be set via config file, and/or command line parameter that gets added when providing the links to the agents.

This should be a per-agent option. Agents that are fully administrated are under full control of the admin anyway and can be completely remote-configured like it is now. Agents that are only administrated when necessary might have a different take on "trust".

[Ylianst]

This is a good request, however, it's going to be difficult to make this work well because the server can update the MeshAgent.exe and MeshCore.js and so, if an admin "goes rogue" and knows what they are doing, they could patch the agents to get around security blockers on the agent.

This said, there are two types of administrators for MeshCentral. The one that setup and manages the server, and the one with administrative permissions on a device group. For example, on MeshCentral.com I added "UserConsentFlags": 64 to the domain section of the config.json.

{
  "settings": {
    "Port": 443
  },
  "domains": {
    "": {
      "UserConsentFlags": 64
    }
  }
}

This makes it so that everyone will see the privacy toolbar and device group administrators can't override it. The values are as follows:

    // User Consent Flags
    const USERCONSENT_DesktopNotifyUser = 1;
    const USERCONSENT_TerminalNotifyUser = 2;
    const USERCONSENT_FilesNotifyUser = 4;
    const USERCONSENT_DesktopPromptUser = 8;
    const USERCONSENT_TerminalPromptUser = 16;
    const USERCONSENT_FilesPromptUser = 32;
    const USERCONSENT_ShowConnectionToolbar = 64;

If you want to require many of these at once, just sum them and place as "UserConsentFlags".

Let me know if that helps, Ylian

[aksdb]

This is a good request, however, it's going to be difficult to make this work well because the server can update the MeshAgent.exe and MeshCore.js and so, if an admin "goes rogue" and knows what they are doing, they could patch the agents to get around security blockers on the agent.

Then I think I need to extend my request to require user consent for agent updates as well :-) That way it could not simply be replaced by a malicious one without some communication between the involved parties (me and whoever system I'm dealing with).

This said, there are two types of administrators for MeshCentral. The one that setup and manages the server, and the one with administrative permissions on a device group. For example, on MeshCentral.com I added "UserConsentFlags": 64 to the domain section of the config.json.

{
  "settings": {
    "Port": 443
  },
  "domains": {
    "": {
      "UserConsentFlags": 64
    }
  }
}

This makes it so that everyone will see the privacy toolbar and device group administrators can't override it. The values are as follows:

    // User Consent Flags
    const USERCONSENT_DesktopNotifyUser = 1;
    const USERCONSENT_TerminalNotifyUser = 2;
    const USERCONSENT_FilesNotifyUser = 4;
    const USERCONSENT_DesktopPromptUser = 8;
    const USERCONSENT_TerminalPromptUser = 16;
    const USERCONSENT_FilesPromptUser = 32;
    const USERCONSENT_ShowConnectionToolbar = 64;

If you want to require many of these at once, just sum them and place as "UserConsentFlags".

Cool, that at least helps guarding against a bad user. However the threat scenario I'm trying to guard against (with my other feature request as well) is someone breaking MeshCentral - either due to a bug in MeshCentral (which unfortunately no one is ever perfectly save from) or in some other system component that would allow the person to take over the server MeshCentral is running on.

Of course a more sophisticated attack will probably plant not easily detectable trap doors, but then it must already be a targeted attack (which is nearly impossible to guard against anyway). However some stray hacker using an exploit to get on the system who then stumbles across a gateway into tons of other systems that he can now silently infiltrate was well feels dangerous.

---

Regarding the "users don't trust admin"-angle: if I was the user in possible need of regular support, I would really like to be sure that the other end doesn't suddenly decide to spy on me. So if there is some client-side "ask me before the admin can do ANYTHING" (update the agent, watch my desktop, open my files, etc.) I would feel a lot safer.

(Of course in the worst case it's probably just a bad idea to have the agent running then ... but that's what my feature request is for: maybe we can find a way to ensure a user stays in control without having to resolve to uninstall/reinstall-when-necessary/uninstall-again :-))

[penguinthingie]

@aksdb I think your request has valid points for Home users, not Business or Enterprise based environments. From a business perspective, most admins goals are to keep the environments safe and manageable with least amount of interruptions or limited constraints when dealing with end user devices. It should be expected that when end users are utilizing a work device that is the property of the organization, the expectations of privacy should be quite minimal.

For example, many organizations do DPI to monitor for bad and good traffic which also gives the admins of those systems full access to the end users browsing habits and data in an un-encrypted format to be readable by scanning solutions weather for compliance/security to industry policy requirements. Nothing is stopping a rogue admin or anybody from outside gaining access to one of those systems to put the user in the same situation and nor are the users being notified of such measures each time they make use of their work devices.

Currently, the notifications functionality within MeshCentral works perfectly for multiple organizations i have deployed the solution to. @Ylianst and the team does an amazing job at implementing a lot of functions and feature requests each day and the best thing is a lot of them are setup with "optional" so the core functionality of what MeshCentral does is not jeopardized. It is possible that your request can be do-able but as an optional customization that may be possible in the future rather then a default behavior.

[MailYouLater]

Regarding the "users don't trust admin"-angle: if I was the user in possible need of regular support, I would really like to be sure that the other end doesn't suddenly decide to spy on me. So if there is some client-side "ask me before the admin can do ANYTHING" (update the agent, watch my desktop, open my files, etc.) I would feel a lot safer.

(Of course in the worst case it's probably just a bad idea to have the agent running then ... but that's what my feature request is for: maybe we can find a way to ensure a user stays in control without having to resolve to uninstall/reinstall-when-necessary/uninstall-again :-))

You could always use a temporary agent. If you give them an installer downloaded using the "Background & interactive" option, they have the choice to "Connect" or "Install", connect being temporary, closing the window removes all remote access, and "Install" being the option that installs a service and keeps it connected all the time. If you choose the "Interactive only" option, then only the temporary version "Connect" is available. This sounds like a good way for people who don't have full trust in the server admin to give access but only when they want to.

[aksdb]

@penguinthingie Absolutely. For enterprise use cases MeshCentral is already perfectly prepared. However I would not say that my described scenario is Home User only. I also have small IT support shops in mind. There are a lot of small businesses (with cash register, payment system, etc.) that hire other local IT shops to manage their PC. That does not always mean (I would say quite the contrary) that these businesses trust these IT shops blindly. Most business owners I know like to stay in control and want to know every detail what is to be done and why (and of course what this will cost etc.).

@MailYouLater Thanks for that detailed guide! This is a possible solution for Windows, but afaik not quite as easy for Linux or OSX. Another little problem with that approach is, that it is then harder to keep the inventory information (which with a "normal" agent is also updated in regards to current hardware, OS version, etc.).

Don't get me wrong. I'm not saying the feature my request is for is make-or-break. MeshCentral is awesome and solutions for the non-enterprise world can be found (or in the worst case exist in the form of alternatives). Yet I think it would still fit in there, if development time permits (even if it is not the primary intended use case of MeshCentral (for now :smiley:) )

[MailYouLater]

... I would not say that my described scenario is Home User only. I also have small IT support shops in mind. There are a lot of small businesses (with cash register, payment system, etc.) that hire other local IT shops to manage their PC. That does not always mean (I would say quite the contrary) that these businesses trust these IT shops blindly. Most business owners I know like to stay in control and want to know every detail what is to be done and why (and of course what this will cost etc.).

I totally agree with that. I feel this feature request is definitely valid, though I think the details of how it should work may still need some more thought.

... This is a possible solution for Windows, but afaik not quite as easy for Linux or OSX. Another little problem with that approach is, that it is then harder to keep the inventory information (which with a "normal" agent is also updated in regards to current hardware, OS version, etc.).

Both very good points.

[Ylianst]

I am also inline with @MailYouLater, I understand the request and it's a valid one. I have a quick idea on how to implement this. We would add in the meshagent.msh a line with user consent flags that would be mandated for that given agent and could not be changed on the server. The agent would display these flags at Install time to make it clear it's enforcing select user consent features.

As long as it's understood that because the meshagent.exe and meshcore.js are updated from the server, there is a limit to how "armored" this technique can be. Someone could get around this by changing server/agent code or getting consent once and using it to edit the .msh file on the client.

If there are other design ideas, please let me know.

[krayon007]

One I finish my changes to the install option on the windows agent, it will allow me to uniformly support install flags on agent installation on all platforms. This will have the side benefit that it will allow the system service manager on all platforms to pass settings to the agent, which could include the feature you are talking about.

[aksdb]

@Ylianst do you think it would be a valid extension to add a new consent feature (only for this specific usecase if you prefer) that requires consent before replacing/updating the meshagent.exe or meshcore.js? That way the agent would be completely locked down unless approved by the user. If this fits into the protocol/implementation it would also help with my other feature request #849 (which otherwise suffers from the same possible flaw (the admin simply being able to replace the agent without the agent being able to "deny" that request).

[sebthom]

@aksdb I think this FR is currently getting resolved via #2725.