Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #71035 > unrolled thread

Using ssl.wrap_socket() in chroot jail

Back to article view | Back to comp.lang.python

Contents

  Using ssl.wrap_socket() in chroot jail Grant Edwards <invalid@invalid.invalid> - 2014-05-07 15:42 +0000
    Re: Using ssl.wrap_socket() in chroot jail Chris Angelico <rosuav@gmail.com> - 2014-05-08 02:04 +1000
    Re: Using ssl.wrap_socket() in chroot jail Christian Heimes <christian@python.org> - 2014-05-07 20:11 +0200
      Re: Using ssl.wrap_socket() in chroot jail Grant Edwards <invalid@invalid.invalid> - 2014-05-07 18:51 +0000
        Re: Using ssl.wrap_socket() in chroot jail Chris Angelico <rosuav@gmail.com> - 2014-05-08 12:12 +1000
          Re: Using ssl.wrap_socket() in chroot jail Grant Edwards <invalid@invalid.invalid> - 2014-05-08 13:31 +0000

#71035 — Using ssl.wrap_socket() in chroot jail

Let's say you have a server/daemon application written in python that
accepts incoming SSL connections.

You want to run that application in a chroot jail.  

The last thing you want in that jail is your SSL certificate private
key file.

But, it appears the ssl module won't accept SSL certificates and keys
as data strings, or as stringio file objects.  It will only accept a
filename, and it has to open/read that file every time a connection is
accepted.

So how do you avoid having your certificate key file sitting, readable,
in the chroot jail?

-- 
Grant Edwards               grant.b.edwards        Yow! An Italian is COMBING
                                  at               his hair in suburban DES
                              gmail.com            MOINES!

[toc] | [next] | [standalone]

#71037

On Thu, May 8, 2014 at 1:42 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> But, it appears the ssl module won't accept SSL certificates and keys
> as data strings, or as stringio file objects.  It will only accept a
> filename, and it has to open/read that file every time a connection is
> accepted.
>
> So how do you avoid having your certificate key file sitting, readable,
> in the chroot jail?

I was going to say "if all else fails, monkey-patch", but the source
code shows that the Python ssl module just passes the file name
straight on to _ssl... and, what's more, that _ssl.c just passes it
right along to SSL_CTX_use_PrivateKey_file which I presume is part of
OpenSSL.

Is it possible for you to initialize an SSLContext before chrooting,
and just hold that in memory? You can then use its wrap_socket instead
of the default wrap_socket. According to the docstring for SSLContext,
it can hold "... possibly a private key", but I don't see a parameter
for that; that's probably just indicative of my lack of experience
with Python's ssl module, though.

If you invoke Python entirely within the chroot jail, though, I don't
know of a way around it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#71043

On 07.05.2014 17:42, Grant Edwards wrote:
> Let's say you have a server/daemon application written in python that
> accepts incoming SSL connections.
> 
> You want to run that application in a chroot jail.  
> 
> The last thing you want in that jail is your SSL certificate private
> key file.
> 
> But, it appears the ssl module won't accept SSL certificates and keys
> as data strings, or as stringio file objects.  It will only accept a
> filename, and it has to open/read that file every time a connection is
> accepted.
> 
> So how do you avoid having your certificate key file sitting, readable,
> in the chroot jail?

Python's SSL module can't load private key from memory. I wanted to
implement that feature for 3.4 but the feature wasn't ready by then.
You have multiple options:

* create a SSLContext, then chroot()
* use pyOpenSSL / cryptography als TLS library
* don't do SSL in your daemon and let some proxy or load balancer do TLS
offloading, e.g. NGinx or Apache + mod_proxy

Christian

[toc] | [prev] | [next] | [standalone]

#71045

On 2014-05-07, Christian Heimes <christian@python.org> wrote:
> On 07.05.2014 17:42, Grant Edwards wrote:
>> Let's say you have a server/daemon application written in python that
>> accepts incoming SSL connections.
>> 
>> You want to run that application in a chroot jail.  
>> 
>> The last thing you want in that jail is your SSL certificate private
>> key file.

[...]

> Python's SSL module can't load private key from memory. I wanted to
> implement that feature for 3.4 but the feature wasn't ready by then.
> You have multiple options:
>
> * create a SSLContext, then chroot()
> * use pyOpenSSL / cryptography als TLS library
> * don't do SSL in your daemon and let some proxy or load balancer do TLS
>   offloading, e.g. NGinx or Apache + mod_proxy

Unfortunately, the actual SSL wrapping stuff isn't being done in my
code.  It's being done by the secure-smtpd module, which will pass
whatever cert/key params I give it to ssl.wrap_socket().  That still
leaves the third option (e.g. stunnel).

Thanks.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm wearing PAMPERS!!
                                  at               
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#71071

On Thu, May 8, 2014 at 4:51 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> Unfortunately, the actual SSL wrapping stuff isn't being done in my
> code.  It's being done by the secure-smtpd module, which will pass
> whatever cert/key params I give it to ssl.wrap_socket().  That still
> leaves the third option (e.g. stunnel).

I'll go back to the naughty-crazy idea of monkey-patching, then: can
you create an SSLContext prior to chrooting, then stuff its
wrap_socket back into the ssl module?

ChrisA

[toc] | [prev] | [next] | [standalone]

#71098

On 2014-05-08, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, May 8, 2014 at 4:51 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> Unfortunately, the actual SSL wrapping stuff isn't being done in my
>> code.  It's being done by the secure-smtpd module, which will pass
>> whatever cert/key params I give it to ssl.wrap_socket().  That still
>> leaves the third option (e.g. stunnel).
>
> I'll go back to the naughty-crazy idea of monkey-patching, then: can
> you create an SSLContext prior to chrooting, then stuff its
> wrap_socket back into the ssl module?

Probably. I'll have to give that a try after I figure out some of the
other "Unix daemon" issues.  Any imports that happen after chroot()ing
are going to fail (I think), and I'm not sure if that's going to be a
problem or not...

-- 
Grant Edwards               grant.b.edwards        Yow! Do you like "TENDER
                                  at               VITTLES"?
                              gmail.com            

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web