Re: [Python-Dev] Issue 8492 [was Re: [Python-dev] History stepping in interactive session?]

[Anand Jeyahar]

Hi Steven,
 Yep am interested. been looking to get back into C development for
sometime now. Though, don't hold your breath, as the last time i wrote any
C code was 10 years ago and i have no experience with the  cpython code
base.

Will look into it over the weekend.  So far i read up the issue and
understood the requirement.
  Next steps for me to do:
  1. to figure out the readline library bindings
  2. Find the source code in cpython. My first suspicion is that it
should be  in the Python/ folder.


Any suggestions welcome
==
Anand Jeyahar
http://www.blog.anandjeyahar.in/
https://github.com/anandjeyahar
==
The man who is really serious,
with the urge to find out what truth is,
has no style at all. He lives only in what is.
  ~Bruce Lee




On 8 October 2012 04:17, Steven D'Aprano  wrote:

> Over on python-ideas, a question about readline was raised and, I think,
> resolved. But while investigating the question, it became obvious to me
> that the ability to inspect the current readline bindings from Python
> was both useful and important.
>
> I wrote:
>
>  I don't believe that there is any direct mechanism for querying the
>> current
>> readline bindings in Python,
>>
>
> But it was requested some time ago: 
> http://bugs.python.org/**issue8492
>
>
> Is there anyone willing and able to give this issue some attention please?
>
> (Replies to python-dev only please.)
>
>
>
> --
> Steven
> __**_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> anand.jeyahar%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Improved evaluator added to ast module

[Vinay Sajip]

In response to http://bugs.python.org/issue15452, I've created an improved
evaluator in the ast module in my sandbox repo. The evaluator supports lookup of
names in a supplied namespace. The basic interface is

def lookup_eval(source_string_or_ast_node, namespace, allow_imports=False):
   # perform limited evaluation of Python expressions

Function calls are not allowed in expressions, but the following are:

* Names (looked up in namespace, and imported if not found there and
  allow_imports is True)
* Literals, just as literal_eval() does
* Array indexing and slicing
* Attribute access
* Arithmetic operators
* Bitwise operators
* Comparison operators
* in / not in
* and / or
* Unary operators

The patch is attached to the issue, and includes changes to replace the use
of eval() by logging.config.fileConfig() to use ast.lookup_eval().

I would welcome review of the patch, particularly as there may be security
implications (the issue is titled "Improve the security model for logging
listener").

Barring objections, I plan to commit it in a week or so.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Benjamin Peterson]

2012/10/11 Vinay Sajip :
> In response to http://bugs.python.org/issue15452, I've created an improved
> evaluator in the ast module in my sandbox repo. The evaluator supports lookup 
> of
> names in a supplied namespace. The basic interface is
>
> def lookup_eval(source_string_or_ast_node, namespace, allow_imports=False):
># perform limited evaluation of Python expressions
>
> Function calls are not allowed in expressions, but the following are:
>
> * Names (looked up in namespace, and imported if not found there and
>   allow_imports is True)
> * Literals, just as literal_eval() does
> * Array indexing and slicing
> * Attribute access
> * Arithmetic operators
> * Bitwise operators
> * Comparison operators
> * in / not in
> * and / or
> * Unary operators

With this operations, you can still cause a lot of trouble.

>
> The patch is attached to the issue, and includes changes to replace the use
> of eval() by logging.config.fileConfig() to use ast.lookup_eval().
>
> I would welcome review of the patch, particularly as there may be security
> implications (the issue is titled "Improve the security model for logging
> listener").

What exactly are you trying to prevent?


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Daniel Holth]

