It seems to me that the event audit subsystem already available in python confirms the possibility of more complex ideas for implementing an integrated security subsystem without the need to use virtual machines and containers.
I will try to summarize them in one list, but this is probably not a complete list.
Creating a full-fledged hook system, when can’t only monitor the progress of execution but also replace the arguments passed to the functions and results of execution or interrupt it
Loading standard modules and classes (or at least only the part that is responsible for important actions for the user) in read-only mode, when it’s impossible to change the behavior of their attributes in the future
Control over the possibility of receiving and changing frames
Monitoring and setting memory usage limits to prevent memory overflow attacks
Tracking the switching of execution to third-party C code with the ability to interrupt such execution
Of course, all these items must be customizable and optional so that the user can select the optimal security model for own tasks.
I hope this list will be discussed and updated.
Perhaps the implementation of most of these points is very difficult, but it’s important to understand exactly what, although difficult, is feasible and what is unrealizable. It’s also very likely that there are still unaccounted for attack vectors, which are also interesting to discuss and consider.
I emphasize once again, this isn’t a list of any requirements for implementation, this is a list for making an accurate understanding of whether it’s possible to create at least a limited security subsystem only by means of a python interpreter.
This idea was already suggested and rejected in the last few weeks wasn’t it?
Conclusion was: The python audit system is not the basis for a secure, sandboxed python. Python is not designed to allow such a secure, sandboxed environment.
This is a reload of the discussion. There are more chances to discuss the issues in detail with the core developers here.
There were no conclusions from the core developers. All issues require considerable discussion to conclude that such a system is impossible.
If you carefully read everything above, then there is talk about the event audit subsystem as an example of monitoring capabilities, and it’s proposed to discuss a number of points on creating a more powerful system. To consider essentially, without general words.
The above are specific points in the implementation of which it is possible to create a secure system with some restrictions.
Most users do not need complete security “from everything”. It’s important for them to gradually close the attack vectors, and first the most critical ones. And this seems quite possible.
In general, if you want to discuss it, then you give specific examples of the impossibility of this in your opinion. In response, I give counterarguments and counterexamples. But if there are no concrete arguments and examples, then this is only your personal opinion so far.
I would assume that core devs aren’t responding because they don’t want to discuss this. And you can’t demand that they care about this.
You might have success if you make small targeted proposals, or if you become a core dev, or if you find a core dev who is willing to support and mentor you for the next few years.
Making these kinds of open ended threads with the goal of arguing with everyone who tells you that python is fundamentally not sandboxable is not going to have a positive effect on the way you are viewed nor on the success chances of your proposals.
Yes, but the topic was originally created in the wrong section. And it was moved to a completely inappropriate section, where it slipped into an empty altercation with ordinary users. After discussion with the moderators, it was decided to try to restart the discussion.
Here I will discuss only specific things on the topic of discussion. If someone just wants to argue without specific arguments then in the future I will simply ignore such messages.
After all, if everything is like that, and such a subsystem is impossible, then there should be no problem to give specific examples of its impossibility.
There is even a special footnote in the original post about this
And they are even specially compiled into a list in the original message of this topic
And I’ll answer you about this, and I probably won’t discuss this kind of remark anymore.
My goal is not to argue with someone. I have already proposed a specific list of points for discussion.
If there are specific arguments about the impossibility, there will be my no less specific counterarguments.
If not, then my list will remain here for the future, for those who want to discuss it on its merits.
But if someone wants to argue about complete spherical security, about my humble person, then they will do it without my participation.
That is multiple proposals with no independent justification. Make a thread arguing for one of those and expect to spend a year or so on just getting that one point implemented. Start with the smallest one.
If you want to make large systematic changes like you seem to want to based on the fact that you have a list of independent features, it would be better if you become a core dev by contributing to python outside of this specific goal, or if you find a core dev that fully supports you.
As a core developer, my view is that making a secure sandbox for Python is not possible in the way you describe. Plenty of people over the years (including a number of core developers!) have tried and failed to make a secure sandbox, and the general view of the core devs is that this isn’t possible.
If you want to try, then obviously you can - this is an open source project and you’re entitled to spend your time however you choose. But you won’t get much interest or help from the core team unless you show up with a ready-made solution which has been battle-tested against serious attempts to break it. And even then, I doubt it will be added to core Python - there’s simply too much risk to make it worth even suggesting that Python is safe to this level.
That’s all I’m going to say on this matter. I’ve spent a lot of time over the years following discussions like this, that ultimately led to failure. I don’t want to get involved in yet another one, sorry.
First, I just want to discuss these points in detail and specifically. In detail and specifically, without general words, as was often the case in the previous topic. And only then think further about their implementation.
But if there are no specific discussions, then this is interesting only to me. And then I will decide for myself what, when and how to implement and whether to implement at all. And the list will remain for future generations of core developers
And so you just suggest that I do everything and think for myself. But I can go this way myself at any time
No, that is not what I am suggesting. But I don’t think anything I say will change your mind, so you do you, I am bowing out of this and probably any future discussion with you.
Nevertheless, I have given specific points that can be implemented. And I want to discuss them on the merits.
And if I see the impossibility of their implementation, I will close the discussion myself.
And so, of course, I can do the implementation myself, but first I want to understand in detail the problems that arose during past iterations of such development. So far, there are a lot of general words, but very few specific examples of problems.
And the example of the implementation of the event audit subsystem still suggests that much more can be implemented.
But discussions are needed. And if there are none, let’s just leave a list of specific items for future generations of core developers to discuss
And of course I don’t force anyone to participate in the discussions. As well as participation without specific examples of emerging problems is also unproductive.
There Victor Stinner (a core developer) discusses pysandbox and “that putting a sandbox directly in Python cannot be secure. To build a secure sandbox, the whole Python process must be put in an external sandbox” with other core developers.
But it was since then that the event audit system appeared.
As for Victor’s arguments, could you put them together in a structured list like mine so that we can discuss them on the merits?
I have identified the following for myself:
It seemed to me that this was the main reasoned remark there.
But it’s strange to hear about such a problem, if in the future it’s possible to create readonly modules then it’s solved simply globals()[__builtins __] = ModuleProxy(__builtins __)
Or let other ways to access builtins be listed.
It is unclear what problems this is fraught with, if it’s impossible to replace any other important modular functions and classes.
But even if suddenly something deeper is hidden behind this, again, can implement the creation of proxy objects with read-only access.
It’s not a problem at all. It’s just implemented in the event audit.
There is a separate item about frames in my original message.
This looks very vague. Specific code examples are needed. For some reason, none of this interfered with the implementation of event auditing.
Why don’t you try implementing this non-trivially-circumvent-able read only proxy object that you’re hinging so many of your assumptions on? That’s a self contained specific (and to us impossible) problem you’ll need to overcome before any of us can possibly stop thinking of this whole proposal as a fantasy.
It’s just strange that so far none of the core developers have allowed themselves to say this
Probably because something like this has already been implemented through MappingProxy
class A: pass
A.__dict__ = { "a": "a" } # AttributeError: attribute '__dict__' of 'type' objects is not writable
A.__dict__["a"] = "a" # TypeError: 'mappingproxy' object does not support item assignment
And even if it’s not easy to transfer this implementation to all other python objects, it’s quite feasible.
I have already answered this above, but I will probably answer it for the last time and try not to respond to such messages anymore.
How it looks from the outside. I describe specific things and try to discuss them. Instead, many people tell me in general words about the impossibility of such things. Then someone still tries to find at least some specific arguments. In return, I provide no less specific counterarguments. And then suddenly a new person comes with the insight that I must first implement everything myself and then discuss something.
Although it seemed to me that an adequate process has the opposite form: first need to comprehensively discuss the issues and then proceed to implementation with the understanding that I have previously assessed most of the possible pitfalls. And it seemed to me that there is exactly the largest community of python experts in the world, which helps each other understand the depth of problems with specific examples.
And the main result for me in any case: even if I don’t get any specific counterarguments now, let my list of points remain for the future, and when someone does implement them, maybe they will remember about me
No, that’s how it looks to you. You are the OP and do not have an outside perspective on this discussion.
How it looks from the outside is that you expect others to do your homework for you. You have made a list of vague ideas, and now want others to explain to you why they won’t work.
Successful idea proposals work the other way around: You do the work to demonstrate that your idea is sound (including at the very least a proof-of-concept implementation). Only then can you expect others to take you seriously.
As many have tried to tell you, this is not how it works. The onus is on you to make the case for your idea(s), not on others to make the case against them.
