title: CLR Strict Security on SQL Server 2017
body: <p>MSDN on <a href="https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/clr-strict-security" rel="noreferrer">this article</a> says:</p>
  
  <blockquote>
    <p>CLR uses Code Access Security (CAS) in the .NET Framework, which is no
    longer supported as a security boundary. A CLR assembly created with
    PERMISSION_SET = SAFE may be able to access external system resources,
    call unmanaged code, and acquire sysadmin privileges. Beginning with
    SQL Server 2017, an sp_configure option called clr strict security is
    introduced to enhance the security of CLR assemblies. clr strict
    security is enabled by default, and treats SAFE and EXTERNAL_ACCESS
    assemblies as if they were marked UNSAFE. The clr strict security
    option can be disabled for backward compatibility, but this is not
    recommended. Microsoft recommends that all assemblies be signed by a
    certificate or asymmetric key with a corresponding login that has been
    granted UNSAFE ASSEMBLY permission in the master database.</p>
  </blockquote>
  
  <p>How can a CLR assembly created with <code>PERMISSION_SET = SAFE</code> may be able to access external system resources, call unmanaged code, and acquire sysadmin privileges?</p>
  
  <p>Why CAS is no longer supported as a security boundary?</p>
  
  <p>As I understand CLR assemblies can no longer be safe, which is very unfortunate.</p>