Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Tue, 2009-02-24 at 16:52 +0100, allefant wrote: I agree, It doesn't bode well for Python as a language to use for game scripting. But in this case, it just means the missing sandboxing makes it the wrong choice of tool in the first place. Python would be an ideal language to re-write the C++ parts of Wesnoth in my opinion. But even in a rewrite of Wesnoth in Python, it would still use WML for its data files, and still would use Lua scripting (once we have that). If at some point in the future someone writes a Python interpreter which can be sandboxed, this would need to be re-evaluated, I think then it would be the ideal choice also for scripting. Agreed. -- Greg Copeland KDTO (Denton, Texas) '79 M20J - N3916H ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Tue, 2009-02-24 at 16:52 +0100, allefant wrote: On Mon, Feb 23, 2009 at 10:50 PM, d...@whitevine.net wrote: My point is that there has been a call out for a long time -- for years -- that anyone wanting to make a nice API to Python for AI purposes and then to write a nice AI can. If this API doesn't sandbox Python, that's fine, we just wouldn't allow easily downloadable AI's using it. I don't think this has anything to do with the language. None of the projects to write a better C++ AI we had going on back then ever produced any results. It doesn't mean C++ is necessarily a bad language for writing AI code. It just shows that the C++ base of Wesnoth does not export an API which can be used for writing AIs which are more complex than the default one. Exporting a bad API to any language (it was only done for Python, out of all possible languages) will not magically improve this API. At least if it's a 1:1 mapping like the one the PythonAI made. Greg's wail module would have improved this, but it was hampered by the sandboxing - and at the time he joined the project sandboxing already was a requirement. Perhaps we should stand this on its head and look at it another way. We're trying to knee-cap python because of a potential attack vector. If we remove the potential attack vector we no longer have a reason to knee-cap python. Perhaps the solution is to simply not allow python scripts to be bundled in campaigns or downloaded via the campaign server. This is, after all, the source of the security risk. Preventing the download of python scripts via Wesnoth does exactly that. On the other hand, we can still provide facilities and abstraction layers for AI authors. The AI scripts will simply require downloading and installation external to the facilities provided by Wesnoth. This is very much in line with just about every game/application out there which offers scripting via python - and many others which offer scripting in other languages. Yes, there is still potential for abuse but only the non-casual user is likely to attempt such things and they will likely be directed from AI authors and other users/consumers of such scripts. This is no different than downloading anything from the Internet - including Wesnoth. Such a scheme, I believe, will make everyone happy. That is, the average and casual user is now insulated from abuse. More advanced users how have more advanced capabilities. The coders willing to create new AIs now have a powerful venue without artificial limitations. And Wesnoth can now provide high level abstractions and interfaces to fuel AI development without creating undo risk to users on the other end of the spectrum. This seems like a win-win to me. -- Greg Copeland gtcopel...@gmail.com ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
I'd like to point out that security issues aren't the only problem for our Python AI's. There's also stands the unresolved issue with redistribution of msvcr71.dll on Windows. The GNU General Public Liscence (Wesnoth's end user liscence) and the Microsoft Visual C++ v7 End User Liscence Agreement are probably not compatible. The MSVC 7 EULA restricts the re-distribution of msvcr71.dll, and MicroSoft isn't shipping msvcr71.dll with Windows either. Making things worse, there is apparently a clause in GPL that doesn't allow you to link against third party libraries unless they're part of the Operating System. (Microsoft has also included anti-GPL terms in their own open source software.) http://www.wesnoth.org/forum/viewtopic.php?p=308685#p308685 http://mail.python.org/pipermail/python-dev/2005-February/051413.html http://en.wikipedia.org/wiki/GNU_General_Public_License Furthermore, in response to allefant, I really don't think the mailing list is the appropriate place to be debating the numerous tradeoffs of Lua OR Python as replacements for scripting WML [event]s, especially since (by your own admission) you are not among our resident WML experts. You might want to take that up in the forum, where such debates have already existed for some time now: http://www.wesnoth.org/forum/viewtopic.php?f=2t=19082 -- Sapient -- From: gtcopel...@gmail.com To: wesnoth-dev@gna.org Date: Tue, 24 Feb 2009 11:03:21 -0600 Subject: Re: [Wesnoth-dev] possible security problems (eg with current python implementation) Perhaps we should stand this on its head and look at it another way. We're trying to knee-cap python because of a potential attack vector. If we remove the potential attack vector we no longer have a reason to knee-cap python. snip ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Tue, Feb 24, 2009 at 01:13:39PM -0500, Patrick Parker wrote: I'd like to point out that security issues aren't the only problem for our Python AI's. There's also stands the unresolved issue with redistribution of msvcr71.dll on Windows. The GNU General Public Liscence (Wesnoth's end user liscence) and the Microsoft Visual C++ v7 End User Liscence Agreement are probably not compatible. I don't know about this issue, but to be clear: rant class=tired *The GPL is not an end user license*. It says nothing about end users, only distribution of the software. Users need not accept the license. Copyright law forbids distribution of software without permission from the copyright holder. The GPL states that you are welcome to distribute so-licensed software, under certain conditions. To distribute GPLed software, you must agree to the license (since nothing else gives you permission to distribute it). That is all. /rant The MSVC 7 EULA restricts the re-distribution of msvcr71.dll, and MicroSoft isn't shipping msvcr71.dll with Windows either. Making things worse, there is apparently a clause in GPL that doesn't allow you to link against third party libraries unless they're part of the Operating System. (Microsoft has also included anti-GPL terms in their own open source software.) [1]http://www.wesnoth.org/forum/viewtopic.php?p=308685#p308685 [2]http://mail.python.org/pipermail/python-dev/2005-February/051413.html [3]http://en.wikipedia.org/wiki/GNU_General_Public_License Furthermore, in response to allefant, I really don't think the mailing list is the appropriate place to be debating the numerous tradeoffs of Lua OR Python as replacements for scripting WML [event]s, especially since (by your own admission) you are not among our resident WML experts. You might want to take that up in the forum, where such debates have already existed for some time now: [4]http://www.wesnoth.org/forum/viewtopic.php?f=2t=19082 -- Sapient --- From: [5]gtcopel...@gmail.com To: [6]wesnoth-...@gna.org Date: Tue, 24 Feb 2009 11:03:21 -0600 Subject: Re: [Wesnoth-dev] possible security problems (eg with current python implementation) Perhaps we should stand this on its head and look at it another way. We're trying to knee-cap python because of a potential attack vector. If we remove the potential attack vector we no longer have a reason to knee-cap python. snip References Visible links 1. http://www.wesnoth.org/forum/viewtopic.php?p=308685#p308685 2. http://mail.python.org/pipermail/python-dev/2005-February/051413.html 3. http://en.wikipedia.org/wiki/GNU_General_Public_License 4. http://www.wesnoth.org/forum/viewtopic.php?f=2t=19082 5. mailto:gtcopel...@gmail.com 6. mailto:wesnoth-dev@gna.org ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev -- +- | PGP http://www.cns.bu.edu/~cjmorlan/public-key.pgp | Cameron Morland came...@morland.ca | | Politicians are like football coaches. They have to be smart | enough to understand the game, and dumb enough to think it's important. | --anonymous +- ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Tue, Feb 24, 2009 at 7:13 PM, Patrick Parker patrick@gmail.com wrote: I'd like to point out that security issues aren't the only problem for our Python AI's. There's also stands the unresolved issue with redistribution of msvcr71.dll on Windows. True, forgot about this, so besides the security issue and the flawed API, it was a third reason to remove it. Furthermore, in response to allefant, I really don't think the mailing list is the appropriate place to be debating the numerous tradeoffs of Lua OR Python as replacements for scripting WML [event]s, especially since (by your own admission) you are not among our resident WML experts. You might want to take that up in the forum, where such debates have already existed for some time now: http://www.wesnoth.org/forum/viewtopic.php?f=2t=19082 Yes, any possible future AI or scripting additions should be discussed on the forum of course. Just was trying to clarify why I think the PythonAI failed - just generally blaming Python would be a bit simple-minded and not help prevent similar problems in the future. Ivanovic mentioned work on Lua scripting in the initial post of the thread - so my impression was this already is or will soon be available in SVN, I wouldn't really have suggested it otherwise :) ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Tue, 2009-02-24 at 21:54 +0100, allefant wrote: Yes, any possible future AI or scripting additions should be discussed on the forum of course. Just was trying to clarify why I think the PythonAI failed - just generally blaming Python would be a bit simple-minded and not help prevent similar problems in the future. Ivanovic mentioned work on Lua scripting in the initial post of the thread - so my impression was this already is or will soon be available in SVN, I wouldn't really have suggested it otherwise :) I take it a python solution without a sandbox will never be an option even if downloading of python scripts is excluded? Any particular reason to completely exclude the development of python AIs regardless of sandbox status? -- Greg Copeland gtcopel...@gmail.com ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
Quoting Greg Copeland gtcopel...@gmail.com: I take it a python solution without a sandbox will never be an option even if downloading of python scripts is excluded? Any particular reason to completely exclude the development of python AIs regardless of sandbox status? It absolutely would be an option. If someone can develop a *good* Python API for AI's (or any other game feature, for that matter) and then people can develop provably good, useful AI's, then we would be happy to use it. The sandboxing issue would only affect whether we'd allow people to easily download extensions that use Python. This is really the same for any technology. If you're excited about a technology, that's great, but the best way to channel your excitement is to develop something high quality for Wesnoth using that technology, and then show it to us. Just saying, this technology is great! It should be used in Wesnoth is not a very productive approach. David ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
Considering the usual level of security expertise for an average user, this is no option at all to me. Better use a language designed for such usage. Agreed, we are a video game, our users can have any age over 8, we can't expect them to do informed security decision. Bye, David ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Sun, 2009-02-22 at 19:25 -0800, Daniel Franke wrote: Nils Kneuper crazy-ivano...@gmx.net writes: 1) Limit PythonAI usage to stuff only available in the data/ main tree, nothing from userdata. 2) Completely deactivate Python for the 1.6 series. This means not even allowing it to be compiled into the binary via the build systems. It was I who proposed option (1), but I think I'm coming around to (2), given the whole system's state of disuse and disrepair. However, I agree that replacing it should be a priority. If silene's Lua work turns out well, I think it ought to be backported to the 1.6 branch. I'm now in favor of removing Python AI support entirely from both 1.4 and 1.5, and releasing 1.5.11 and 1.4.8 as soon we've done this and also fixed bug #13037. ESR, this to my knowledge makes you the last holdout in favor of option (1). Any new thoughts? I'm very pro-python. I'm the author of what was the start of the wail module. Having tried to work within the confines of the existing infrastructure, I do not see Python as a viable scripting option. Safe.py is nothing but a headache disguised as security. In my opinion safe.py is the single reason python scripting never went anywhere. It prevents access to the majority of python's language features, modules, and is the single reason why everything is low level. In short, safe.py prevents access to what is commonly known as the python language. Until a security model or acceptable security policy is endorsed, there exists no reason to provide python as a scripting language. I personally would prefer for users be forced to police their own security. In doing so we could offer a dual environment. One where safe.py is used and requires no user interaction. The other where users are alerted to the potential security risk and must accept or reject the risks associated with a script. In turn this opens the door for python to actually have value and for high level interface abstractions to be created. Unless something like this is accepted, I do not see python as a viable solution for Wesnoth. -- Greg Copeland gtcopel...@gmail.com ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Okay, in revision 33040 dfranke removed PythonAI support from Wesnoth. That is in 1.6 *no* Python is available ingame at all. Python is still used for several external tools (like eg wmllint and many others), but the game itself will not rely on Python at all. This should be enough security to basically solve CVE-2009-0367 in the upcoming stable series. For the moment we can only recommend to *NOT* activate python when compiling a 1.4.x binary. All distributions should keep this in mind, since it is basically the easiest workaround of those problems. Beside this the diff from revision 33013 [1] is required to have the campaign DiD still working. In general our addon server for 1.4.x will not send anything python related that the game can make use of, but users can of course copy the stuff in from anywhere in the depths of the net, so the only way to be secure is to deactivate python support all together! For later releases (post the 1.6 stable branch) we will have to see how we handle scripting support in Wesnoth. Cheers, Nils Kneuper aka Ivanovic [1]http://svn.gna.org/viewcvs/wesnoth?rev=33013view=rev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmiwGkACgkQfFda9thizwVIUgCfbyW0wMkRwUQazK/XFQbVXrwL 9KMAmQH7GoEoy8i+ls+NYvj1P5j25Gn9 =M1SK -END PGP SIGNATURE- ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
На Mon, 23 Feb 2009 16:27:38 +0100 Nils Kneuper crazy-ivano...@gmx.net wrote: In general our addon server for 1.4.x will not send anything python related that the game can make use of, but users can of course copy the stuff in from anywhere in the depths of the net, so the only way to be secure is to deactivate python support all together! Even that is not secure, since users can get *standalone* python programs anywhere in the depths of the net which don't rely on Wesnoth to run!! ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Mon, Feb 23, 2009 at 3:40 PM, Greg Copeland gtcopel...@gmail.com wrote: I'm very pro-python. I'm the author of what was the start of the wail module. Having tried to work within the confines of the existing infrastructure, I do not see Python as a viable scripting option. Safe.py is nothing but a headache disguised as security. In my opinion safe.py is the single reason python scripting never went anywhere. It prevents access to the majority of python's language features, modules, and is the single reason why everything is low level. In short, safe.py prevents access to what is commonly known as the python language. Until a security model or acceptable security policy is endorsed, there exists no reason to provide python as a scripting language. We had Python support for years without safe.py or any restrictions at all. So this can't have been the problem. It was more that the API was really low level. All it ever did was export some AI related C++ classes. And the resulting scripts were very complicated and un-pythonic. If we had had something like your wail module from the beginning, I'm sure it would have been used much more. Also, the real reason to use scripting is not to write new AIs from scratch, but to augment the existing AI, and to script WML events. Both are not possible with the current PythonAI. Give items to units, modify terrain, create new user interfaces elements, ... endless things which make scripting fun and useful. But nothing of it was possible. And this is all independent of security. I personally would prefer for users be forced to police their own security. In doing so we could offer a dual environment. One where safe.py is used and requires no user interaction. The other where users are alerted to the potential security risk and must accept or reject the risks associated with a script. In turn this opens the door for python to actually have value and for high level interface abstractions to be created. Unless something like this is accepted, I do not see python as a viable solution for Wesnoth. Yes, and the model where you can execute any WML (with or without scripts embedded) clearly is the nicer one for a game like Wesnoth. The only way to get that with Python would be some kind of sandboxing module, but it does not exist (safe.py was the best you could get in that direction). So let's hope for a nice Lua scripting interface now. Once the Python developers provide a sandbox module (or someone implements a safe Python interpreter), it should be very easy to hook this to the then proven scripting interface (with the only change that you could use Python instead of Lua to access the scripting API). ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Sun, Feb 22, 2009 at 07:25:46PM -0800, Daniel Franke wrote: Nils Kneuper crazy-ivano...@gmx.net writes: 1) Limit PythonAI usage to stuff only available in the data/ main tree, nothing from userdata. 2) Completely deactivate Python for the 1.6 series. This means not even allowing it to be compiled into the binary via the build systems. It was I who proposed option (1), but I think I'm coming around to (2), given the whole system's state of disuse and disrepair. However, I agree that replacing it should be a priority. If silene's Lua work turns out well, I think it ought to be backported to the 1.6 branch. No if lua works well it shouldn't be backported, that violates the idea of a stable branch. -- Regards, Mark de Wever aka Mordante/SkeletonCrew ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Mon, Feb 23, 2009 at 03:49:52PM +0100, David Philippi wrote: Am Montag 23 Februar 2009 schrieb Greg Copeland: I personally would prefer for users be forced to police their own security. In doing so we could offer a dual environment. One where Considering the usual level of security expertise for an average user, this is no option at all to me. Better use a language designed for such usage. Agreed on both points. -- Regards, Mark de Wever aka Mordante/SkeletonCrew ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Mon, 2009-02-23 at 18:54 +0100, allefant wrote: We had Python support for years without safe.py or any restrictions at all. So this can't have been the problem. It may not have been the original problem. It is a significant problem now. I've spoken with and exchanged many forum posts, IRC comments, and emails with people who claim to have a desire to write AIs in python but can not do so because no abstraction layers exist, making it too hard to create or augment AIs. What prevents an abstraction layer for python is safe.py. So while it may not have been the original problem, these days, if it is not the sole largest obstacle, it is on par with any other large obstacle preventing uptake of python for AI creation and augmentation. I can say in absolute terms, the only thing preventing Wesnoth from having a usable wail module now was the endless problems of trying to work with and extend/around safe.py. I can't begin to tell you how many hours I wasted trying to get some usable solution which didn't completely gut python. Those hours could have been spent creating a usable abstraction layer. Personally I believe your argument is one of false economics. There are many reasons which may have prevented python uptake but once safe.py was put in place, it became the largest obstacle to all forward progress and future uptake for python in Wesnoth. It was more that the API was really low level. Which is really saying the same thing. The API is low level because with a gutted python that is all that will every be possible or available. A higher level abstraction is possible if it is written on the C++ side and exposed as a module but it doesn't change the fact safe.py guts python and prevents it from being python. This forces everything to be treated at the lowest levels in the python language and utterly prevents many possibilities; including many, many keywords, fundamental modules, and pythonic solutions. In other words, too many things become very hard or impossible. All it ever did was export some AI related C++ classes. And the resulting scripts were very complicated and un-pythonic. And unless safe.py is removed this is all you will ever have. If we had had something like your wail module from the beginning, I'm sure it would have been used much more. I believe that too - but wail is not possible so long as safe.py exists. Also, the real reason to use scripting is not to write new AIs from scratch, but to augment the existing AI, and to script WML events. I argue both are the objective whereas the largest draw is likely augmentation rather than creation. [snip] And this is all independent of security. Not so long as python is in the mix. Game mechanic augmentation (rewards, reenforcements, etc) can be done within the confines of safe.py. Anything beyond is, IMO, hopelessly limited so long as safe.py is in the mix. [snip] As I fully expect no one wants to let go of safe.py so long as python is available, I do not see python has much value to add; especially if lua is available shortly. While I much, much prefer python to lua, so long as users are to take absolutely no responsibility for themselves, short of an official sandbox implementation, python is an impossibility. -- Greg Copeland gtcopel...@gmail.com ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
Quoting allefant allef...@gmail.com: Also, the real reason to use scripting is not to write new AIs from scratch, but to augment the existing AI If we really can't develop a decent C++/Python API and then develop a decent AI in Python, I don't think it bodes well for those who want to convert more and more of Wesnoth into Python. I mean, this is a perfect test project to show how well Python can integrate with our existing code and then show off the superior productivity of Python, but so far the results have been almost nothing. David ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
d...@whitevine.net writes: If we really can't develop a decent C++/Python API and then develop a decent AI in Python, I don't think it bodes well for those who want to convert more and more of Wesnoth into Python. I mean, this is a perfect test project to show how well Python can integrate with our existing code and then show off the superior productivity of Python, but so far the results have been almost nothing. I disagree. The problems with the Python AI that have been described in this thread all stem from attempting to sandbox Python and thereby attempt to put a square peg in a round hole. Sandboxing is a very specialized problem. There are only a few languages that are any good at it; Python isn't one of them and neither is C++. Converting more pieces of Wesnoth to Python may or may not be workable, but this debacle is not evidence in either direction. -- Daniel Franke d...@dfranke.us http://www.dfranke.us || =|\ || * | -|-\- Man is free at the instant he wants to be. -| =| \ /// --Voltaire ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
Quoting Daniel Franke d...@dfranke.us: d...@whitevine.net writes: If we really can't develop a decent C++/Python API and then develop a decent AI in Python, I don't think it bodes well for those who want to convert more and more of Wesnoth into Python. I mean, this is a perfect test project to show how well Python can integrate with our existing code and then show off the superior productivity of Python, but so far the results have been almost nothing. I disagree. The problems with the Python AI that have been described in this thread My post was admittedly a teensy bit off the topic of this thread. all stem from attempting to sandbox Python and thereby attempt to put a square peg in a round hole. Sandboxing is a very specialized problem. There are only a few languages that are any good at it; Python isn't one of them and neither is C++. Converting more pieces of Wesnoth to Python may or may not be workable, but this debacle is not evidence in either direction. For a time we didn't sandbox Python, and if someone wanted to develop a nice Python API that wasn't sandboxed and then allow normal/checked in code (i.e. not downloadable) to run an AI we'd have always been fine with it. My point is that there has been a call out for a long time -- for years -- that anyone wanting to make a nice API to Python for AI purposes and then to write a nice AI can. If this API doesn't sandbox Python, that's fine, we just wouldn't allow easily downloadable AI's using it. Out of all this all we have gotten is a crappy API and no decent AI's. That is what doesn't bode well for Python. David -- Daniel Franke d...@dfranke.us http://www.dfranke.us || =|\ || * | -|-\- Man is free at the instant he wants to be. -| =| \ /// --Voltaire ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] possible security problems (eg with current python implementation)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody! dfranke lately spotted several possible security issues in our code. That is of those findings, so far two led us to the conclusion serious enough for official reporting so that Rhonda submitted two new CVE for us: 1) CVE-2009-0366 was submitted for bug #13037 [1] 2) CVE-2009-0367 was submitted for bug #13048 [2] The interesting question is how to fix those issues. From IRC conversations it looks like silene will have a look at the first one (not sure though...). More interesting is the second problem which allows python scripts to escape our sandbox. In IRC we came to two possible solutions for the soon planned 1.6 release. For post 1.7.x and later stuff we should have a closer look at all this stuff anyway... Here are the two possible (short term) solutions: 1) Limit PythonAI usage to stuff only available in the data/ main tree, nothing from userdata. 2) Completely deactivate Python for the 1.6 series. This means not even allowing it to be compiled into the binary via the build systems. Currently python only allows to write scripts for AI stuff, nothing else. It seems to not be widely used at all. In mainline we do ship some AI scripts for multiplayer, but they seem to not be too well maintained and even non functional at the moment[3]. Until today there was a PythonAI for a scenario in DiD but it was removed now and Dragonking will work on implementing something that actually works in FormulaAI. This are all PythonAI usages in mainline. Beside this users seem to not have created much using PythonAI even though it is already possible to use it since 1.2.x days. So what would the benefits for users be if it was possible to load Python stuff from the main dir? Probably not much at all. It would be possible to create AIs themselves, but this option is basically unused. As zookeeper pointed out in IRC today, it is just too difficult to really make use of it (at least at the moment). The benefit of removing Python support from ingame for 1.6 all together would be that no security problems in this module were possible at all and that the dependencies would be reduced a little (this should save several MB in the package size for OSX...). For post 1.6 we should have a closer look at allowing better scripting facilities in Wesnoth to allow content creators more flexibility. Adding real support for some way of scripting will be needed and we will have to have a look at what works best as in the aspects of is it secure enough?. do we have someone to implement it? and will content creators be able to use it?. Possible candidates for this are lua (there is some patch already by silene for some basic stuff, we will have to evaluate how much sandboxing is possible there) and maybe python, though there we will have problems with sandboxing and atm this seems to be a field of research, so rather problematic for us to solve in a good was. Beside this FormulaAI should be further extended to make it really useful, too. Long mail cut short: What about 1.6? Should we got for 1) or for 2)? Or does anyone of you have even a better idea what we should do? Personally I vote for 2) since PythonAI is not really used and it would reduce the (possible) security problems with it to zero (not to speak about the positive impact on packagers with less dependencies). Please reply to this mail, so that we can come to a decision soon. Cheers, Nils Kneuper aka Ivanovic [1]https://gna.org/bugs/index.php?13037 [2]https://gna.org/bugs/index.php?13048 [3]https://gna.org/bugs/index.php?13047 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmhhn8ACgkQfFda9thizwXbzwCfRk0wrJn7oYILx5Ls4hFvd1L1 jJMAn0woJ+e/Dl4EBIqvPLFe4efy2mou =xgMM -END PGP SIGNATURE- ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Sun, Feb 22, 2009 at 6:08 PM, Nils Kneuper crazy-ivano...@gmx.net wrote: Long mail cut short: What about 1.6? Should we got for 1) or for 2)? Or does anyone of you have even a better idea what we should do? Personally I vote for 2) since PythonAI is not really used and it would reduce the (possible) security problems with it to zero (not to speak about the positive impact on packagers with less dependencies). I'd also say, go for 2. The current PythonAI implementation had two big design problems from the start. First, it uses the C-Python API which is very low-level and makes it hard to maintain. This means, it's not a big loss removing this version - if Python scripting is wanted, better start fresh with Boost::Python or similar. Second, no thought was spent on security when it was first implemented. Historically, when I was taking over maintenance of it for some time, I first added code to the campaign server to disallow Python scripts until someone would verify it (this is essentially the security model used by most other projects allowing Python scripting). Later someone provided us with the safe.py wrapper - but the idea was flawed from the beginning. For one, it removed a lot of the Python language features, so scripts aren't really Python any longer. And it adds a lot more maintenance burden again, apparently neither the queue nor the threading module were safe to whitelist - the original author of safe.py likely would have known that, but I did not. Casically, Python does not support sandboxing - but I think it's a feature we much should require for Wesnoth scripting. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
just a quick note : the bugs reported are private i.e only registered devs can view them, however, this mailing list is not. So please avoid discussing the vulnerabilites themselves here this might be obvious to everybody, but it's better repeated OK, I would also vote for 2, my main argument is that there is still a known attack vector which can lead to serious problems, even if it si mitigated. Moreover, pythonAI has been around since 1.2 and no serious attempt to use it was produced. I don't think this feature will be used in the future anyway. If it was meant to happen, it would already have happened Boucman On Sun, Feb 22, 2009 at 6:28 PM, allefant allef...@gmail.com wrote: On Sun, Feb 22, 2009 at 6:08 PM, Nils Kneuper crazy-ivano...@gmx.net wrote: Long mail cut short: What about 1.6? Should we got for 1) or for 2)? Or does anyone of you have even a better idea what we should do? Personally I vote for 2) since PythonAI is not really used and it would reduce the (possible) security problems with it to zero (not to speak about the positive impact on packagers with less dependencies). I'd also say, go for 2. The current PythonAI implementation had two big design problems from the start. First, it uses the C-Python API which is very low-level and makes it hard to maintain. This means, it's not a big loss removing this version - if Python scripting is wanted, better start fresh with Boost::Python or similar. Second, no thought was spent on security when it was first implemented. Historically, when I was taking over maintenance of it for some time, I first added code to the campaign server to disallow Python scripts until someone would verify it (this is essentially the security model used by most other projects allowing Python scripting). Later someone provided us with the safe.py wrapper - but the idea was flawed from the beginning. For one, it removed a lot of the Python language features, so scripts aren't really Python any longer. And it adds a lot more maintenance burden again, apparently neither the queue nor the threading module were safe to whitelist - the original author of safe.py likely would have known that, but I did not. Casically, Python does not support sandboxing - but I think it's a feature we much should require for Wesnoth scripting. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
Nils Kneuper crazy-ivano...@gmx.net writes: 1) Limit PythonAI usage to stuff only available in the data/ main tree, nothing from userdata. 2) Completely deactivate Python for the 1.6 series. This means not even allowing it to be compiled into the binary via the build systems. It was I who proposed option (1), but I think I'm coming around to (2), given the whole system's state of disuse and disrepair. However, I agree that replacing it should be a priority. If silene's Lua work turns out well, I think it ought to be backported to the 1.6 branch. I'm now in favor of removing Python AI support entirely from both 1.4 and 1.5, and releasing 1.5.11 and 1.4.8 as soon we've done this and also fixed bug #13037. ESR, this to my knowledge makes you the last holdout in favor of option (1). Any new thoughts? -- Daniel Franke d...@dfranke.us http://www.dfranke.us || =|\ || * | -|-\- Man is free at the instant he wants to be. -| =| \ /// --Voltaire ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
