More remote access inference torment

[mike1813]

At present, when a text only remote access client (i.e., a terminal) could connect to a process that can't be run from the command line, the connection is made anyway.

This is done because the illegal connection can then be detected by a modelling error threat, giving a clear indication of the problem. If the illegal connection were not made, it may lead to a break in data flow, or a remote interactive process having no connection from a user, In either case, a different modelling error would then be found, but this will be at some distance from the unmade connection, making it very difficult to understand, let alone address.

A similar situation arises when the client is graphical (i.e., a remote desktop client), and the connection is via a login service that supports only command line/textual interactions.

The problem with this arrangement is that the illegal connection might not be asserted. For example, it may be inferred from connections to a reverse proxy. In that situation, the connection may be inadvertent. This leads to a different set of confusions. It is also possible for a connection to be inferred that is not illegal, but is unintended and may be inappropriate - and for this to create problems in the data flow inference sequence, e.g., due to this limitation.

There are lots of interesting issues raised by this situation. Some of these may merit elevation to a separate issue, in some cases for the system-modeller. For example:

• We could make or not make an illegal remote access connection depending on what type it is. For example, perhaps connections from terminals to graphical processes should be dropped, but connections to remote access services allow to stand.
• We could try to refine modelling error threats so they detect the hanging ends of a broken remote access connection path. This would need to use information from the data flow construction, however, and may mean we end up allowing broken data flows instead.
• It would be nice if construction (and threat) patterns could be sensitive to whether a system model match to a node or link in a pattern is asserted or inferred. Then we could take a different approach in either case, which might help determine when an illegal connection is best made anyway or left out, or allow different modelling error threats so the one found always refers to a user assertion.

Meantime, we need to resolve the situation to get the best outcome we can with minimal changes. Making major changes would not be desirable because of the complex interdependencies between this and the models used for client-service communication, authentication, and data flow inference.

[mike1813]

Addressed at least for now in branch 85 by suppressing the addition of 'usesRemotely' links where:

• the connection from the remote access Client is via a reverse proxy, not a direct 'Client-uses-Process' relationship, and
• the Process connected to is incompatible with the client, i.e., where one of the following is true
  • the Process is a remote login service (domain#LoginService)and the Client is a remote desktop client (domain#RemoteDesktop),
  • the Process is not an Interactive Process (domain#InteractiveProcess)
  • the Client is a remote terminal and the Process is not a Command Line Process (domain#ConsoleProcess)

Note that the remote access connection is not suppressed where the 'uses' relationship.

For most 'sensible' system models, this works quite well. It handles a few situations where a remote access client connects via a reverse proxy that also serves other processes, which was previously not handled at all. It handles many more situations where a proxy serves remote access clients only than was previously the case.

This will do for now.

Longer term, the simplest solution may be to introduce separate reverse proxy subclasses for specific types of clients (e.g., remote access clients, web clients, etc.). We could then add modelling errors to detect cases where a client connects to the wrong type of reverse proxy, forcing users to include different proxies for remote access and other traffic. This is similar to the current K8S model, where tha API Server subclass handles remote login, while the Ingress Proxy subclass handles user access to hosted services.

[mike1813]

It may make sense to introduce further fixes for this issue on branch 107, as remote access to interactive processes does have some bearing on the model for user interactions with data (issue #107).

However, fixing these would add a lot of work, so changes to the model of proxies used for remote access can be deferred.

[mike1813]

We could also have a situation where a rich client like a web browser is used to access a service providing access to a remote login service via (say) a JavaScript terminal emulator. I have seen that used in some open source firewall applications.

Should this be modelled as:

• a WebBrowser client accessing a remote LoginService or DesktopService, or
• a WebBrowser client using a collocated (client-side) RemoteTerminal or RemoteDesktop process which is the client of the remote LoginService or DesktopService?

In the former case, we would be allowing a WebBrowser to act like a remote terminal or remote desktop client. In the latter case we would be allowing a user to interact with such a client via the WebBrowser process, and not directly (unless we use a pattern to add this as an inferred relationships).