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
_______________________________________________
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/QRIZNJTTL54DE3CYUIGTOHWO2SPBHOJW/
Code of Conduct: http://python.org/psf/codeofconduct/
