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 <steve.do...@python.org> 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://github.com/zooba/spython). I just don't want people to think > we've "solved" security for them, when there's honestly no way for us to > do it from here. > > Cheers, > Steve > -- 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/CX4DMONP5SAZRE5D337NOA5ATKW7ZGGI/ Code of Conduct: http://python.org/psf/codeofconduct/
