OpenSSL and seteuid

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL and seteuid

Steve Thompson
Question concerning the treatment of certificate and key files...

I am in the midst of SSL-enabling a large application using OpenSSL 0.9.7g
on various unix systems. I am also relatively new to OpenSSL, so I
apologize in advance if the quesion is silly. One component is a server
that, in the SSL version, starts running as user X (not root) and does the
usual SSL initialization stuff with SSL_CTX_use_certificate_chain_file,
SSL_CTX_use_PrivateKey_file, etc. The user X is the only system user
(aside from root) that has read access to these files. Communications
using TLS proceeds for a while with various clients; all is well. The
application image is setuid root and verifies at startup that it is
running as user X.

A later phase can, in some circumstances, require that the server change
its effective UID to that of user Y in order to be able to write into the
file system in an area to which only Y has write access. Data written to
the file system arrives on an SSL connection established before the UID
was changed, but that data is partly read from the connection while the
effective UID is that of user Y. The question: I am concerned that SSL
might have recourse to access the original key and certificate files some
time during this process, for example, if a renegotiation is requested by
the client. This would of course not work since user Y cannot open these
files. Is this a likely possibility, or is everything that SSL requires
already in memory of a result of the initial context setup?

-steve
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and seteuid

Dr. Stephen Henson
On Sat, Feb 11, 2006, Steve Thompson wrote:

>
> A later phase can, in some circumstances, require that the server change
> its effective UID to that of user Y in order to be able to write into the
> file system in an area to which only Y has write access. Data written to
> the file system arrives on an SSL connection established before the UID
> was changed, but that data is partly read from the connection while the
> effective UID is that of user Y. The question: I am concerned that SSL
> might have recourse to access the original key and certificate files some
> time during this process, for example, if a renegotiation is requested by
> the client. This would of course not work since user Y cannot open these
> files. Is this a likely possibility, or is everything that SSL requires
> already in memory of a result of the initial context setup?
>

The files are openened, read and converted to structures *once* initially.

After that only the in memory structures are accessed.

The only case where certificates or CRLs can be dynamically loaded is when you
specify a directory for the verify location.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and seteuid

Kyle Hamilton
In reply to this post by Steve Thompson
The only file that really needs to be protected, btw, is the
PrivateKey file.  (When a client connects to the server, the
certificate chain is going to be presented to them anyway.)

-Kyle H

On 2/11/06, Steve Thompson <[hidden email]> wrote:

> Question concerning the treatment of certificate and key files...
>
> I am in the midst of SSL-enabling a large application using OpenSSL 0.9.7g
> on various unix systems. I am also relatively new to OpenSSL, so I
> apologize in advance if the quesion is silly. One component is a server
> that, in the SSL version, starts running as user X (not root) and does the
> usual SSL initialization stuff with SSL_CTX_use_certificate_chain_file,
> SSL_CTX_use_PrivateKey_file, etc. The user X is the only system user
> (aside from root) that has read access to these files. Communications
> using TLS proceeds for a while with various clients; all is well. The
> application image is setuid root and verifies at startup that it is
> running as user X.
>
> A later phase can, in some circumstances, require that the server change
> its effective UID to that of user Y in order to be able to write into the
> file system in an area to which only Y has write access. Data written to
> the file system arrives on an SSL connection established before the UID
> was changed, but that data is partly read from the connection while the
> effective UID is that of user Y. The question: I am concerned that SSL
> might have recourse to access the original key and certificate files some
> time during this process, for example, if a renegotiation is requested by
> the client. This would of course not work since user Y cannot open these
> files. Is this a likely possibility, or is everything that SSL requires
> already in memory of a result of the initial context setup?
>
> -steve
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]