On Thu, Oct 11, 2012 at 12:34 PM, Benjamin Peterson  wrote:
> 2012/10/11 Vinay Sajip :
>> In response to http://bugs.python.org/issue15452, I've created an improved
>> evaluator in the ast module in my sandbox repo. The evaluator supports 
>> lookup of
>> names in a supplied namespace. The basic interface is
>>
>> def lookup_eval(source_string_or_ast_node, namespace, allow_imports=False):
>># perform limited evaluation of Python expressions
>>
>> Function calls are not allowed in expressions, but the following are:
>>
>> * Names (looked up in namespace, and imported if not found there and
>>   allow_imports is True)
>> * Literals, just as literal_eval() does
>> * Array indexing and slicing
>> * Attribute access
>> * Arithmetic operators
>> * Bitwise operators
>> * Comparison operators
>> * in / not in
>> * and / or
>> * Unary operators
>
> With this operations, you can still cause a lot of trouble.
>
>>
>> The patch is attached to the issue, and includes changes to replace the use
>> of eval() by logging.config.fileConfig() to use ast.lookup_eval().
>>
>> I would welcome review of the patch, particularly as there may be security
>> implications (the issue is titled "Improve the security model for logging
>> listener").
>
> What exactly are you trying to prevent?

How does this compare to the markerlib approach? In markerlib you just
make sure all the AST nodes are in a set of allowed nodes, currently
(Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
use the normal eval(). Is one way more secure / fast / flexible than
the other?

(https://bitbucket.org/dholth/markerlib/src/tip/markerlib/markers.py)

Thanks,

Daniel H
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Vinay Sajip]

Benjamin Peterson  python.org> writes:

> 
> With this operations, you can still cause a lot of trouble.
> 

Perhaps; I am hoping that some more specific information (about the kind of
trouble this can cause) will emerge. Hence the request for review.

> What exactly are you trying to prevent?

The issue was raised because people felt that the use of unrestricted eval()
in logging.config.fileConfig() - usage intended to convert class names and
constructor arguments to Python objects suitable for actually creating objects
like logging handlers - was a potential security hole, because configurations
can be sent and received over the network (not from remote clients, but there's
still a potential vulnerability for machines with multiple users like non-VPS
hosting boxes). No specific hole was described, so I don't have a specific list
of things I'm trying to prevent, other than function calls.

I added support for the items I thought would be useful in an evaluator slightly
more capable than literal_eval, but it's quite possible that I've allowed more
things than needed (e.g. array indexing and slicing). Clearly, replacing eval()
with literal_eval() will mean potential breakage of code in config files out
there - but that's a trade-off that may need to be made if security
considerations prevail.

Alternatively, it may be considered that the changes I've already committed
to logging's listen() function - to allow a verifier callback to be specified
- is sufficient to allay the concerns that led to the issue being raised in the
first place. In which case, I can close the issue without committing this patch.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Vinay Sajip]

Daniel Holth  gmail.com> writes:

> How does this compare to the markerlib approach? In markerlib you just
> make sure all the AST nodes are in a set of allowed nodes, currently
> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
> use the normal eval(). Is one way more secure / fast / flexible than
> the other?

I don't think performance is an issue, and the markerlib approach seems just
as reasonable as the one I've taken, except that it calls eval(), whereas my
approach doesn't. It boils down to what should be allowed in expressions, and
what shouldn't be.

ISTM there is a space for a limited evaluator that's less limiting than
literal_eval(). I do realise that this type of sandboxing is not easy to 
achieve,
and I'm not aiming to advance the state of the art here - I just want to close
the issue in the best way I can.

Regards,

Vinay Sajip


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Daniel Holth]

> ISTM there is a space for a limited evaluator that's less limiting than
> literal_eval(). I do realise that this type of sandboxing is not easy to 
> achieve,
> and I'm not aiming to advance the state of the art here - I just want to close
> the issue in the best way I can.

It is certainly a useful facility.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Serhiy Storchaka]

On 11.10.12 19:34, Benjamin Peterson wrote:

With this operations, you can still cause a lot of trouble.


Agree. Simple example: 9**9**9.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Serhiy Storchaka]

On 11.10.12 19:06, Vinay Sajip wrote:

Function calls are not allowed in expressions, but the following are:


Are properties allowed?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Georg Brandl]

