Python May Let Security Tools See What Operations the Runtime Is Performing (bleepingcomputer.com) 75
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.
PEP-666 (Score:1)
I'm patiently waiting to submit PEP-666 next April 1st.
It's going to add curly braces!
Hmm, I might do a vim plugin for that (Score:2)
You got me thinking, I just might seriously do a vim plugin to add and remove curly braces from Python code. I've coded in a lot of languages over many years, most of which use curly braces, so my eyes/brain process them somewhat automatically. I also block-based operations in vim, which work based on curly braces. I might find it easier / faster to parse Python that had braces inserted temporarily.
This wouldn't be needed if my co-workers didn't write blocks that are FAR longer than any coding standard rec
Yep (Score:2)
Indeed. Just the other day I "adjusted" one of my co-workers pull requests just like that. That got rid of two single-line conditional blocks which put the rest of their 200-300 line function two levels deeper than it needed to be.
Those people are wrong. Unless (Score:2)
A single return is good if you write 4-20 line functions, which is common in many communities, and I favor that style.
If you're going to have a 200-line function, it's better to do your input validation and "exception handling" up front like this:
if (denominator == 0 ||
denominator == null ||
numerator == null) {
return error
}
Rather than have your entire 200-line body three levels deeper than it needs to be, putting some blocks 6 or 8 levels deep. If course actual exception handling is an
Re: (Score:2)
Good grief! I consider myself a total amateur, yet even I don’t do that.
Re: (Score:2)
Re: (Score:1)
Any time you have forced whitespace or whitespace between keywords the language is broken.
Python and Make are the two most common horribly broken languages.
Re: (Score:2)
Re: (Score:2)
My first post operations.
Your first post-op what?
Who will watch the watchers? (Score:1)
Tread carefully here: The morons who did WebRTC and the JavaScript Battery API didn't stop to think of the huge security loopholes they were opening up. People may well have died in oppressive regimes due to the arrogant shortsightedness of these twats.
I'd lilke to see proper Sandboxing but those who have tried to add it have concluded you need to do it from the ground up. Not after the fact like Java did.
Sandbox. operating system sandbox, please (Score:4, Interesting)
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.
So many things would have been preventable... (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You need a semi-brain. Begone lest I taunt you some more.
Re: (Score:2)
To be honest, I stil think the syntax of something like visual basic (classic), is one of the cleanest syntaxes around (I'm only refering to the syntax, not the language itself, that certainly needs some enhancements, haha).
Re:Python needs semicolons (Score:4, Informative)
Python does not ignore semicolons. Python allows multiple, semicolon separated, statements on the same line.
The Python Style Guide discourages that, but it's a guide, not a language rule.
Just curious... (Score:2)
Also, given that Python is all open-source, it would seem that the community which focuses on the runtime component (yes, I know it's the same guys proposing this - bear with me) would have pretty good checks on things, especially buffer overflows, etc.)
Having said that - and obviously not being a Python guru - I'm kinda surprised to learn that even with the amazing plethora of Python modules, there is not already a similar logging/tracing
Already doable! (Score:2)
The easy way to accomplish this is to use a system language and a debugger. ;)
On a serious note: do you really want a scripting language "executing potentially dangerous operations"? Seriously, think about it, they aren't signed text files and they are trivial to modify. Sure, there's no agreed upon ELF signing convention but at least it's significantly more difficult for a script to modify.
I know I'll be burned at the stake by those who are in love with Python but that doesn't invalidate my points.
Re:Already doable! (Score:4, Insightful)
On a serious note: do you really want a scripting language "executing potentially dangerous operations"?
You mean like:
/bin/sh
#!
rm -rf /
Re: Already doable! (Score:3)
Re: (Score:3)
If you need static typing, you probably shouldn't be using Python. You might want to look into Perl which is similar to Python in many ways and has stricter variable typing. However, many (most?) folks find Perl code to be very difficult to read. Might have something to do with stricter typing. Or maybe it's something else.
Re: (Score:2)
As a guy who did software QA for decades, I can tell you that a generally valid argument for strong typing is that it permits compile time checking for problems that otherwise won't be seen until unit test, or (worse) system test, or (much worse) production.
As a programmer, I'm on your side. If I wanted constant aggravation, I'd have picked a different profession.
What is this anyway? (Score:5, Informative)
I read through the comments and still didn't have a clue what the article is about. So I took the drastic step of actually reading the PEP.
AFAICS, What is proposed is that the Python runtime provide some hooks that allow system administrators to observe/log some events occurring in scripts. That's useful because Python provides access to just about anything one might want to do via dynamically loadable modules.
Will it actually be usable for anything? I haven't a clue. My gut feeling is probably not very. But what do I know?
Can it be used for evil? Probably. But I should think that the risk from malicious modules and code vastly outweighs any additional risk from these hooks.
Re: (Score:2)
Isnt the larger question really 'why'?
As in why would python try and do what is done, for very good reasons, at OS level already, and if it is not, things are completely broken anyway?
After all there is that tiny little loophole of C extensions, or hell, just writing the nasty programs in C (or just about any other language) to behind with?
I basically read this as 'Python has a HUGE problem because it works like pretty much every other language out there, quick, fix it!'
ie: someone stiring up a storm in a t
Re: (Score:2)
We're way beyond my tiny area of competence here, but PEP551 https://www.python.org/dev/pep... [python.org] includes an example:
The PEP asserts that sort of thing bypasses (most) malware scanners and file access controls because there is no file written to disk. Could be. The proble
Re: (Score:3)
PowerShell has similar functionality, and I can speak a little on why they did it.
"Normal" AV looks at files. You read a file and it's scanned. You write a file and it's scanned. File-less attacks nullify this approach by never dropping anything to the disk. They call PowerShell (or Python, apparently) by passing in a script block, the equivalent of a one-liner that is Eval()'d. To help close this hole and expose scriptblocks to AV PowerShell added features to decode incoming scriptblocks, log them, and exp
And the malware tools to use those APIs (Score:2)
... will be available the day before the standard's officially released.