Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-6729

NTFS permissions should be recalculated given SYSTEM is an implicit member of local Administrators

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: PUP 6.0.0
    • Component/s: None
    • Labels:
      None
    • Template:
    • Acceptance Criteria:
      Hide
      • Permissions should be laid down simpler - for instance, its typically unnecessary to set both Administrators and SYSTEM permissions when they are the same.
      • Beaker suite workarounds (like those found in pxp-agent and mcollective suites) should be able to be removed
      Show
      Permissions should be laid down simpler - for instance, its typically unnecessary to set both Administrators and SYSTEM permissions when they are the same. Beaker suite workarounds (like those found in pxp-agent and mcollective suites) should be able to be removed
    • Team:
      Windows
    • Story Points:
      1
    • Sprint:
      Windows 2018-06-13, Windows 2018-06-27, Windows 2018-07-05, Windows 2018-07-11
    • CS Priority:
      Normal
    • CS Frequency:
      3 - 25-50% of Customers
    • CS Severity:
      3 - Serious
    • CS Business Value:
      4 - $$$$$
    • CS Impact:
      Hide
      Customers might assume that running puppet agent -t it would have the same result as a normal puppet daemon run, but it doesn't because puppet runs as LOCALSYSTEM when it's a daemon, but as the user calling it when it's run as puppet agent -t.

      It would seem as though we want puppet to assign permissions to the LocalAdministrator group no matter which user it runs under(LOCALSYSTEM or a administrator) to avoid these oddities.
      Show
      Customers might assume that running puppet agent -t it would have the same result as a normal puppet daemon run, but it doesn't because puppet runs as LOCALSYSTEM when it's a daemon, but as the user calling it when it's run as puppet agent -t. It would seem as though we want puppet to assign permissions to the LocalAdministrator group no matter which user it runs under(LOCALSYSTEM or a administrator) to avoid these oddities.

      Description

      Puppet has traditionally been careful to separate out permissions when running as a SYSTEM vs a member of the Administrators group when it tries to emulate a POSIX root. This has led to a number of problems around permissions ordering within an ACL of ACEs, permissions being denied to the Puppet service for certain config files, etc.

      The current NTFS permission code doesn't take into account that SYSTEM is actually an implicit / hidden member of the Administrators group, making some of the permissions code unnecessarily complex. This ticket would involve refactoring.

      From my comment on PUP-5491:

      I found a reference in Mechanics of User Identification and Authentication that explains this. SYSTEM is an implicit / hidden member of the Administrators group, which can be verified by opening a psexec session as SYSTEM and running whoami /groups in it:

      C:\Users\Administrator\Downloads> psexec -s cmd.exe
       
      PsExec v2.11 - Execute processes remotely
      Copyright (C) 2001-2014 Mark Russinovich
      Sysinternals - www.sysinternals.com
       
       
      Microsoft Windows [Version 6.1.7601]
      Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
       
      C:\Windows\system32>whoami
      nt authority\system
       
      C:\Windows\system32>whoami /groups
       
      GROUP INFORMATION
      -----------------
       
      Group Name                             Type             SID          Attributes
       
      ====================================== ================ ============ ==================================================
      BUILTIN\Administrators                 Alias            S-1-5-32-544 Enabled by default, Enabled group, Group owner
      Everyone                               Well-known group S-1-1-0      Mandatory group, Enabled by default, Enabled group
      NT AUTHORITY\Authenticated Users       Well-known group S-1-5-11     Mandatory group, Enabled by default, Enabled group
      Mandatory Label\System Mandatory Level Label            S-1-16-16384
      

      So my unverified theory is that some of the problems we've seen around permission management might be due to the ordering of the ACEs inside the DACL, since an explicit grant to Administrators should also cover SYSTEM in theory as well.

      As a refresher, The Old New Thing talks about canonical ACE ordering and evaluation

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  ethan Ethan Brown
                • Votes:
                  2 Vote for this issue
                  Watchers:
                  14 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: