Partager via

about_Language_Modes

Brève description

Explique les modes de langage et leur effet sur les sessions PowerShell.

Description longue

Le mode de langue d’une session PowerShell détermine quels éléments du langage PowerShell peuvent être utilisés dans la session.

PowerShell prend en charge les modes de langage suivants :

  • FullLanguage
  • RestrictedLanguage
  • ConstrainedLanguage (introduit dans PowerShell 3.0)
  • NoLanguage

Qu’est-ce qu’un mode linguistique ?

Le mode de langue détermine les éléments de langue autorisés dans la session.

Le mode de langage est une propriété de la configuration de session (ou « point de terminaison ») utilisée pour créer la session. Toutes les sessions qui utilisent une configuration de session particulière ont le mode de langue de la configuration de session.

Toutes les sessions PowerShell ont un mode de langage. Les sessions sont créées à l’aide des configurations de session sur l’ordinateur cible. Le mode de langue défini dans la configuration de session détermine le mode de langue de la session. Pour spécifier la configuration de session d’une session PSSession, utilisez le paramètre ConfigurationName des applets de commande qui créent une session.

À compter de PowerShell 7.3, vous pouvez l’exécuter pwsh avec le paramètre ConfigurationFile . Cela vous permet de démarrer PowerShell à l’aide d’une configuration spécifique.

Recherche du mode de langue d’une session

Vous pouvez trouver le mode de langue d’une FullLanguage ou ConstrainedLanguage de session en obtenant la valeur de la propriété LanguageMode de l’état de session.

Par exemple :

$ExecutionContext.SessionState.LanguageMode

ConstrainedLanguage

Toutefois, dans les sessions avec RestrictedLanguage et NoLanguage les modes, vous ne pouvez pas utiliser l’opérateurd’accès membre (.) pour obtenir des valeurs de propriété. Au lieu de cela, le message d’erreur révèle le mode de langue.

Lorsque vous accédez à une $ExecutionContext.SessionState.LanguageMode session, PowerShell retourne les messages d’erreur RestrictedLanguage et VariableReferenceNotSupportedInDataSection.

  • PropertyReferenceNotSupportedInDataSection : les références de propriété ne sont pas autorisées en mode de langage restreint ou en section Données.
  • VariableReferenceNotSupportedInDataSection : variable qui ne peut pas être référencée en mode de langage restreint ou une section Données est référencée.

Lorsque vous accédez $ExecutionContext.SessionState.LanguageMode à une NoLanguage session, PowerShell retourne le message d’erreur ScriptsNotAllowed .

  • ScriptsNotAllowed : La syntaxe n’est pas prise en charge par cet espace d’exécution. Cela peut être dû au fait qu’il est en mode sans langue.

Recherche du mode de langue d’une configuration de session

Lorsqu’une configuration de session est créée à l’aide d’un fichier de configuration de session, la configuration de session a une propriété LanguageMode . Vous pouvez trouver le mode de langue en obtenant la valeur de la propriété LanguageMode .

(Get-PSSessionConfiguration -Name Test).LanguageMode

FullLanguage

Sur d’autres configurations de session, vous pouvez trouver le mode de langue indirectement en recherchant le mode de langue d’une session créée à l’aide de la configuration de session.

Définition du mode de langue

Le mode de langage d’une session PowerShell peut être défini via la variable intégrée $ExecutionContext .

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

Toutefois, cela n’est utile que pour expérimenter les modes de langage. Les modes de langage sont destinés à fournir une sécurité ajoutée aux sessions PowerShell pour des contextes spécifiques.

Les modes de langage sont définis lorsque vous utilisez une stratégie de contrôle d’application système ou créez une configuration de session.

Utilisation d’une stratégie de contrôle d’application système

PowerShell s’exécute automatiquement en ConstrainedLanguage mode lorsqu’il s’exécute sous une stratégie de contrôle d’application système. Les stratégies de contrôle d’application détectées sont AppLocker et Windows Defender Application Control (WDAC) sur les plateformes Windows.

PowerShell applique d’autres restrictions en plus des modes de langage lorsqu’il détecte une stratégie de contrôle d’application. Par exemple, il existe des restrictions supplémentaires pour l’approvisionnement en points et l’importation de modules dans le cadre d’une stratégie.

