Can PyWin32 give users "too-much" access to the Win32 API?

Question

I'm developing a tool for a utility group with very high-security standards (for obvious reasons). This tool runs inside ESRI's ArcMap Application (Using the ArcMap API - ArcPy). ArcFM is Software installed on top of ArcMap and is used for utility based analytics (ArcFM has a license separate from ArcMap). The tool I'm developing requires ArcPy (Python) to check-out the ArcFM license using PyWin32 (see snippet below)

#ArcFM licensing
import win32com.client
app = win32com.client.Dispatch("Miner.Framework.Dispatch.MMAppInitializeDispatch")
runtime = win32com.client.Dispatch("Miner.Framework.Dispatch.MMRuntimeEnvironmentDispatch")
app.Initialize(0x5)
#end ArcFm licensing

In order to use some of the ArcFM functionalities within the tool I'm developing, the ArcFM license must first be check-out inside the script.

This snippet checks out the license to ArcFM so I can access ArcFM functions outside of the GUI. The IT Director of the Utility Group has been hesitant to install PyWIN on their machines as he/she is concerned that it will give users too much access to there own computers.

From my understanding, Win32 won't give users "extra" access to their computers (it only allows them to access features through the API). For example, if a user doesn't have rights to access registry-keys, Win32 (or PyWin32) will not bypass any security settings assigned to that user profile.

Do I understand this correctly? Is there anything I missed?

Answer 1

[GitHub]: mhammond/pywin32 - Python for Windows (pywin32) Extensions (emphasis is mine) states:

This is the readme for the Python for Win32 (pywin32) extensions, which provides access to many of the Windows APIs from Python.

So, PyWin32 is a Python wrapper over WINAPIs (it just allows them to be called from Python in a friendly manner). Regardless of it (not) being installed on a Python installation, the WINAPIs are still there and can be accessed from:

• C

• Python as well (e.g. using [Python 3]: ctypes - A foreign function library for Python), but the code would be much:

  1. Longer (all kinds of conversions are required)
  2. Less readable (lots of "maintenance" code - not related to the business logic)
  3. Error prone

  
  You could check [SO]: Get the title of a window of another program using the process name (@CristiFati's answer) for difference between the 2 approaches (also check (the last part of) [SO]: python win32service - Getting triggered startup information for service (@CristiFati's answer)).

• Other languages

Since Pywin32 doesn't have an official doc page, I'll be referencing the next best thing (that I found): [ActiveState.Docs]: PyWin32 Documentation.

Examples:

• Since you mentioned registry:
  • [ActiveState.Docs]: win32api.RegOpenKeyEx wraps [MS.Docs]: RegOpenKeyExW function
  • But maybe it's not the best example, as registry functions are also available via [Python 3]: winreg - Windows registry access (which is part of Python's standard library)
• Another one (that has something to do with security):
  • [ActiveState.Docs]: win32security.LogonUserEx wraps [MS.Docs]: LogonUserExW function

Bottom line

There are NO additional privileges (rights) granted (by default) by PyWin32.

---

However I'm trying to find a reason for management's concern towards having PyWin32 installed.

Generally, experts (in the WINAPI area) would most likely know:

1. C (number of devs is decreasing)
2. Win internals (not very many here either)
3. General computer (low level) knowledge
4. From the 3 above, such users would know what the implications of calling an WINAPI (and if not, they would easily know where / what to search / investigate in order to get answers)

From these users' PoV, it makes no difference. But since PyWin32 modules can be queried for their content:

>>> import win32security
>>>
>>> print([name for name in dir(win32security) if callable(getattr(win32security, name))])
['ACL', 'AcceptSecurityContext', 'AcquireCredentialsHandle', 'AdjustTokenGroups', 'AdjustTokenPrivileges', 'AllocateLocallyUniqueId', 'CheckTokenMembership', 'ConvertSecurityDescriptorToStringSecurityDescriptor', 'ConvertSidToStringSid', 'ConvertStringSecurityDescriptorToSecurityDescriptor', 'ConvertStringSidToSid', 'CreateRestrictedToken', 'CreateWellKnownSid', 'CredHandleType', 'CryptEnumProviders', 'CtxtHandleType', 'DsBind', 'DsCrackNames', 'DsGetDcName', 'DsGetSpn', 'DsListDomainsInSite', 'DsListInfoForServer', 'DsListRoles', 'DsListServersForDomainInSite', 'DsListServersInSite', 'DsListSites', 'DsUnBind', 'DsWriteAccountSpn', 'DuplicateToken', 'DuplicateTokenEx', 'EnumerateSecurityPackages', 'GetBinarySid', 'GetFileSecurity', 'GetKernelObjectSecurity', 'GetNamedSecurityInfo', 'GetPolicyHandle', 'GetSecurityInfo', 'GetTokenInformation', 'GetUserObjectSecurity', 'ImpersonateAnonymousToken', 'ImpersonateLoggedOnUser', 'ImpersonateNamedPipeClient', 'ImpersonateSelf', 'InitializeSecurityContext', 'IsTokenRestricted', 'LogonUser', 'LogonUserEx', 'LookupAccountName', 'LookupAccountSid', 'LookupPrivilegeDisplayName', 'LookupPrivilegeName', 'LookupPrivilegeValue', 'LsaAddAccountRights', 'LsaCallAuthenticationPackage', 'LsaClose', 'LsaConnectUntrusted', 'LsaDeregisterLogonProcess', 'LsaEnumerateAccountRights', 'LsaEnumerateAccountsWithUserRight', 'LsaEnumerateLogonSessions', 'LsaGetLogonSessionData', 'LsaLookupAuthenticationPackage', 'LsaOpenPolicy', 'LsaQueryInformationPolicy', 'LsaRegisterLogonProcess', 'LsaRegisterPolicyChangeNotification', 'LsaRemoveAccountRights', 'LsaRetrievePrivateData', 'LsaSetInformationPolicy', 'LsaStorePrivateData', 'LsaUnregisterPolicyChangeNotification', 'MapGenericMask', 'OpenProcessToken', 'OpenThreadToken', 'PyCredHandleType', 'PyCtxtHandleType', 'PySecBufferDescType', 'PySecBufferType', 'QuerySecurityPackageInfo', 'RevertToSelf', 'SECURITY_ATTRIBUTES', 'SECURITY_DESCRIPTOR', 'SID', 'SecBufferDescType', 'SecBufferType', 'SetFileSecurity', 'SetKernelObjectSecurity', 'SetNamedSecurityInfo', 'SetSecurityInfo', 'SetThreadToken', 'SetTokenInformation', 'SetUserObjectSecurity', 'TranslateName', 'error']

that might get one of the other kind of users, ideas.

So the (arguable: false) concern, is that a great power (including the one of knowledge) is shared with users that might not have the great responsibility required to handle that power. In some cases, that could lead (dramatizing a bit) to disaster (and whether is because of mistake or malintent isn't very relevant).

To draw a parallel with a real life scenario: having a dummy lock on your door (or the wallet in the shoe at the beach):

• Will stop ~90%+ of the thieves (the mediocre ones)
• Will have no effect against the real masters