Windows installer: Python binaries are user-writable

[PatK]

BPO	31616
Nosy	@pfmoore, @tjguk, @bitdancer, @zware, @eryksun, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2017-09-28.18:30:27.005>
created_at = <Date 2017-09-28.09:15:11.566>
labels = ['3.7', 'invalid', 'type-feature', 'expert-installation', 'OS-windows']
title = 'Windows installer: Python binaries are user-writable'
updated_at = <Date 2017-09-28.18:30:27.004>
user = 'https://bugs.python.org/PatK'

bugs.python.org fields:

activity = <Date 2017-09-28.18:30:27.004>
actor = 'steve.dower'
assignee = 'none'
closed = True
closed_date = <Date 2017-09-28.18:30:27.005>
closer = 'steve.dower'
components = ['Installation', 'Windows']
creation = <Date 2017-09-28.09:15:11.566>
creator = 'Pat K'
dependencies = []
files = []
hgrepos = []
issue_num = 31616
keywords = []
message_count = 7.0
messages = ['303200', '303217', '303224', '303232', '303253', '303265', '303267']
nosy_count = 7.0
nosy_names = ['paul.moore', 'tim.golden', 'r.david.murray', 'zach.ware', 'eryksun', 'steve.dower', 'Pat K']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue31616'
versions = ['Python 3.7']

[PatK]

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.

[eryksun]

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.

[PatK]

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\>

---

[bitdancer]

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 :)

[pfmoore]

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.

[bitdancer]

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).

[zooba]

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).