Lorsqu’une session PowerShell est démarrée sous une stratégie, elle s’exécute en ConstrainedLanguage mode. À compter de PowerShell 7.4, l’affichage de la bannière de démarrage inclut un message indiquant qu’il est en cours d’exécution dans ce mode. Cela permet aux utilisateurs d’avoir une expérience d’interpréteur de commandes interactive utilisable, d’exécuter des applets de commande et des commandes natives, ainsi que d’accéder aux éléments de langage de base. Mais l’utilisateur ne peut pas accéder aux API PowerShell, .NET ou COM susceptibles d’être utilisées par un acteur malveillant.

Tout module basé sur un script ou basé sur un script exécuté dans cette session s’exécute en ConstrainedLanguage mode. Toutefois, tout script ou module basé sur un script autorisé par la stratégie s’exécute en FullLanguage mode sans contraintes. De cette façon, un système verrouillé par stratégie peut avoir des scripts approuvés par la stratégie et s’exécuter avec quelques contraintes.

Utilisation d’une configuration de session

La communication à distance PowerShell prend éventuellement en charge la création de configurations de session personnalisées. Vous pouvez définir le mode de langue souhaité pour cette configuration personnalisée. Les configurations PowerShell Just Enough Administration (JEA) utilisent NoLanguage le mode pour limiter les sessions aux appels de commande uniquement. Avec JEA, la session à distance peut être limitée à des utilisateurs spécifiques. Les utilisateurs JEA sont limités à l’exécution d’un ensemble défini de commandes et ne peuvent pas accéder directement aux API, au système de fichiers ou à d’autres ressources système.

Pour plus d’informations, consultez configurations de session JEA et New-PSSessionConfigurationFile.

Fonctionnalités et limitations du mode langage

Cette section décrit les modes de langage dans les sessions PowerShell.

mode FullLanguage

Le FullLanguage mode autorise tous les éléments de langage dans la session. FullLanguage est le mode de langue par défaut pour les sessions par défaut sur toutes les versions de Windows.

mode RestrictedLanguage

En RestrictedLanguage mode, les utilisateurs peuvent exécuter des commandes (applets de commande, fonctions, commandes CIM et workflows), mais ne peuvent pas utiliser de blocs de script. Ce mode est également utilisé pour traiter les manifestes de modules chargés par Import-Module.

À compter de PowerShell 7.2, l’applet de commande est désactivée en New-Object mode lorsque le RestrictedLanguage verrouillage du système est configuré.

Par défaut, seules les variables suivantes sont autorisées en RestrictedLanguage mode :

  • $PSCulture
  • $PSUICulture
  • $true
  • $false
  • $null

Les manifestes de module sont chargés en RestrictedLanguage mode et peuvent utiliser ces variables supplémentaires :

  • $PSScriptRoot
  • $PSEdition
  • $EnabledExperimentalFeatures
  • Toute variable d’environnement, comme $env:TEMP

Seuls les opérateurs de comparaison suivants sont autorisés :

  • -eq (égal)
  • -gt (supérieur à)
  • -lt (inférieur à)

Les instructions d’affectation, les références de propriété et les appels de méthode ne sont pas autorisés.

mode ConstrainedLanguage

ConstrainedLanguage Le mode est conçu pour autoriser les éléments de langage de base tels que les boucles, les conditions, l’expansion de chaîne et l’accès aux propriétés d’objet. Les restrictions empêchent les opérations qui pourraient être abusées par un acteur malveillant.

Le ConstrainedLanguage mode autorise toutes les applets de commande et un sous-ensemble d’éléments de langage PowerShell, mais limite les types d’objets qui peuvent être utilisés.

