Slashdot Mirror
Python May Let Security Tools See What Operations the Runtime Is Performing (bleepingcomputer.com)
An anonymous reader writes: A new feature proposal for the Python programming language wants to add "transparency" to the runtime and let security and auditing tools view when Python may be running potentially dangerous operations. In its current form, Python does not allow security tools to see what operations the runtime is performing. Unless one of those operations generates particular errors that may raise a sign of alarm, security and auditing tools are blind that an attacker may be using Python to carry out malicious operations on a system.
But in Python Enhancement Proposal 551 (PEP-551), Steve Dower, a core Python developer, has proposed the addition of two new APIs that will let security tools detect when Python is executing potentially dangerous operations. The first, the Audit Hook API, will raise warning messages about certain type of Python operations; while the second, the Verified Open Hook API, is a mechanism to let the Python runtime know what files it is permitted to execute or tamper with.
Initial plans were to have PEP-551 ship with Python 3.7, scheduled for release in mid-June 2018, but the proposal did not make the final cut, according to a list of new features added for next month's release. This doesn't mean PEP-551 won't ship with a future version of Python. This is the second major scripting engine to open its runtime to security tools, after PowerShell.
But in Python Enhancement Proposal 551 (PEP-551), Steve Dower, a core Python developer, has proposed the addition of two new APIs that will let security tools detect when Python is executing potentially dangerous operations. The first, the Audit Hook API, will raise warning messages about certain type of Python operations; while the second, the Verified Open Hook API, is a mechanism to let the Python runtime know what files it is permitted to execute or tamper with.
Initial plans were to have PEP-551 ship with Python 3.7, scheduled for release in mid-June 2018, but the proposal did not make the final cut, according to a list of new features added for next month's release. This doesn't mean PEP-551 won't ship with a future version of Python. This is the second major scripting engine to open its runtime to security tools, after PowerShell.
Were re-inventing resource specification sandboxes. The farther you push these things out to the edge rather than at the OS the less uniform policies you have. You become dependent of every app and every plugin the app trusts and every system function the app forks off to have a security policy that matches the one you want. Since you are not the app creator this can't ever happen.
On the other hand if you can define the security policy of what resources an app and all it's children can use then you can have a system wide or app-to-app tailored policy. And even then the app maker, who might know more than you do, could supply a pre-written "suggested" sandbox policy for their app. That is firefox could tell you what directories it will ever access and supply a sandbox for the OS to enforce it on itself. Likewise plugins that violate the norms can come with installers that update the sandbox for their extended needs beyond firefox. Since you can stack sandbox policies you can have a global one then the app specific one so even a hostile installer can't exceed some bounds.
But don't keep trying to write the one-true-secure application. (well do, but don't count on it.) and Don't put the policies in the interpreter.
OSX has a sand box. Linux has a sandbox (dtrace). And I imagine Windows might even have one.
The trouble is no one uses them regularly.
Some drink at the fountain of knowledge. Others just gargle.