classification
Title: Windows installer: Python binaries are user-writable
Type: enhancement Stage: resolved
Components: Installation, Windows Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Pat K, eryksun, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-09-28 09:15 by Pat K, last changed 2017-09-28 18:30 by steve.dower. This issue is now closed.

Messages (7)
msg303200 - (view) Author: Pat K (Pat K) Date: 2017-09-28 09:15
This seems to affect different versions of Python Windows installer. The problem is when Python is installed for all users (requires elevation) its binaries and DLLs are shipped with writable permission for "Authenticated Users":

PS C:\Python36> icacls python.exe
python.exe BUILTIN\Administrators:(I)(F)
           NT AUTHORITY\SYSTEM:(I)(F)
           BUILTIN\Users:(I)(RX)
           NT AUTHORITY\Authenticated Users:(I)(M)

...

This could be easily exploited for profit by a malicious user to hijack the interpreter or libraries of other users, including Administrator, possibly leading to the privilege escalation.
msg303217 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-09-28 11:09
The "(I)" flag in an icacls entry means it's inherited from the parent directory. The installer doesn't override these inherited permissions. Currently, it's your responsibility to do this if you install to a custom directory such as C:\Python36. 

Starting with Python 3.5, a per-machine installation defaults to a subdirectory of Program Files. This system directory only grants standard users generic read and execute access for subdirectories and files. A per-user installation defaults to the user's Programs directory (i.e. %LocalAppData%\Programs). This directory grants full control to the user, administrators, and the system. Other users have no access.
msg303224 - (view) Author: Pat K (Pat K) Date: 2017-09-28 11:49
Thank you for the explanation. I understand this is intentional. However
user without such knowledge of inheritable permissions might want to
default the installation directory to the old one (C:\PythonXX) and
could easily run into this issue without knowing. IMHO extra security
check or explicit warning wouldn't hurt here. Just my 5c.

On 9/28/2017 1:09 PM, Eryk Sun wrote:
> 
> Eryk Sun <eryksun@gmail.com> added the comment:
> 
> The "(I)" flag in an icacls entry means it's inherited from the parent directory. The installer doesn't override these inherited permissions. Currently, it's your responsibility to do this if you install to a custom directory such as C:\Python36. 
> 
> Starting with Python 3.5, a per-machine installation defaults to a subdirectory of Program Files. This system directory only grants standard users generic read and execute access for subdirectories and files. A per-user installation defaults to the user's Programs directory (i.e. %LocalAppData%\Programs). This directory grants full control to the user, administrators, and the system. Other users have no access.
> 
> ----------
> components: +Windows
> nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
> type:  -> enhancement
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31616>
> _______________________________________
>
msg303232 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-28 13:27
In fact, this is a backward compatibility issue.  Users expect that if you install it in the old location, it behaves like it did in the old location (lower security), and this is probably depended on by a number of users of python.  We *could* change it in some new feature release I suppose, but I'm pretty sure we consciously decided to go with this approach for this reason.

I do wonder what the standard practice is in the Windows world for alternate install locations, because that might have been a factor too :)
msg303253 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2017-09-28 15:02
Standard Windows behaviour, in my experience, is inherited permissions.

IMO, the current behaviour is correct - we default to an OS-managed secure location for system wide installs, and a user-modifiable location for user installs. If the person doing the install chooses an alternate location, we do not attempt to set policy on that location, but simply inherit the defined permissions.
msg303265 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-28 18:20
I'll let Steve be the one to close this, but it sounds like this isn't even a doc bug (ie: it is standard window's practice).
msg303267 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-09-28 18:30
Correct, this is expected behavior.

If you want your system to be secure *and* to modify default settings, you have to take full responsibility for that. You can't rely on other tools to have secure non-default settings (they should have secure *default* settings, which we do).
History
Date User Action Args
2017-09-28 18:30:27steve.dowersetstatus: open -> closed
resolution: not a bug
messages: + msg303267

stage: resolved
2017-09-28 18:20:48r.david.murraysetmessages: + msg303265
2017-09-28 15:02:33paul.mooresetmessages: + msg303253
2017-09-28 13:27:51r.david.murraysetnosy: + r.david.murray
messages: + msg303232
2017-09-28 11:49:24Pat Ksetmessages: + msg303224
2017-09-28 11:09:47eryksunsetnosy: + paul.moore, tim.golden, eryksun, zach.ware, steve.dower
messages: + msg303217

components: + Windows
type: enhancement
2017-09-28 09:15:11Pat Kcreate