Eryk Sun added the comment:
It's not a bug that you can't read those keys. The DACL (discretionary access
control list) of those two keys doesn't grant any access to standard users.
However, administrators do have full control, in case your account is a UAC
restricted admin with a split token. In that case you can elevate ("run as
administrator") Python or the parent cmd shell to gain access to those keys.
Specifically, the registry key for the LocalSystem (SYSTEM) account, the one
that you can access (I think it's not locked down as much for the sake of
legacy compatibility), grants standard user accounts GENERIC_READ access (i.e.
KEY_READ):
HKU\S-1-5-18
Medium Mandatory Level (Default) [No-Write-Up]
R BUILTIN\Users
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL
RW BUILTIN\Administrators
KEY_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
KEY_ALL_ACCESS
RW CREATOR OWNER
KEY_ALL_ACCESS
R APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL
On the other hand, the registry keys for the LocalService (LOCAL SERVICE) and
NetworkService (NETWORK SERVICE) accounts grant no access to standard user
accounts:
HKU\S-1-5-19
Medium Mandatory Level (Default) [No-Write-Up]
RW NT AUTHORITY\LOCAL SERVICE
KEY_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
KEY_ALL_ACCESS
RW BUILTIN\Administrators
KEY_ALL_ACCESS
R NT AUTHORITY\RESTRICTED
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL
R APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL
HKU\S-1-5-20
Medium Mandatory Level (Default) [No-Write-Up]
RW NT AUTHORITY\NETWORK SERVICE
KEY_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
KEY_ALL_ACCESS
RW BUILTIN\Administrators
KEY_ALL_ACCESS
R NT AUTHORITY\RESTRICTED
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL
R APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL
LocalSystem and administrators have GENERIC_ALL access (i.e. KEY_ALL_ACCESS).
The respective service accounts also have all access, unless the service
process (or thread impersonation) token has restricted SIDs (security
identifiers). In that case the RESTRICTED SID should also be in the token's
list of restricted SIDs, so the service should be limited to KEY_READ access.
That is, unless a subkey has an ACE (access control entry) in its DACL that
grants additional access to one of its service SIDs.
It won't help to call CreateRestrictedToken to create a token that has the "NT
AUTHORITY\RESTRICTED" SID in its list of restricted SIDs, because the system
uses a double access check. The first pass is a normal check, and the token's
normal list of user and group SIDs, which you can't extend, doesn't have the
well-known RESTRICTED SID. In other words, a restricted token can never get a
higher level of access to a secured object than its source token.
----------
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28011>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
