I knew the audit hooks were new but didn't realize they were quite that new. I didn't mean to come across as pejorative asking if people cared about this. The fact that I had trouble finding more information made me think this good stuff had been left by the wayside. It's new, I'll to pump the brakes a little and let things take their course.
I wasn't aware of the configuration system for 3.8. I'll look into that. When I was in there poking around I kept wondering why we didn't have a fancy configuration system. The good news is we do I just didn't know about it. You're completely right about my implementation logging to a file. I fully admit my code wasn't camera ready. Once I learned that the hooks existed I wanted to give them a try. Once I got it working I wanted to get some feedback. Thank you for the feedback. I'm glad somebody is thinking about these types of things and I'd love to help if I can. On Thu, Nov 21, 2019 at 2:49 PM Christian Heimes <christ...@python.org> wrote: > On 21/11/2019 18.27, Jason Killen wrote: > > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > > switch to using io.open_code when appropriate. In the process of making > > those PRs I spent a bit of time reading the two related PEPs. In > > PEP-551 there's a suggestion that people use a restricted entry point in > > production environments. I googled around a bit and couldn't find any > > evidence that there was an existing implementation, at least not made > > public, that people were using in a general sense. So I created a > > branch from my fork and over the last few days have implemented part of > > what's suggested in PEP-551. Specifically my changes remove most of the > > command line options, ignore envvars (except for a possible logging > > filename for the audit hooks), and registers an audit hook that logs > > everything to the defined envvar when provided or stderr if not. > > As Steve already pointed out, https://github.com/zooba/spython contains > examples examples for Windows and Linux. The linux_xattr is a PoC that I > developed for our joined talk at EuroPython 2019. > > > Now the questions: > > 1) Does anybody care? Is anyone currently doing this or planning on > > doing this? > > 2) Do we want to provide an "official" version of a restricted entry > > point that could be used as-is or easily modified per specific needs? > > Seems kinda silly to make everyone roll their own version but I'm happy > > to yield to the will of the people. > > 3) What's the chance we wanna merge something like this into the > > official master branch? I accomplished what I wanted to do using a few > > #ifdef's and some funky makefile magic. I think it would merge easily. > > Maintaining a fork sounds like a lot of work to me. > > Yes, we still care. Steve has been more active on the Windows side than > me on the Linux side. Please keep in mind that the feature is new to > Python 3.8 and 3.8.0 just came out a little more than a month ago. It's > going to take a while until major vendors will make use of the feature. > > PEP 578 features require distribution and vendor-specific adjustments. > For example it makes sense to disable byte code compilation and usage on > Windows. On the other hand RPM based platforms like RHEL always want to > use precompiled byte code because PYC files are shipped with RPM packages. > > > And here's the code: > > I'm very open to suggestions. I basically have no idea what I'm doing. > > I haven't touched C in about 7 years so don't expect the Mona Lisa. > > > https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point > > Thanks for your work! Prototypes like this are useful to figure out how > Python's configuration should be improved. Eventually it should not be > necessary to modify any code in CPython to create an spython > interpreter. I like to reach a state in which it is possible to > configure all these flags by providing a custom configuration. Victor's > new config system in 3.8 can accomplish almost everything. It is > currently not possible to modify argument parsing, though. > > One comment about your implementation: > You are logging to a file. It's not very useful to log to a target in > the same security context except for debugging. If an attacker is able > to compromise the interpreter, then the attacker most likely gains > enough privileges to wipe the file. That's why Steve uses the Windows > event log in his examples and I'm going for syslog and journald. These > logging system run as a different user and log files are protected by > additional means, e.g. SELinux. I have been working on structures > journald logging recently. > > Christian > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/HCSME57BS2AEAATLFMPLCKMWUYZX4SCM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Jason Killen jsnk...@gmail.com Pain is inevitable, misery is optional.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AV7PKVM2WAFYVBJZ4M5FQ635J3XCDKYV/ Code of Conduct: http://python.org/psf/codeofconduct/
