ipn/{ipnauth,ipnlocal,ipnserver,localapi}: start baby step toward moving access checks from the localapi.Handler to the LocalBackend
Currently, we use PermitRead/PermitWrite/PermitCert permission flags to determine which operations are allowed for a LocalAPI client.
These checks are performed when localapi.Handler handles a request. Additionally, certain operations (e.g., changing the serve config)
requires the connected user to be a local admin. This approach is inherently racey and is subject to TOCTOU issues.
We consider it to be more critical on Windows environments, which are inherently multi-user, and therefore we prevent more than one
OS user from connecting and utilizing the LocalBackend at the same time. However, the same type of issues is also applicable to other
platforms when switching between profiles that have different OperatorUser values in ipn.Prefs.
We'd like to allow more than one Windows user to connect, but limit what they can see and do based on their access rights on the device
(e.g., an local admin or not) and to the currently active LoginProfile (e.g., owner/operator or not), while preventing TOCTOU issues on Windows
and other platforms. Therefore, we'd like to pass an actor from the LocalAPI to the LocalBackend to represent the user performing the operation.
The LocalBackend, or the profileManager down the line, will then check the actor's access rights to perform a given operation on the device
and against the current (and/or the target) profile.
This PR does not change the current permission model in any way, but it introduces the concept of an actor and includes some preparatory
work to pass it around. Temporarily, the ipnauth.Actor interface has methods like IsLocalSystem and IsLocalAdmin, which are only relevant
to the current permission model. It also lacks methods that will actually be used in the new model. We'll be adding these gradually in the next
PRs and removing the deprecated methods and the Permit* flags at the end of the transition.
Updates tailscale/corp#18342
Signed-off-by: Nick Khyl <nickk@tailscale.com>
2024-08-27 20:22:56 +00:00
|
|
|
// Copyright (c) Tailscale Inc & AUTHORS
|
|
|
|
// SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
|
|
|
|
package ipnauth
|
|
|
|
|
|
|
|
import (
|
ipn/{ipnauth,ipnlocal,ipnserver}: send the auth URL to the user who started interactive login
We add the ClientID() method to the ipnauth.Actor interface and updated ipnserver.actor to implement it.
This method returns a unique ID of the connected client if the actor represents one. It helps link a series
of interactions initiated by the client, such as when a notification needs to be sent back to a specific session,
rather than all active sessions, in response to a certain request.
We also add LocalBackend.WatchNotificationsAs and LocalBackend.StartLoginInteractiveAs methods,
which are like WatchNotifications and StartLoginInteractive but accept an additional parameter
specifying an ipnauth.Actor who initiates the operation. We store these actor identities in
watchSession.owner and LocalBackend.authActor, respectively,and implement LocalBackend.sendTo
and related helper methods to enable sending notifications to watchSessions associated with actors
(or, more broadly, identifiable recipients).
We then use the above to change who receives the BrowseToURL notifications:
- For user-initiated, interactive logins, the notification is delivered only to the user who initiated the
process. If the initiating actor represents a specific connected client, the URL notification is sent back
to the same LocalAPI client that called StartLoginInteractive. Otherwise, the notification is sent to all
clients connected as that user.
Currently, we only differentiate between users on Windows, as it is inherently a multi-user OS.
- In all other cases (e.g., node key expiration), we send the notification to all connected users.
Updates tailscale/corp#18342
Signed-off-by: Nick Khyl <nickk@tailscale.com>
2024-10-13 16:36:46 +00:00
|
|
|
"fmt"
|
|
|
|
|
ipn/{ipnauth,ipnlocal,ipnserver,localapi}: start baby step toward moving access checks from the localapi.Handler to the LocalBackend
Currently, we use PermitRead/PermitWrite/PermitCert permission flags to determine which operations are allowed for a LocalAPI client.
These checks are performed when localapi.Handler handles a request. Additionally, certain operations (e.g., changing the serve config)
requires the connected user to be a local admin. This approach is inherently racey and is subject to TOCTOU issues.
We consider it to be more critical on Windows environments, which are inherently multi-user, and therefore we prevent more than one
OS user from connecting and utilizing the LocalBackend at the same time. However, the same type of issues is also applicable to other
platforms when switching between profiles that have different OperatorUser values in ipn.Prefs.
We'd like to allow more than one Windows user to connect, but limit what they can see and do based on their access rights on the device
(e.g., an local admin or not) and to the currently active LoginProfile (e.g., owner/operator or not), while preventing TOCTOU issues on Windows
and other platforms. Therefore, we'd like to pass an actor from the LocalAPI to the LocalBackend to represent the user performing the operation.
The LocalBackend, or the profileManager down the line, will then check the actor's access rights to perform a given operation on the device
and against the current (and/or the target) profile.
This PR does not change the current permission model in any way, but it introduces the concept of an actor and includes some preparatory
work to pass it around. Temporarily, the ipnauth.Actor interface has methods like IsLocalSystem and IsLocalAdmin, which are only relevant
to the current permission model. It also lacks methods that will actually be used in the new model. We'll be adding these gradually in the next
PRs and removing the deprecated methods and the Permit* flags at the end of the transition.
Updates tailscale/corp#18342
Signed-off-by: Nick Khyl <nickk@tailscale.com>
2024-08-27 20:22:56 +00:00
|
|
|
"tailscale.com/ipn"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Actor is any actor using the [ipnlocal.LocalBackend].
|
|
|
|
//
|
|
|
|
// It typically represents a specific OS user, indicating that an operation
|
|
|
|
// is performed on behalf of this user, should be evaluated against their
|
|
|
|
// access rights, and performed in their security context when applicable.
|
|
|
|
type Actor interface {
|
|
|
|
// UserID returns an OS-specific UID of the user represented by the receiver,
|
|
|
|
// or "" if the actor does not represent a specific user on a multi-user system.
|
|
|
|
// As of 2024-08-27, it is only used on Windows.
|
|
|
|
UserID() ipn.WindowsUserID
|
|
|
|
// Username returns the user name associated with the receiver,
|
|
|
|
// or "" if the actor does not represent a specific user.
|
|
|
|
Username() (string, error)
|
ipn/{ipnauth,ipnlocal,ipnserver}: send the auth URL to the user who started interactive login
We add the ClientID() method to the ipnauth.Actor interface and updated ipnserver.actor to implement it.
This method returns a unique ID of the connected client if the actor represents one. It helps link a series
of interactions initiated by the client, such as when a notification needs to be sent back to a specific session,
rather than all active sessions, in response to a certain request.
We also add LocalBackend.WatchNotificationsAs and LocalBackend.StartLoginInteractiveAs methods,
which are like WatchNotifications and StartLoginInteractive but accept an additional parameter
specifying an ipnauth.Actor who initiates the operation. We store these actor identities in
watchSession.owner and LocalBackend.authActor, respectively,and implement LocalBackend.sendTo
and related helper methods to enable sending notifications to watchSessions associated with actors
(or, more broadly, identifiable recipients).
We then use the above to change who receives the BrowseToURL notifications:
- For user-initiated, interactive logins, the notification is delivered only to the user who initiated the
process. If the initiating actor represents a specific connected client, the URL notification is sent back
to the same LocalAPI client that called StartLoginInteractive. Otherwise, the notification is sent to all
clients connected as that user.
Currently, we only differentiate between users on Windows, as it is inherently a multi-user OS.
- In all other cases (e.g., node key expiration), we send the notification to all connected users.
Updates tailscale/corp#18342
Signed-off-by: Nick Khyl <nickk@tailscale.com>
2024-10-13 16:36:46 +00:00
|
|
|
// ClientID returns a non-zero ClientID and true if the actor represents
|
|
|
|
// a connected LocalAPI client. Otherwise, it returns a zero value and false.
|
|
|
|
ClientID() (_ ClientID, ok bool)
|
ipn/{ipnauth,ipnlocal,ipnserver,localapi}: start baby step toward moving access checks from the localapi.Handler to the LocalBackend
Currently, we use PermitRead/PermitWrite/PermitCert permission flags to determine which operations are allowed for a LocalAPI client.
These checks are performed when localapi.Handler handles a request. Additionally, certain operations (e.g., changing the serve config)
requires the connected user to be a local admin. This approach is inherently racey and is subject to TOCTOU issues.
We consider it to be more critical on Windows environments, which are inherently multi-user, and therefore we prevent more than one
OS user from connecting and utilizing the LocalBackend at the same time. However, the same type of issues is also applicable to other
platforms when switching between profiles that have different OperatorUser values in ipn.Prefs.
We'd like to allow more than one Windows user to connect, but limit what they can see and do based on their access rights on the device
(e.g., an local admin or not) and to the currently active LoginProfile (e.g., owner/operator or not), while preventing TOCTOU issues on Windows
and other platforms. Therefore, we'd like to pass an actor from the LocalAPI to the LocalBackend to represent the user performing the operation.
The LocalBackend, or the profileManager down the line, will then check the actor's access rights to perform a given operation on the device
and against the current (and/or the target) profile.
This PR does not change the current permission model in any way, but it introduces the concept of an actor and includes some preparatory
work to pass it around. Temporarily, the ipnauth.Actor interface has methods like IsLocalSystem and IsLocalAdmin, which are only relevant
to the current permission model. It also lacks methods that will actually be used in the new model. We'll be adding these gradually in the next
PRs and removing the deprecated methods and the Permit* flags at the end of the transition.
Updates tailscale/corp#18342
Signed-off-by: Nick Khyl <nickk@tailscale.com>
2024-08-27 20:22:56 +00:00
|
|
|
|
|
|
|
// IsLocalSystem reports whether the actor is the Windows' Local System account.
|
|
|
|
//
|
|
|
|
// Deprecated: this method exists for compatibility with the current (as of 2024-08-27)
|
|
|
|
// permission model and will be removed as we progress on tailscale/corp#18342.
|
|
|
|
IsLocalSystem() bool
|
|
|
|
|
|
|
|
// IsLocalAdmin reports whether the actor has administrative access to the
|
|
|
|
// local machine, for whatever that means with respect to the current OS.
|
|
|
|
//
|
|
|
|
// The operatorUID is only used on Unix-like platforms and specifies the ID
|
|
|
|
// of a local user (in the os/user.User.Uid string form) who is allowed to
|
|
|
|
// operate tailscaled without being root or using sudo.
|
|
|
|
//
|
|
|
|
// Deprecated: this method exists for compatibility with the current (as of 2024-08-27)
|
|
|
|
// permission model and will be removed as we progress on tailscale/corp#18342.
|
|
|
|
IsLocalAdmin(operatorUID string) bool
|
|
|
|
}
|
|
|
|
|
|
|
|
// ActorCloser is an optional interface that might be implemented by an [Actor]
|
|
|
|
// that must be closed when done to release the resources.
|
|
|
|
type ActorCloser interface {
|
|
|
|
// Close releases resources associated with the receiver.
|
|
|
|
Close() error
|
|
|
|
}
|
ipn/{ipnauth,ipnlocal,ipnserver}: send the auth URL to the user who started interactive login
We add the ClientID() method to the ipnauth.Actor interface and updated ipnserver.actor to implement it.
This method returns a unique ID of the connected client if the actor represents one. It helps link a series
of interactions initiated by the client, such as when a notification needs to be sent back to a specific session,
rather than all active sessions, in response to a certain request.
We also add LocalBackend.WatchNotificationsAs and LocalBackend.StartLoginInteractiveAs methods,
which are like WatchNotifications and StartLoginInteractive but accept an additional parameter
specifying an ipnauth.Actor who initiates the operation. We store these actor identities in
watchSession.owner and LocalBackend.authActor, respectively,and implement LocalBackend.sendTo
and related helper methods to enable sending notifications to watchSessions associated with actors
(or, more broadly, identifiable recipients).
We then use the above to change who receives the BrowseToURL notifications:
- For user-initiated, interactive logins, the notification is delivered only to the user who initiated the
process. If the initiating actor represents a specific connected client, the URL notification is sent back
to the same LocalAPI client that called StartLoginInteractive. Otherwise, the notification is sent to all
clients connected as that user.
Currently, we only differentiate between users on Windows, as it is inherently a multi-user OS.
- In all other cases (e.g., node key expiration), we send the notification to all connected users.
Updates tailscale/corp#18342
Signed-off-by: Nick Khyl <nickk@tailscale.com>
2024-10-13 16:36:46 +00:00
|
|
|
|
|
|
|
// ClientID is an opaque, comparable value used to identify a connected LocalAPI
|
|
|
|
// client, such as a connected Tailscale GUI or CLI. It does not necessarily
|
|
|
|
// correspond to the same [net.Conn] or any physical session.
|
|
|
|
//
|
|
|
|
// Its zero value is valid, but does not represent a specific connected client.
|
|
|
|
type ClientID struct {
|
|
|
|
v any
|
|
|
|
}
|
|
|
|
|
|
|
|
// NoClientID is the zero value of [ClientID].
|
|
|
|
var NoClientID ClientID
|
|
|
|
|
|
|
|
// ClientIDFrom returns a new [ClientID] derived from the specified value.
|
|
|
|
// ClientIDs derived from equal values are equal.
|
|
|
|
func ClientIDFrom[T comparable](v T) ClientID {
|
|
|
|
return ClientID{v}
|
|
|
|
}
|
|
|
|
|
|
|
|
// String implements [fmt.Stringer].
|
|
|
|
func (id ClientID) String() string {
|
|
|
|
if id.v == nil {
|
|
|
|
return "(none)"
|
|
|
|
}
|
|
|
|
return fmt.Sprint(id.v)
|
|
|
|
}
|