[Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

[Gregory P. Smith]

On Tue, Feb 26, 2019 at 2:31 PM Steve Dower <steve.dower at python.org> wrote:

> On 2/26/2019 1:20 PM, Gregory P. Smith wrote:
> > For an OS distro provided interpreter, being able to restrict its use to
> > only OS distro provided software would be ideal (so ideal that people
> > who haven't learned the hard distro maintenance lessons may hate me for
> it).
> >
> > Such a restriction could be implemented within the interpreter itself.
> > For example: Say that only this set of fully qualified path whitelisted
> > .py files are allowed to invoke it, with no interactive, stdin, or
> > command line "-c" use allowed.  I'm not aware of anyone actually having
> > done that.  It's hard to see how to do that in a /maintainable/ manner
> > that people using many distros wouldn't just naively work around by
> > adding themselves to the whitelist rather than providing their own
> > interpreter for their own software stack.  It feels more doable without
> > workarounds for something like macOS or any other distro wholly
> > controlled and maintained as a single set of software rather than a
> > widely varying packages.
> >
> > Solving that is way outside the scope of PEP 394.  Just food for thought
> > that I'd like to leave as an earworm for the future for distro minded
> > folks.  I some people to hate this idea.
>
> I haven't caught up on this thread yet, but this sounds a lot like the
> "Restricting the entry point" section of
> https://www.python.org/dev/peps/pep-0551/ (which is still a draft, so if
> anyone wants to help make it more like what they want, I'm happy to have
> contributors).
>
> So I'm in favour of making this easy (since I'm already having to deal
> with it being difficult ;) ), as it's extremely valuable for
> security-conscious deployments as well as the distro package cases
> mentioned by Gregory.
>

Similar. What I'm talking about has nothing to do with _security_
(pep-0551's focus) and only to do with installed interpreter
maintainability.  But an implementation of the concept of deciding what is
allowed to use an entry point in what manner might be the same.  :)

As for 551, I'm not a fan of pretending you can aid security by restricting
use of an interpreter; when an adversary has the ability to trigger an exec
of new process with args or input of its desire, their opponent lost the
game several moves ago.  Defense in depth minded people may disagree and
still desire the feature.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190227/de162c2e/attachment.html>