[Python-Dev] PEP 578: Python Runtime Audit Hooks (original) (raw)

Steve Dower steve.dower at python.org
Tue Apr 16 16:53:26 EDT 2019

On 16Apr2019 0532, Christian Heimes wrote:

Sorry, I forgot to reply.

Do you think it would make sense to split the PEP into two PEPs? The auditing hook and import opener hook are related, but distinct improvements. The auditing part looks solid and ready now. The import opener may need some more refinement. I would also like to get feedback from some Linux Kernel security engineers first.

That will make three PEPs...

The only question for the security engineers is "how much context do you need from the calling process", as that's the only thing that will affect the API. It doesn't have to have any implementation right now.

And so far, all the context that's been proposed is "may be executed", which is already implied in the open_code() call. I haven't heard any more requests than "give us the filename and let us return the open (and exclusive) handle/descriptor", so this feels like YAGNI.

On 01/04/2019 18.31, Steve Dower wrote:

In each case there should be associated audit events for tracking the intent (and interrupting at that point if it doesn't like the intended action), but for the simple case of "let me open this specific file" it doesn't really add much. And it almost certainly shouldn't impact decision making. There is no need to trust the intent flag that much. I would like to have a way to further narrow down the scope for an open call. This would allow the caller to tell the hook "I want to open something that should be a shared library suitable for ctypes". It would allow tighter control.

But those don't go through open(), they'll go through dlopen(), right? It's already a totally different code path from "open and read arbitrary bytes".

Audit events are useful and powerful. But I don't want to put too much burden on the auditing framwork. I prefer to have checks that prevent operations rather than allow operations and audit them.

Right, and this is the default position for security defenders (to try and block things) ;) Auditing has been found to be a working balance

- Context is an optional Python object from the caller's context. For the import system, it could be the loader instance.

I think the audit event covers this, unless you have some way of using this context in mind that I can't think of? To be honest I don't have a good use case yet. I just like the idea to have a way to pass some custom thing into an API and now who called an API. You seem to like it, too. Your hook has a void *userData, but it's not passed into the Python function. :) int PyImportSetOpenForImportHook(hookfunc handler, void *userData)

There is no Python function for the (now named) open_code hook. It can only be set as a C function by an embedder, and that's when the userData is provided. Nothing to do with each individual call - just one value per CPython runtime. (Similarly with the audit hook, but for the Python hooks you can pass a closure or a method - in C you need a separate pointer for this.)

Cheers, Steve

More information about the Python-Dev mailing list