A session manager is an abstract object which is responsible for tracking the lifetimes of sessions and other stateful connection information such as handles. It is generally not necessary for client applications to implement or even interact with session managers directly. However, their behavior does manifest itself in user-visible ways.
Each session manager has a (probablistically) unique, randomly-generated session manager ID (smid
) which is 64 bits in length. This ID is important in session establishment and lifecycle.
Each association operates under a specific session manager. Even if an association does not have a session manager explicitly set, it will implictly create a private instance as necessary. Associations which have the same session manager and endpoint are considered to be part of the same session, and thus may share state such as handles. Associations delegate session and handle logic to the session manager:
During the handshake stage of connection setup, each peer queries the session manager responsible for the connection for its smid
and sends it its counterpart. Each peer then notifies its own session manager of its entry into a session, passing along the remote session manager ID (rsmid
) along with any security token it received. When the connection is closed, it notifies the session manager that it is leaving the session.
When a session manager is notified of entry into a session, it first consults an internal table of active sessions. If the session is found, the manager increments a count in the session record indicating the number of associations currently participating in that session. Otherwise, it creates a new session record with said count set to 1. Upon notification of the session being left, it decrements this count.
When the count of a session reaches zero, the session is torn down and freed. In particular, any active handles remaining in the session are cleaned up using the cleanup function registered with lwmsg_session_register_handle().
During the lifetime of a session, handles may be registered and unregistered by participating associations. Handles, unlike sessions, are not reference counted – when unregistered by an association, a handle immediately becomes invalid, and subsequent use by the peer will result in undefined behavior.
While a session remains active, any association in that session may use any handle regardless of which association created it.
When a session manager first creates a session record in its table, it stores a copy of the peer security token given to it by the association. When a session is entered, it checks that the old and new security tokens are compatible. If they are not, the session manager rejects entry into the session – this typically leads to the connection being aborted.
Because of this security check, the ill effects of smid
collisions are mitigated. There are two scenarios:
smid
s are associated with the same security token, e.g. they are from two processes running as the same user. When this occurs, the presumably unrelated processes will unintentionally enter into the same session, causing inexplicable handle collisions. Assuming users don't attempt collision attacks against themselves, the likelihood of this occuring is a remote 1 in 264.smid
s are associated with different security tokens, e.g. they are from two processes running as different users. In this case, one of the two will have the connection aborted. This could potentially lead to a denial-of-service attack if it were possible to discover the smid
that the victim will use. To mitigate this possibility, clients and servers do not share session managers between ingoing and outgoing connections or between outgoing connections to different endpoints. This prevents an attacker from using the ID received from a peer to impersonate it. In addition, the session manager uses the best entropy sources possible in order to make guessing smid
s prohibitively difficult. Likewise Message Library, part of the Likewise platform
Copyright © 2020 Likewise Software. All rights reserved.