[Python-Dev] Restricted Entry Point from PEP-551/578
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. 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. 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 -- 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/KYEKDEGSI5B7BSY7XCJ36TE6XCBM2GML/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
Thanks. Yea if you bring all the backchannels together at some point I would like to be included mostly as a listener. I totally agree about not wanting people to think we've "solved" security. I expected that might be the reason this hadn't been done. On the other hand I think some sort of starting point or examples are very useful so we don't all reinvent the wheel. Your spython branch seems to be what I was looking for but couldn't find. I'm gonna clone it and poke around a bit. How can we make your fork easier to find? Googling for spython doesn't even get you in the right neighborhood. Can we include a link in the PEP? On Thu, Nov 21, 2019 at 1:09 PM Steve Dower wrote: > On 21Nov2019 0927, 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. > > Hi Jason. Great to see that you're interested! > > Right now there isn't an existing implementation, mainly because the > value is very limited unless you also integrate into other system > security services. Since CPython runs on so many platforms, there was no > way for us to support all the possible combinations upstream, so instead > we made it easy to extend so that distributors can customise it for > their own platform (including sysadmins who want to customise for their > own internal setups). > > You can watch the presentations I gave on this recently (top few links > at https://stevedower.id.au/speaking), or read my whitepaper at > https://aka.ms/sys.audit (which will be rolled into PEP 551 soon). > > I have also some samples at https://github.com/zooba/spython (that are > shown and discussed in the whitepaper). > > > Now the questions: > > 1) Does anybody care? Is anyone currently doing this or planning on > > doing this? > > Yes, quite a few people care. It's mostly being discussed with me on > backchannels right now though, and I haven't even connected everyone > together yet. If you're interested, I'll include you when I do? > > > 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. > > As I said above, an "official" one can only go so far. I'd prefer to see > the Linux distros have their own official one (e.g. if I'm on RHEL then > I use Red Hat's restricted entry point, etc.) > > > 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. > > The fork is very minimal now that the hooks are available in core. I've > been involved in maintaining a true fork (based on 3.6 without the > hooks) and *that* is a lot of work, but now that it can all be done from > the entry-point it's actually pretty simple. > > > 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 > > I think this looks almost exactly like what we would merge if we were > going to merge anything. My concern is that I think if we offer anything > at all it will discourage people/distros from actually implementing it > properly for their context, and so we make things worse. Making it easy > to extend without actually doing it seems like a better place to be. > > And I'm totally in favour of publishing ready-to-build samples (again, > see https://g
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
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 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 fil
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
I'm good, not discouraged. Thank you for the explanation I've got my bearings now. I will try and figure out what's missing with the new config system. If you have tips or reading material or anything else I should know just send it on otherwise I'll start googling. On Thu, Nov 21, 2019 at 4:30 PM Christian Heimes wrote: > On 21/11/2019 21.19, Jason Killen wrote: > > 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. > > I'm sorry, I wasn't trying to stop you or discourage you in any way. It > was my intent to provide an explanation why there is not much adoption > of the new hooks yet. Please go ahead, put the paddle to the metal and > play around with the new features! > > For example you could look into the new config system and figure out > what is missing to build an spython interpreter. > > 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/5KKLTIKNY37GK4ZK4DJGGOHAPZFQHGN5/ > 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/6E3CKBZXKFRXZLRD5SCAWBERUYBUP3QI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
I did a quick hack up of letting configs control what command line options were available. I'm not sure y'all wanted it but here it is. I'm happy to take suggestions including tossing the whole thing and chalking it up to experience. It's lightly tested with the syslog implementation from the spython repo. https://github.com/python/cpython/compare/master...jsnklln:cmdline_options_controled_by_config On Thu, Nov 21, 2019 at 9:36 PM Terry Reedy wrote: > On 11/21/2019 4:46 PM, Steve Dower wrote: > > (though some won't be raised until 3.8.1... we should probably mark > > those, or at least update that page to warn that events may have been > > added over time). > > I included this in a new audit doc issue. > https://bugs.python.org/issue38892 > > -- > Terry Jan Reedy > ___ > 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/OBHSBXUMM6EML35MY76QPAP7PQVNEHBY/ > 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/XMJWSYDFOLGCIMIODRXJQ47G42B55TN5/ Code of Conduct: http://python.org/psf/codeofconduct/
