Может ли PyWin32 предоставить пользователям «слишком много» доступа к Win32 API? - PullRequest
Новая
       61

Может ли PyWin32 предоставить пользователям «слишком много» доступа к Win32 API?

0 голосов
/ 04 марта 2019

Я разрабатываю инструмент для группы утилит с очень высокими стандартами безопасности (по понятным причинам).Этот инструмент работает в приложении ESRI ArcMap (с использованием ArcMap API - ArcPy).ArcFM - это Программное обеспечение, установленное поверх ArcMap и используемое для аналитики на основе утилит (у ArcFM есть лицензия, отдельная от ArcMap).Инструмент, который я разрабатываю, требует ArcPy (Python) для извлечения лицензии ArcFM с использованием PyWin32 (см. Фрагмент ниже) 

#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

Для того, чтобы использовать некоторые функции ArcFM в разрабатываемом мной инструментесначала необходимо получить лицензию ArcFM внутри скрипта.

Этот фрагмент проверяет лицензию ArcFM, чтобы я мог получить доступ к функциям ArcFM за пределами графического интерфейса.ИТ-директор Utility Group не решается установить PyWIN на свои машины, поскольку он / она обеспокоен тем, что он предоставит пользователям слишком большой доступ к собственным компьютерам.

Насколько я понимаю, Win32 не дастпользователи «дополнительно» получают доступ к своим компьютерам (это позволяет им получать доступ к функциям только через API).Например, если у пользователя нет прав доступа к ключам реестра, Win32 (или PyWin32) не будет обходить никакие параметры безопасности, назначенные этому профилю пользователя.

Правильно ли я понимаю?Я что-то пропустил?

1 Ответ

0 голосов
/ 21 марта 2019

[GitHub]: mhammond / pywin32 - Расширения Python для Windows (pywin32) ( выделение принадлежит мне):

Это файл readmeдля расширений Python для Win32 (pywin32) , который обеспечивает доступ ко многим API-интерфейсам Windows из Python .

Так, PyWin32 - это Python обертка над WINAPI s (он просто позволяет вызывать их из Python дружественным образом).Независимо от того, установлен ли он (не) на Python , WINAPI s все еще там и доступны из:

Поскольку Pywin32 не имеет официальной страницы документации, я буду референтомВозьмем следующую лучшую вещь (которую я нашел): [ActiveState.Docs]: Документация PyWin32 .

Примеры:


Итог

НЕТ никаких дополнительных привилегий (прав), предоставляемых (по умолчанию) PyWin32 .

Однако я пытаюсь найти причину обеспокоенности руководства по поводу установки PyWin32 .

Как правило, эксперты (в области WINAPI ), скорее всего, знают:

  1. C (количество разработчиков уменьшается)
  2. Win внутреннее устройство (здесь тоже не очень много)
  3. Общие знания компьютера (низкий уровень)
  4. Из 3 приведенных выше, такие пользователи будут знать, каковы последствиявызова WINAPI (а если нет, то они легко узнают, где / что искать / исследовать, чтобы получить ответы)

От этих пользователей PoV , это не имеет значения.Но поскольку у PyWin32 модулей можно запрашивать их содержимое: 

>>> 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']

, которые могут получить других пользователей, идеи.

Таким образом (можно утверждать: ложь ) проблема заключается в том, что великая сила (включая силу знаний) передается пользователям, которые могут не иметь большую ответственность Требуется справиться с этой властью.В некоторых случаях это может привести (немного драматизировать) к катастрофе (и то, что из-за ошибки или недобросовестности, не очень важно).

Провести параллель с реальным сценарием: наличие фиктивной блокировкина вашей двери (или кошельке в туфле на пляже):

  • Остановит ~ 90% + воров (посредственных)
  • Не будет никакого эффекта против настоящих мастеров
...