[Python-Dev] [Security-sig] PEP 551: Security transparency in the Python runtime

[Wes Turner]

On Monday, August 28, 2017, Steve Dower <steve.dower at python.org> wrote:

> On 28Aug2017 1834, Gregory P. Smith wrote:
>
>> My gut feeling says that there are N interpreters available on just
>> about every bloated system image out there. Multiple pythons are often
>> among them, other we do not control will also continue to exist. I
>> expect a small initial payload can be created that when executed will
>> binary patch the interpreter's memory to disable all auditing,
>> /potentially/ in a manner that cannot be audited itself (a challenge
>> guaranteed to be accepted).
>>
>
> Repeating the three main goals listed by the PEP:
> * preventing malicious use is valuable
> * detecting malicious use is important
> * detecting attempts to bypass detection is critical
>
> This case falls under the last one. Yes, it is possible to patch the
> interpreter (at least in systems that don't block that - Windows certainly
> can prevent this at the kernel level), but in order to do so you should
> trigger at least one very unusual event (e.g. any of the ctypes ones).
>
> Compared to the current state, where someone can patch your interpreter
> without you ever being able to tell, it counts as a victory.
>
> And yeah, if you have alternative interpreters out there that are not
> auditing, you're in just as much trouble. There are certainly sysadmins who
> do a good job of controlling this though - these changes enable *those*
> sysadmins to do a better job, it doesn't help the ones who don't invest in
> it.
>
> If the goal is to audit attacks and the above becomes the standard
>> attack payload boilerplate before existing "use python to pull down
>> 'fun' stuff to execute". It seems to negate the usefulness.
>>
>
> You can audit all code before it executes and prevent it. Whether you use
> a local malware scanner or some sort of signature scan of log files doesn't
> matter, the change *enables* you to detect this behaviour. Right now it is
> impossible.


Wouldn't it be great to have the resources to source audit all code? (And
expect everyone to GPG sign all their commits someday.)

Many Linux packaging formats do have checksums of all files in a package:
{RPM, DEB,}

Python Wheel packages do have a manifest with SHA256 file checksums.
bdist_wheel.write_record():

https://bitbucket.org/pypa/wheel/src/5d49f8cf18679d1bc6f3e1e414a5df3a1e492644/wheel/bdist_wheel.py?at=default&fileviewer=file-view-default#bdist_wheel.py-436

Is there a tool for checking these manifest and file checksums and
signatures?

Which keys can sign for which packages? IIUC, any key loaded into the local
keyring is currently valid for any package?

"ENH: GPG signatures, branch-environment map (GitFS/HgFS workflow)"
https://github.com/saltstack/salt/issues/12183

- links to GPG signing support in hg, git, os packaging systems

...

Setting and checking SELinux file context labels:

Someone else can explain how DEB handles semanage and chcon?

https://fedoraproject.org/wiki/PackagingDrafts/SELinux

RPM supports .te (type enforcement), .fc (file context), and .if SELinux
files with an `semodule` command.

RPM requires various combinations of the policycoreutils,
selinux-policy-targeted, selinux-policy-devel, and  policycoreutils-python
packages.

Should setup.py (running with set fcontext (eg root)) just call chcon
itself; or is it much better to repack (signed) Python packages as e.g.
RPMs?

FWIW, Salt and Ansible do support setting and checking SELinux file
contexts:

salt.modules.selinux:

https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.selinux.html

https://github.com/saltstack/salt/blob/develop/salt/modules/selinux.py

Requires:
- cmds: semanage, setsebool, semodule
- pkgs: policycoreutils, policycoreutils-python,


Ansible sefcontext:

http://docs.ansible.com/ansible/latest/sefcontext_module.html

https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/system/sefcontext.py

Requires:
- pkgs: libselinux-python, policycoreutils-python

Does it make sense to require e.g. policycoreutils-python[-python] in
'spython'? ((1) Instead of wrapping `ls -Z` and `chcon` (2) in setup.py (3)
as root)?



> This audit layer seems like a defense against existing exploit kits
>> rather than future ones.
>>
>
> As a *defense*, yes, though if you use a safelist of your own code rather
> than a blocklist of malicious code, you can defend against all unexpected
> code. (For example, you could have a signed catalog of code on the machine
> that is used to verify all sources that are executed. Again - these
> features are for sysadmins who invest in this, it isn't free security for
> lazy ones.)
>
> Is that still useful from a defense in depth
>> point of view?
>>
>
> Detection is very useful for defense in depth. The new direction of
> malware scanners is heading towards behavioural detection (away from
> signature-based detection) because it's more future proof to detect
> unexpected actions than unexpected code.
>
> (If you think any of these explanations deserve to be in the PEP text
> itself, please let me know so I can add it in. Or if you don't like them,
> let me know that too and I'll try again!)
>
> Cheers,
> Steve
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
> turner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170829/dcfa6afc/attachment-0001.html>