rfi : bestpractises for implementing secure policies in python

Stephen Hansen apt.shansen at gmail.com
Tue Feb 3 02:04:54 EST 2009

> Wondering if it is at-all possible to implement "secure" (s.a. not viewable
> / tunable / tweakable) "Policies" in python ?
> Use-cases:
> 1) License enforcement -- Same application, licensed at differential price
> levels, based on various feature-sets.
> 2) "Parental-Control" enforcement. Application usable, with *all* features
> only if adult (a particular user-id) is using, and *restricted* feature set
> if a child is using it.
> 3) Enterprise Policy enforecement -- People from Dept-X shouldn't be able
> to use the application feature-set A, but only set B. However, people from
> Dept-Y should be able to feature-set A & B.
> The question is for what could be a desktop (standalone) python
> application, or a hosted (SaaS) application. The target user group includes
> "Programmers" and "hackers", so while application need not be Fort Knox (no
> national secrets or mission-critical), it need to deter basic-to-moderate
> hacker attempts at bypassing policy.

2 and 3 are very... domain-specific. You just need to implement some sort of
login procedure where users connect with a credential, and you test those
credential vs rights defined in some configuration. Exactly what the login
mechanism is depends too much on just what you're doing with your app, and
how you define users and roles and privileges as well.

As for 1, what we do is that we distribute our main application code as a
.zip file with PYC's only and no PY's. That's more then sufficient as far as
I'm concerned. If someone knows Python and knows what's going on they can
dig into a pYC and disassemble its bytecode and fiddle.. but I don't care at
that point. Someone's going to get through if they're that determined.

As for determining license enforcement, we provide a system file which
includes several fields that define what the system is capable of doing
according to the given contract/license, then a license file which is just a
checksum of the file with a simple encryption applied to it. When the app
starts it computes a checksum of the system file, decrypts the license and
compares the checksums. If it matches, we continue on.

Its not even close to perfect: someone could find which PYC had the checking
routine and disassemble it to get the key, but... its more then good enough
IMHO. I could get more cryptic and do the decryption in a C module (perhaps
written in Cython) and try to go through more effort obfuscating it... then
they'd have to disassemble an object file and know assembly to get the key.
But that's just "harder". I'm only interested in the casual protection. But
we have a solid relationship with our customers and they all have
maintenance contracts: we keep them loyal and not interested in doing
anything like that primarily by providing continued updates and enhancements
overtime. So we're only really worried about casual tweaking bypassing the


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090202/54cfdfe1/attachment.html>

More information about the Python-list mailing list