Les fonctionnalités du ConstrainedLanguage mode sont les suivantes :

  • Toutes les applets de commande dans les modules Windows sont entièrement fonctionnelles et ont un accès complet aux ressources système, sauf indication contraire.
  • Tous les éléments du langage de script PowerShell sont autorisés.
  • Tous les modules inclus dans Windows peuvent être importés et toutes les commandes que les modules exportent s’exécutent dans la session.
  • L’applet Add-Type de commande peut charger des assemblys signés, mais elle ne peut pas charger de code C# arbitraire ou d’API Win32.
  • L’applet New-Object de commande ne peut être utilisée que sur les types autorisés (répertoriés ci-dessous).
  • Seuls les types autorisés peuvent être utilisés dans PowerShell. Les autres types ne sont pas autorisés. La conversion de type est autorisée, mais uniquement lorsque le résultat est un type autorisé.
  • Les paramètres d’applet de commande qui convertissent l’entrée de chaîne en types fonctionnent uniquement lorsque le type résultant est un type autorisé.
  • La ToString() méthode et les méthodes .NET des types autorisés peuvent être appelées.
  • Les utilisateurs peuvent obtenir toutes les propriétés des types autorisés. Les utilisateurs peuvent définir les valeurs des propriétés uniquement sur les types autorisés.

Les types .NET suivants sont autorisés en ConstrainedLanguage mode. Les utilisateurs peuvent obtenir des propriétés, appeler des méthodes et convertir des objets en ces types.

Types autorisés :

  • [adsi] (Windows uniquement)
  • [adsisearcher] (Windows uniquement)
  • [Alias]
  • [AllowEmptyCollection]
  • [AllowEmptyString]
  • [AllowNull]
  • [ArgumentCompleter]
  • [ArgumentCompletions]
  • [array]
  • [bigint]
  • [bool]
  • [byte]
  • [char]
  • [cimclass]
  • [cimconverter]
  • [ciminstance]
  • [CimSession]
  • [cimtype]
  • [CmdletBinding]
  • [cultureinfo]
  • [datetime]
  • [decimal]
  • [double]
  • [DscLocalConfigurationManager]
  • [DscProperty]
  • [DscResource]
  • [ExperimentAction]
  • [Experimental]
  • [ExperimentalFeature]
  • [float]
  • [guid]
  • [hashtable]
  • [int]
  • [int16]
  • [int32]
  • [int64]
  • [ipaddress]
  • [IPEndpoint]
  • [long]
  • [mailaddress]
  • [Microsoft.PowerShell.Commands.ModuleSpecification]
  • [NoRunspaceAffinity]
  • [NullString]
  • [Object[]]
  • [ObjectSecurity]
  • [ordered]
  • [OutputType]
  • [Parameter]
  • [PhysicalAddress]
  • [pscredential]
  • [pscustomobject]
  • [PSDefaultValue]
  • [pslistmodifier]
  • [psobject]
  • [psprimitivedictionary]
  • [PSTypeNameAttribute]
  • [regex]
  • [sbyte]
  • [securestring]
  • [semver]
  • [short]
  • [single]
  • [string]
  • [SupportsWildcards]
  • [switch]
  • [timespan]
  • [uint]
  • [uint16]
  • [uint32]
  • [uint64]
  • [ulong]
  • [uri]
  • [ushort]
  • [ValidateCount]
  • [ValidateDrive]
  • [ValidateLength]
  • [ValidateNotNull]
  • [ValidateNotNullOrEmpty]
  • [ValidateNotNullOrWhiteSpace]
  • [ValidatePattern]
  • [ValidateRange]
  • [ValidateScript]
  • [ValidateSet]
  • [ValidateTrustedData]
  • [ValidateUserDrive]
  • [version]
  • [void]
  • [WildcardPattern]
  • [wmi] (Windows uniquement)
  • [wmiclass] (Windows uniquement)
  • [wmisearcher] (Windows uniquement)
  • [X500DistinguishedName]
  • [X509Certificate]
  • [xml]

Seuls les types d’objets COM suivants sont autorisés :

  • Scripting.Dictionary
  • Scripting.FileSystemObject
  • VBScript.RegExp

Cas spéciaux :

  • [ref] - Conversion d’un objet en type [ref] ou [Management.Automation.PSReference] n’est pas autorisé. D’autres utilisations sont autorisées.

mode NoLanguage

Le mode PowerShell désactive complètement le langage de script PowerShell NoLanguage . Vous ne pouvez pas exécuter des scripts ou utiliser des variables. Vous pouvez uniquement exécuter des commandes natives et des cmdlets.

À compter de PowerShell 7.2, l’applet de commande est désactivée en New-Object mode lorsque le NoLanguage verrouillage du système est configuré.

Voir aussi

  • Last updated on