Am 11.10.2012 20:13, schrieb Serhiy Storchaka:
> On 11.10.12 19:06, Vinay Sajip wrote:
>> Function calls are not allowed in expressions, but the following are:
> 
> Are properties allowed?

Yes, since attribute access also means properties.

This doesn't have to be a problem, since the objects on which you can
access properties are not controlled by the user.

I'm not sure if you can get at "dangerous" objects, such as sys.modules,
via attribute and item access chains if the accessible objects are
of built-in types, but the case is very difficult to decide in practice
for objects of user-supplied classes.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

[Benjamin Peterson]

2012/10/11 Vinay Sajip :
> Benjamin Peterson  python.org> writes:
>
>>
>> With this operations, you can still cause a lot of trouble.
>>
>
> Perhaps; I am hoping that some more specific information (about the kind of
> trouble this can cause) will emerge. Hence the request for review.

For example, if you have attribute access you can easily get to
important modules like "sys" and "os". Banning function calls is
essentially a red-herring, since almost any operation in Python can
cause arbitrary code execution.

>
>> What exactly are you trying to prevent?
>
> The issue was raised because people felt that the use of unrestricted eval()
> in logging.config.fileConfig() - usage intended to convert class names and
> constructor arguments to Python objects suitable for actually creating objects
> like logging handlers - was a potential security hole, because configurations
> can be sent and received over the network (not from remote clients, but 
> there's
> still a potential vulnerability for machines with multiple users like non-VPS
> hosting boxes). No specific hole was described, so I don't have a specific 
> list
> of things I'm trying to prevent, other than function calls.

Surely, if a hacker can get the app to use logging configs he sends,
he can have it send sensitive log data to himself.

>
> I added support for the items I thought would be useful in an evaluator 
> slightly
> more capable than literal_eval, but it's quite possible that I've allowed more
> things than needed (e.g. array indexing and slicing). Clearly, replacing 
> eval()
> with literal_eval() will mean potential breakage of code in config files out
> there - but that's a trade-off that may need to be made if security
> considerations prevail.
>
> Alternatively, it may be considered that the changes I've already committed
> to logging's listen() function - to allow a verifier callback to be specified
> - is sufficient to allay the concerns that led to the issue being raised in 
> the
> first place. In which case, I can close the issue without committing this 
> patch.

I like that. I don't exactly unterstand the usecase for logging
untrusted logging configurations.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Merge 3.2

[Chris Jerdonek]

On Thu, Oct 11, 2012 at 2:13 PM, brian.curtin
 wrote:
> http://hg.python.org/cpython/rev/2802b26c64a9
> changeset:   79670:2802b26c64a9
> parent:  79667:c3c188a0325a
> parent:  79668:8245333db1e5
> user:Brian Curtin 
> date:Thu Oct 11 16:12:47 2012 -0500
> summary:
>   Merge 3.2

FYI, it looks like a merge from 3.3 to default is missing from this
set of changes.

--Chris

>
> files:
>   Lib/platform.py |  7 ++-
>   Misc/NEWS   |  2 ++
>   2 files changed, 8 insertions(+), 1 deletions(-)
>
>
> diff --git a/Lib/platform.py b/Lib/platform.py
> --- a/Lib/platform.py
> +++ b/Lib/platform.py
> @@ -595,8 +595,13 @@
>  release = '7'
>  else:
>  release = '2008ServerR2'
> +elif min == 2:
> +if product_type == VER_NT_WORKSTATION:
> +release = '8'
> +else:
> +release = '2012Server'
>  else:
> -release = 'post2008Server'
> +release = 'post2012Server'
>
>  else:
>  if not release:
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -45,6 +45,8 @@
>  Library
>  ---
>
> +- Issue #16176: Properly identify Windows 8 via platform.platform()
> +
>  - Issue #16088: BaseHTTPRequestHandler's send_error method includes a
>Content-Length header in it's response now. Patch by Antoine Pitrou.
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com