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.
I'm patiently waiting to submit PEP-666 next April 1st.
It's going to add curly braces!
Yes Boris! We pour vodka up prostitute assholes and drink as it sprays out!
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.
It helps to have some humor when you live in a former superpower that has a smaller economy than Italy's.
My first post operations.
Your first post-op what?
Ezekiel 23:20
...if only Python had some semblance of sane design, like, e.g., Newspeak does, or other languages with an actual security model.
Ezekiel 23:20
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 recommends, but I've had limited success changing their habits. Instead of functions that do one simple thing, they like to write an entire 800-line program as one "function", except it's still not actually a function because it uses global variables from another file. Within their faketion they like to do this:
if can work
200 lines
eight levels deep
else
return error
The only problem with writing such a plugin is that there are a lot of gotchas to finding the beginning and end of Python blocks. Other people have tried to write plugins to delimit Python blocks, but they all fail on real-world Python because a change in leading whitespace doesn't NECESSARILY mean a new block. Only sometimes.
post-op human, we started with an orangutan.
Begone whitespace!
Has anyone shown any POC code that tricks out the Python runtime?
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 capability available. Yes! Full steam ahead!
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.
The very proposal that a separate set of some kind of "security tool APIs" are needed indicates to me that something is seriously wrong, fundamentally. There should not be any need for any kind of a "security tool API" for a well-designed, secure, virtual machine.
I am not aware of any kind of a "security tool API" floating around in the Perl ecosphere, and Perl is also a virtual machine-based programming language. Why is that? Why does Python need a "security tool API"? What exactly is so flawed with Python that it can potentially be insecure, and requires a "security tool API" bandaid?
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.
Anons need not reply. Questions end with a question mark.
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.
Sex change.
So you want Python to be more like Rust? You want it to be so awkward to use that it's nearly impossible to write insecure code, solely because it's nearly impossible to get the code to compile in the first place?
Want to improve Python application security? How about add some better compile-time checking like proper typed variable declarations, static type checking, static analysis and assertions. You know features that real languages like C, Ada, and even Java have had for a few decades.
I think Python is a pretty garbage language and can't understand its popularity. Things like strong typing and more checking at compile time were learned to be good back in the 60's (e.g. Pascal is an improvement over Algol 68) and I guess we'll just learn those lessons again.
This isn't trying to be flame bait -- I genuinely think Python is a scripting language that is being used as an application programming language and that's a bad idea.
This is SPARTA!!
You, good sir, have challenged the internet to a fatal duel.
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 another conversation.
Nice idea
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.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
... will be available the day before the standard's officially released.