Re: [Openhpi-devel] OpenHPI security

[Mohan <mo...@fc...>]

Thanks for going through the licensing David.

We will look into the dependency issue further. We will look into the
options available. It will take some time.

Thanks
Mohan



On Tue, 2013-02-26 at 07:27 -0800, David Mckinley wrote:
> Hemantha,
> 
> Actually, it appears that both glib and gcrypt are LGPL licensed, which is not so bad. My previous email was based on a quick check that seemed to indicate that gcrypt was GPL rather than LGPL licensed.  Checking further, I see that there is more to the story. 
> 
> This is in the README file (version 1.5):
> 
>     The library is distributed under the terms of the GNU Lesser
>     General Public License (LGPL); see the file COPYING.LIB for the
>     actual terms.  The helper programs (e.g. gcryptrnd and getrandom)
>     as well as the documentation are distributed under the terms of
>     the GNU General Public License (GPL); see the file COPYING for the
>     actual terms.
> 
>     This library used to be available under the GPL - this was changed
>     with version 1.1.7 with the rationale that there are now many free
>     crypto libraries available and many of them come with capabilities
>     similar to Libcrypt.  We decided that to foster the use of
>     cryptography in Free Software an LGPLed library would make more
>     sense because it avoids problems due to license incompatibilities
>     between some Free Software licenses and the GPL.
> 
> So, as long as those "helper programs" are not required, then I guess libcrypt is now LGPL, and does not cause any more problems than glib does for openhpi licensing.  But, if the parts that are GPL licensed are required, then that needs to be carefully considered.
> 
> In any case, the main issue still seems to be this:  Why make libcrypt a mandatory dependency?  Can it not be set up so that it is only required if encryption of the configuration file is desired?
> 
> David
> 
> > -----Original Message-----
> > From: Beecherla, Hemantha [mailto:hem...@hp...]
> > Sent: Monday, February 25, 2013 5:11 PM
> > To: ope...@li...
> > Subject: Re: [Openhpi-devel] OpenHPI security
> > 
> > Hi David,
> > I am able to see OpenHPI base library is depending on Glib and it is
> > GPL licensed library like gcrypt.
> > And Gib is required at build time, and it used by Infrastructure as
> > well as plugins.
> > 
> > Thanks& regards,
> > Hemantha Reddy
> > 
> > -----Original Message-----
> > From: David Mckinley [mailto:dav...@or...]
> > Sent: Monday, February 25, 2013 9:51 AM
> > To: ope...@li...
> > Subject: Re: [Openhpi-devel] OpenHPI security
> > 
> > Hello,
> > 
> > I would think that introducing a dependency on a GPL licensed library
> > is a problem for OpenHPI; its BSD-style license is important to many
> > users.  I suppose if the dependency is only at build-time, and
> > ultimately OpenHPI can be installed and operable on systems without
> > gcrypt, that would be acceptable.  But, if that is the case, why not
> > fix the build system so that the dependency does not exist unless
> > gcrypt use is selected by ./configure?
> > 
> > Regards,
> > 
> > David
> > 
> > > -----Original Message-----
> > > From: Mohan [mailto:mo...@fc...]
> > > Sent: Monday, February 25, 2013 10:23 AM
> > > To: Anton Pak
> > > Cc: ope...@li...
> > > Subject: Re: [Openhpi-devel] OpenHPI security
> > >
> > > Hi Anton,
> > >
> > > Thank you very much for the immediate reply.
> > > My responses are in-line
> > >
> > > On Sat, 2013-02-23 at 01:27 +0400, Anton Pak wrote:
> > > > Hello!
> > > >
> > > > My points of concern (I haven't looked into the solution
> > thoroughly):
> > > >
> > > > o) Seems with this patch it is not possible to build OpenHPI for
> > > linux
> > > > without gcrypt.
> > > That's true. OpenHPI has gcrypt dependency now.
> > >
> > > >
> > > > o) Is gcrypt a well-known libs? Is it widely recognized in embedded
> > > domain?
> > > It is a well-known library. It is installed by default on the RHEL
> > and
> > > SLES systems because so many other applications depend on it. There
> > > are many different embedded applications, some of them stripped to
> > > bare bones. I do not know how well it is recognized in all of these
> > > embedded applications. Need help to look into this.
> > >
> > > >
> > > > o) What about Solaris and FreeBSD variants?
> > >
> > > I have not looked into these two. Does anybody have these systems? I
> > > will try to install these and see if gcrypt gets installed
> > > automatically.
> > >
> > > >
> > > > o) On my system /sys/devices/virtual/dmi/id/product_uuid is for
> > root
> > > only
> > > > to read.
> > > > Will it be possible to run OpenHPI under non-privileged user
> > account?
> > >
> > > Yes, if the uuid file is not there or not accessible, then the
> > default
> > > password is used.  So a non-privileged effective user can encrypt and
> > > run openhpid against an encrypted config file.
> > >
> > > >
> > > > o) That uuid - is it hardware-dependent? Will it change if I
> > replace
> > > some
> > > > peaces of
> > > > hardware?
> > >
> > > Very good question. It is supposed to be dependent on the mother
> > board.
> > > So it is not supposed to change. I need to test this. What are the
> > > pieces of hardware you are thinking of? I will try to replace memory,
> > > hard disk, etc.
> > >
> > > >
> > > > o) How to prevent decryption if a bad guy has access to the config
> > > and to
> > > > the uuid?
> > >
> > > This encryption takes care of the disks that are removed from the
> > > system, it takes care of the security audits etc.  If the bad guy has
> > > the root access, uuid and the config file then he can decrypt the
> > file.
> > > It identifies the bad guy (he needs to have intention to decrypt the
> > > file, it is not just lying around).
> > >
> > > Thanks
> > > Mohan
> > >
> > >
> > >
> > > >
> > > > 	Anton Pak
> > > >
> > > > On Sat, 23 Feb 2013 00:51:01 +0400, Mohan <mo...@fc...> wrote:
> > > >
> > > > > Since the last time we talked about OpenHPI security, the
> > > > > following
> > > has
> > > > > happened. We filed a bug against the security loop hole we had in
> > > > > permissions for accessing the config file, openhpi.conf.  The bug
> > > number
> > > > > is 3566478,  Daemon needs to check config file security.  We
> > fixed
> > > the
> > > > > issue by creating the config file with 0600 permissions and
> > > checking the
> > > > > user permissions of the file and directory during execution
> > > > > against
> > > the
> > > > > effective user of the program.
> > > > >
> > > > > What remained was encrypting the config file. There were several
> > > reasons
> > > > > why we wanted to encrypt that file. It contains passwords and
> > > > > plain
> > > text
> > > > > password files are caught in the security audits. End of life
> > > systems
> > > > > with plain text password files is a security loop hole as there
> > is
> > > a
> > > > > chance that the disks could end up in other systems.
> > > > >
> > > > > Earlier discussion on this topic was very productive. Eight
> > > different
> > > > > people in this thread provided several suggestions over a period
> > > > > of couple months. With all the input, we went to design a
> > solution.
> > > The
> > > > > solution had following requirements.
> > > > > a. Maintain the current behavior by default.
> > > > > b. Provide an option to encrypt the config file using a tool.
> > > > > c. Use a system identifier as a key, if that is not available use
> > > > > a default key.
> > > > > d. Let the daemon handle the decrypted text in memory rather than
> > > > > writing to disk.
> > > > > e. Use an encryption package that is generally available and
> > > > > widely used.
> > > > > f. Provide a tool to encrypt and decrypt the config file.
> > > > > g. Let the tool and openhpi link against the same libraries.
> > > > > h. Isolate this encryption code.
> > > > >
> > > > > Based on the above requirements, we coded and tested a solution.
> > > The
> > > > > following are its salient points.
> > > > >
> > > > > a. Used gcrypt package. More than 10 other packages depend on
> > > > > this,
> > > so
> > > > > it is already present on RHEL and SLES
> > > > >
> > > > > b. Created a small tool, hpicrypt, to encrypt and decrypt the
> > > config
> > > > > file.
> > > > >
> > > > > c. The system uuid is used as a key to encrypt the file and it is
> > > read
> > > > > from /sys/devices, not stored in openhpi. If uuid is not
> > > > > available,
> > > a
> > > > > default key is used (DOB of OpenHPI) for encryption. Usually
> > every
> > > > > system has a unique uuid. If an encrypted file is copied from one
> > > system
> > > > > to a different system, it cannot be decrypted easily.
> > > > >
> > > > > d. One new header file and source file ( sahpi_gcrypt_utils.[ch]
> > )
> > > > > contains all the encryption and decryption functions.  It becomes
> > > the
> > > > > part of utils library, which is linked against by the tool and
> > the
> > > > > daemon.
> > > > >
> > > > > e. User uses -d option to the daemon to decrypt the config file,
> > > > > in memory and use it.
> > > > >
> > > > > We have modified the sources, makefiles, README file etc and
> > > created the
> > > > > patch. We do hope it addresses all the concerns we had. It takes
> > > care of
> > > > > the security audits and the end of life systems and disks
> > > > > separated
> > > from
> > > > > the systems. If some one is bent on breaking the security, he may
> > > be
> > > > > able to do it, but this is a big deterrent.
> > > > >
> > > > > Please review the patch and let's know your feedback. Since this
> > > > > is
> > > a
> > > > > new use case, please review it from the use model too. We would
> > > like to
> > > > > take care of most of the use models and document it properly so
> > > that it
> > > > > is easy to use.
> > > > >
> > > > > Regards
> > > > > Mohan
> > > > >
> > > > >
> > > > > On Wed, 2012-09-12 at 16:48 -0600, mo...@fc... wrote:
> > > > >> While it is true that it is very difficult to provide a fool
> > > > >> proof security system as Corey mentioned, as a first step
> > towards
> > > > >> a
> > > better
> > > > >> solution, let's start with encrypted config file option, so
> > clear
> > > text
> > > > >> passwords problem is fixed.
> > > > >>
> > > > >> There are few defects / enhancement requests filed. Hope
> > everyone
> > > in
> > > > >> this list got the bug mails too.
> > > > >>
> > > > >> OpenHPI is relying solely on the standard system security. Even
> > > > >> if
> > > we
> > > > >> are unable to completely safeguard the information, OpenHPI
> > could
> > > make
> > > > >> it more difficult to get to the passwords than what it does
> > today.
> > > > >>
> > > > >> What are the things we could do to make the config file or a
> > file
> > > that
> > > > >> contains login information a non-human readable one? We need to
> > > find a
> > > > >> solution that is acceptable and reasonable to implement.
> > > > >>
> > > > >> The following are the ideas that we discussed so far. Most of
> > > these are
> > > > >> pragmatic ideas leading to simple solutions.
> > > > >> 1. Create a tool to encrypt openhpi.conf, let openhpid decrypt
> > it.
> > > -
> > > > >> Michael Thompson
> > > > >> 2. Like SSH, keys could be stored in protected files, check
> > > > >> file/directory permissions on startup - Anton Pak 3. Encrypt
> > with
> > > > >> default key in automated installs. Allow the user
> > > to
> > > > >> provide the key in manual installs. Store the key in secure
> > > location -
> > > > >> Mohan
> > > > >> 4. Generate a random key during make and store in inside the
> > > binary (not
> > > > >> source code). This could be used by encrypting application. -
> > > Bryan
> > > > >> Sutula
> > > > >> 5. Let daemon/application create an one way encrypted password
> > > file.
> > > > >> Daemon/application could use the same password to create a key
> > > > >> for decrypt/encrypt the file. Daemon opens a socket to read the
> > > password and
> > > > >> match the encrypted password before proceeding. - Mohan 6. Let a
> > > > >> tool setup openhpi.conf file. Setup permissions so that
> > > only
> > > > >> the tool and openhpi can access that file. Let the user setup
> > > selinux -
> > > > >> Corey Minyard
> > > > >> 7. Use an environment variable to hold the key/password (used in
> > > > >> ipmiutil/ipmitool) - Andy Cress.
> > > > >> 8. Using an environment variable with an option to over-ride it.
> > > vim -x
> > > > >> could be used to create the passphrase protected openhpi.conf
> > > > >> file
> > > -
> > > > >> discussions with Shuah
> > > > >>
> > > > >> Any one of the above could work to enhance the security that we
> > > have
> > > > >> right now. A closer look at it shows most of the above are
> > > > >> similar
> > > to
> > > > >> one another. For example, many of them have the idea of
> > > > >> encrypting
> > > with
> > > > >> a default key with an option for the user to specify his own key
> > > and
> > > > >> safe guarding the key with permissions.
> > > > >>
> > > > >> It appears that we could use most of the above ideas in our
> > > solution.
> > > > >> What do you think? Again, it may not be perfect, but far better
> > > than
> > > > >> what it is today.
> > > > >>
> > > > >> Please do share your thoughts. We could work on a detailed
> > design
> > > for a
> > > > >> better solution.
> > > > >>
> > > > >>
> > > > >> Regards
> > > > >> Mohan
> > > > >>
> > > > >>
> > > > >> On Sat, 2012-09-08 at 00:35 +0400, Anton Pak wrote:
> > > > >> > In that case intruder just executes "cat /proc/<pid>/environ"
> > > and
> > > > >> sees the
> > > > >> > password.
> > > > >> >
> > > > >> > Also the question is who will set that env. var and when.
> > > > >> >
> > > > >> > 	Anton Pak
> > > > >> >
> > > > >> > On Sat, 08 Sep 2012 00:35:31 +0400, Andy Cress
> > > > >> <and...@us...>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > One alternative to storing the passwords in a non-volatile
> > > config
> > > > >> file,
> > > > >> > > is to support the capability to read them from an
> > environment
> > > > >> variable.
> > > > >> > > The environment variable 'IPMI_PASSWORD' is what ipmiutil
> > and
> > > > >> ipmitool
> > > > >> > > use for this purpose, as an option.
> > > > >> > >
> > > > >> > > This gets around some cases of accidentally exposing the
> > > password,
> > > > >> so it
> > > > >> > > is somewhat better, but does not solve the case for multiple
> > > targets
> > > > >> > > with different passwords.
> > > > >> > >
> > > > >> > > Andy
> > > > >> > >
> > > > >> > > -----Original Message-----
> > > > >> > > From: Corey Minyard [mailto:cmi...@mv...]
> > > > >> > > Sent: Friday, September 07, 2012 2:37 PM
> > > > >> > > To: ope...@li...
> > > > >> > > Subject: Re: [Openhpi-devel] OpenHPI security
> > > > >> > >
> > > > >> > > On 09/07/2012 01:25 PM, Anton Pak wrote:
> > > > >> > >> So what is the point against plain test passwords in the
> > > file?
> > > > >> > >> With proper permissions only openhpi user or root can read
> > > it.
> > > > >> > >> If intruder already has openhpi or root rights and openhpi
> > > sources
> > > > >> > > then
> > > > >> > >> the solted and hashed password does not stop him.
> > > > >> > >
> > > > >> > > IMHO, proper permissions is the right way to handle the
> > > > >> > > issue,
> > > and
> > > > >> > > suggest selinux if a user is really paranoid and is willing
> > > > >> > > to
> > > pay
> > > > >> the
> > > > >> > > price.
> > > > >> > >
> > > > >> > > -corey
> > > > >> > >
> > > > >> > >> 	Anton Pak
> > > > >> > >>
> > > > >> > >> On Fri, 07 Sep 2012 22:19:06 +0400, Corey Minyard
> > > > >> > > <cmi...@mv...>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >>> On 09/07/2012 12:36 PM, mo...@fc... wrote:
> > > > >> > >>>> On Thu, 2012-09-06 at 13:31 -0500, Corey Minyard wrote:
> > > > >> > >>>>> Your approach has a number of usability and security
> > > issues.
> > > > >> But
> > > > >> > >>>>> that's
> > > > >> > >>>>> not the fundamental issue. One-way encryptions has it's
> > > uses,
> > > > >> but
> > > > >> > > it
> > > > >> > >>>>> offers no protection for someone with root access (as
> > > > >> > >>>>> they
> > > can
> > > > >> > > change
> > > > >> > >>>>> the keys to whatever they want).  And I'm not sure of
> > the
> > > point
> > > > >> of
> > > > >> > >>>>> storing the key someplace.  If someone enters the wrong
> > > key, you
> > > > >> > > will
> > > > >> > >>>>> know.
> > > > >> > >>>> I completely agree with someone with root access can
> > break
> > > the
> > > > >> > > security.
> > > > >> > >>>> They could even change the kernel to get what they want.
> > > > >> > >>>>> Putting keys in binaries is just a bad idea.  They are
> > > > >> > >>>>> all
> > > the
> > > > >> same
> > > > >> > > and
> > > > >> > >>>>> they can't be easily changed.  A recipe for a security
> > > disaster.
> > > > >> > >>>> If we connect to the daemon to give the password then
> > this
> > > is
> > > > >> like a
> > > > >> > >>>> login application on the local system. The keys need not
> > > > >> > >>>> be
> > > > >> stored
> > > > >> > > in
> > > > >> > >>>> the binaries or on the local system.
> > > > >> > >>>>> That may sound harsh, but designing good security
> > > procedures is
> > > > >> > > *very
> > > > >> > >>>>> very very* hard.
> > > > >> > >>>> True. It is taking a long time and it is still in
> > > discussion
> > > > >> stage -
> > > > >> > > on
> > > > >> > >>>> the mailing list, one-on-one, meetings etc.
> > > > >> > >>>>> Anything that requires human interaction (like
> > connecting
> > > to a
> > > > >> > > local
> > > > >> > >>>>> socket) is just not going to work in a large server farm
> > > or a
> > > > >> > > remote
> > > > >> > >>>>> telecom system.  That's fundamental issue #1.
> > > > >> > >>>> We could even think of opening a socket and waiting for a
> > > > >> connection
> > > > >> > >>>> from some other machine (like "openhpi_sshd"!). That way
> > > openhpid
> > > > >> > > could
> > > > >> > >>>> run on a remote system too. Openhpid is expected to run
> > > > >> > >>>> for
> > > a
> > > > >> long
> > > > >> > > time.
> > > > >> > >>>> The config file has to be setup anyway. After the config
> > > file
> > > > >> setup,
> > > > >> > > the
> > > > >> > >>>> openhpid has to be started by some means. So one time
> > > > >> > >>>> login
> > > > >> should
> > > > >> > > not
> > > > >> > >>>> be a big deal.
> > > > >> > >>> That's actually just another security hole.  (Yet more
> > > > >> > >>> proof
> > > that
> > > > >> > > this
> > > > >> > >>> stuff is hard :).  A rogue user on the machine to open the
> > > socket
> > > > >> and
> > > > >> > >>> wait for a connection and get the password that way.
> > > > >> > >>>
> > > > >> > >>>>> Fundamental issue #2 is that the credentials in the
> > > > >> configuration
> > > > >> > > file
> > > > >> > >>>>> are for connecting to other systems.  You have to have
> > > > >> > >>>>> the
> > > > >> original
> > > > >> > >>>>> credentials, and openhpi has to be able to read them.
> > > > >> > >>>> This is correct. The encrypted file needs to be read
> > using
> > > the
> > > > >> key
> > > > >> > > that
> > > > >> > >>>> is supplied through the socket or login when the openhpi
> > > was
> > > > >> > > started. So
> > > > >> > >>>> far, other than root user defeating the security
> > > > >> > >>>> mechanism,
> > > I am
> > > > >> not
> > > > >> > >>>> seeing the problem in using a openhpi starter key as a
> > > viable
> > > > >> > > solution.
> > > > >> > >>>> The major difference between the login and this is the
> > > stored
> > > > >> config
> > > > >> > >>>> file which was encrypted using a password/key when it was
> > > > >> created.
> > > > >> > >>>>
> > > > >> > >>>>> Put another way, the credentials have to be stored in a
> > > way that
> > > > >> > >>>>> openhpi
> > > > >> > >>>>> can read them and use them for connecting to remote
> > > systems.  If
> > > > >> > >>>>> openhpi
> > > > >> > >>>>> can do this, then *anything* on the system with
> > > > >> > >>>>> equivalent
> > > > >> > > privileges
> > > > >> > >>>>> (like root) is going to be able to do it.  You can go
> > > through
> > > > >> all
> > > > >> > > kinds
> > > > >> > >>>>> of machinations, but in the end, that is the bottom
> > line.
> > > > >> > > Something
> > > > >> > >>>>> can
> > > > >> > >>>>> always open the openhpi process memory image and pull
> > the
> > > > >> password
> > > > >> > > out.
> > > > >> > >>>>> That's not as hard as it sounds.
> > > > >> > >>>> This is true. A root user can do what ever he wants to do
> > > on the
> > > > >> > > system,
> > > > >> > >>>> including reading the memory image.
> > > > >> > >>> I guess the point of the above is to say that setting the
> > > > >> permissions
> > > > >> > > of
> > > > >> > >>> the config file to 0600 is just as good as anything else
> > > like
> > > > >> this.
> > > > >> > >>>
> > > > >> > >>>>> You could use selinux to help here, and perhaps provide
> > a
> > > tool
> > > > >> for
> > > > >> > >>>>> updating the configuration file and only give that tool
> > > and
> > > > >> openhpi
> > > > >> > >>>>> access to the file.  Setting up selinux is a big job,
> > but
> > > it's
> > > > >> not
> > > > >> > >>>>> nearly as bad as it used to be, and if you really are
> > > concerned,
> > > > >> > > IMHO
> > > > >> > >>>>> that's what you should do.
> > > > >> > >>>> Do not know much about selinux. I am sure a root user
> > > > >> > >>>> could
> > > bust
> > > > >> the
> > > > >> > >>>> security here too. As you mention, the config file needs
> > > > >> > >>>> to
> > > be
> > > > >> > > accessed
> > > > >> > >>>> only by the tool that generates the file and the
> > openhpid.
> > > > >> > >>> selinux implements mandatory access controls.  That means
> > > that
> > > > >> every
> > > > >> > >>> single program on the machine, run by root or not, can
> > only
> > > access
> > > > >> > > files
> > > > >> > >>> (or any other resource) that it is explicitly allowed to
> > > access.
> > > > >> So
> > > > >> > > if
> > > > >> > >>> "vi" is not allowed to open openhpi.conf, then it can't,
> > > even if
> > > > >> run
> > > > >> > > by
> > > > >> > >>> root.
> > > > >> > >>>
> > > > >> > >>> No security is ever going to be perfect, of course, but if
> > > > >> properly
> > > > >> > >>> implemented it should keep the passwords secure even if
> > > someone
> > > > >> gets
> > > > >> > >>> root on the machine.
> > > > >> > >>>
> > > > >> > >>>>> Validating proper permissions is, of course, a good
> > idea.
> > > > >> > >>>> This is one thing everyone agrees to so far :)
> > > > >> > >>> :-).
> > > > >> > >>>
> > > > >> > >>> -corey
> > > > >> > >>>
> > > > >> > >>>>> -corey
> > > > >> > >>>> Mohan
> > > > >> > >>>>
> > > > >> > >>>>> On 09/06/2012 12:52 PM, mo...@fc... wrote:
> > > > >> > >>>>>> Thanks a lot for the thoughtful responses. The
> > following
> > > things
> > > > >> > > are
> > > > >> > >>>>>> clear from your mail.
> > > > >> > >>>>>> - We may not be able to interrupt the install of
> > openhpi
> > > as it
> > > > >> may
> > > > >> > > be
> > > > >> > >>>>>> installed as part of the system and distributions
> > > > >> > >>>>>> control
> > > the
> > > > >> > > process.
> > > > >> > >>>>>> - We may not be able to provide the password or
> > > paraphrase
> > > > >> during
> > > > >> > > the
> > > > >> > >>>>>> start of the daemon as it is started automatically. The
> > > > >> > > stdin/stdout
> > > > >> > >>>>>> are
> > > > >> > >>>>>> also blocked.
> > > > >> > >>>>>> - We may not be able to change the passwords for many
> > > many
> > > > >> systems
> > > > >> > > and
> > > > >> > >>>>>> encrypt each one of them independently as it is
> > > cumbersome.
> > > > >> > >>>>>> - We need to look at the existing solutions for
> > managing
> > > the
> > > > >> > > security
> > > > >> > >>>>>> instead of implementing everything in openhpi.
> > > > >> > >>>>>>
> > > > >> > >>>>>> Looks like build generating its own key during the
> > build
> > > could
> > > > >> > > work
> > > > >> > >>>>>> and
> > > > >> > >>>>>> it could become part of the optimized code (not
> > > > >> > >>>>>> generated
> > > > >> during
> > > > >> > > debug
> > > > >> > >>>>>> build). Using the "current time" to the nanosecond
> > > accuracy
> > > > >> could
> > > > >> > >>>>>> help.
> > > > >> > >>>>>> We need to make sure, the build does not print the key.
> > > > >> > >>>>>>
> > > > >> > >>>>>> Had a chance to discuss this problem with some people
> > > here.
> > > > >> One of
> > > > >> > >>>>>> potential solution was to use the one way encryption,
> > > > >> > >>>>>> the
> > > same
> > > > >> way
> > > > >> > >>>>>> password logins are executed. Here are the thoughts
> > > > >> > >>>>>> - Have a tool to create the openhpi.conf file. The tool
> > > takes
> > > > >> the
> > > > >> > >>>>>> password and stores the one way encrypted password in a
> > > file.
> > > > >> > >>>>>> Generates
> > > > >> > >>>>>> a key based on the password and uses the key to encrypt
> > > the
> > > > >> > >>>>>> openhpi.conf
> > > > >> > >>>>>> file.
> > > > >> > >>>>>> - When the daemon starts, it puts a message in syslog
> > > > >> indicating
> > > > >> > > it is
> > > > >> > >>>>>> waiting for the password and it opens a socket and
> > waits
> > > for
> > > > >> the
> > > > >> > > user
> > > > >> > >>>>>> to
> > > > >> > >>>>>> connect using an application to supply the password.
> > > > >> > >>>>>> - Any client that is trying to connect to the daemon
> > > > >> > >>>>>> gets
> > > a
> > > > >> > > message
> > > > >> > >>>>>> that
> > > > >> > >>>>>> the user has not provided the password to decrypt the
> > > > >> openhpi.conf
> > > > >> > >>>>>> file.
> > > > >> > >>>>>> - Once the daemon gets the password, it can encrypt it
> > > and
> > > > >> match
> > > > >> > > the
> > > > >> > >>>>>> encrypted password with the stored file and generate a
> > > key to
> > > > >> > > decrypt
> > > > >> > >>>>>> the openhpi.conf file and proceed further.
> > > > >> > >>>>>> - If the user forgets the password, he needs to run the
> > > tool to
> > > > >> > > create
> > > > >> > >>>>>> the openhpi.conf file and the encrypted password file
> > > again. He
> > > > >> > > will
> > > > >> > >>>>>> not
> > > > >> > >>>>>> be able to retrieve the credentials in the old file.
> > > > >> > >>>>>>
> > > > >> > >>>>>> What are the pitfalls or usability problems you could
> > > > >> > >>>>>> see
> > > in
> > > > >> this
> > > > >> > >>>>>> approach?
> > > > >> > >>>>>>
> > > > >> > >>>>>> One thing that Anton mentioned in a previous message
> > > > >> > >>>>>> that
> > > we
> > > > >> need
> > > > >> > > to
> > > > >> > >>>>>> make sure the directory permissions and file
> > permissions
> > > are
> > > > >> valid
> > > > >> > >>>>>> before proceeding needs to be implemented as it is
> > > fundamental
> > > > >> to
> > > > >> > >>>>>> security.
> > > > >> > >>>>>>
> > > > >> > >>>>>> Mohan
> > > > >> > >>>>>>
> > > > >> > >>>>>> On Wed, 2012-09-05 at 19:37 -0600, Bryan Sutula wrote:
> > > > >> > >>>>>>> I'm still not sure we can completely protect these
> > > passwords
> > > > >> (or
> > > > >> > > any
> > > > >> > >>>>>>> credentials) if the attacker has root access.
> > > Nevertheless,
> > > > >> > > comments
> > > > >> > >>>>>>> below.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> If the Red Hat or SuSE packagers are still watching
> > > > >> > >>>>>>> this
> > > list,
> > > > >> > >>>>>>> perhaps
> > > > >> > >>>>>>> they have ideas or input on what follows.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> On Wed, 2012-09-05 at 10:30 -0600, mo...@fc...
> > > wrote:
> > > > >> > >>>>>>> [...]
> > > > >> > >>>>>>>> Clear text passwords are frowned upon nowadays.
> > > Encrypting
> > > > >> the
> > > > >> > > conf
> > > > >> > >>>>>>>> file
> > > > >> > >>>>>>>> could help. A malicious hacker could get into the
> > file
> > > as it
> > > > >> is
> > > > >> > > an
> > > > >> > >>>>>>>> open
> > > > >> > >>>>>>>> source. We could make it harder. Here are some of the
> > > things
> > > > >> > > that I
> > > > >> > >>>>>>>> could think of.
> > > > >> > >>>>>>>> - Get the key from the user during installation and
> > > store
> > > > >> > >>>>>>>> in /var/lib/openhpi. Encrypt this file using a
> > default
> > > key.
> > > > >> > >>>>>>>> - Decrypt the file to get the key and use this key to
> > > decrypt
> > > > >> > > conf
> > > > >> > >>>>>>>> file.
> > > > >> > >>>>>>>>
> > > > >> > >>>>>>>> We could provide a tool to create the conf file. This
> > > tool
> > > > >> could
> > > > >> > > do
> > > > >> > >>>>>>>> the
> > > > >> > >>>>>>>> above things. This tool could be run during install
> > > with some
> > > > >> > >>>>>>>> default
> > > > >> > >>>>>>>> options or the user could run it later.
> > > > >> > >>>>>>> I guess the idea is as good as any.  However, any
> > > solution
> > > > >> that
> > > > >> > >>>>>>> becomes
> > > > >> > >>>>>>> part of the OpenHPI install is in the domain of the
> > > > >> distribution
> > > > >> > >>>>>>> packager, not the OpenHPI project itself.  In other
> > > words,
> > > > >> > > OpenHPI
> > > > >> > >>>>>>> gets
> > > > >> > >>>>>>> to define how the application works, but the
> > > distribution (Red
> > > > >> > > Hat,
> > > > >> > >>>>>>> SuSE, Debian) usually controls how OpenHPI is
> > installed.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> That said, the default "make install" for OpenHPI can
> > > > >> certainly
> > > > >> > > do
> > > > >> > >>>>>>> the
> > > > >> > >>>>>>> above steps.  It would then be up to the individual
> > > package
> > > > >> > > creators
> > > > >> > >>>>>>> (Red Hat, SuSE, Debian, etc.) to use the same or a
> > > similar
> > > > >> > > technique
> > > > >> > >>>>>>> during their installs.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>>> Please do share other ideas.
> > > > >> > >>>>>>> Building on the above idea, the weakness seems to be
> > > that the
> > > > >> > > Daemon
> > > > >> > >>>>>>> source code needs to contain the "default key" in
> > order
> > > to
> > > > >> read
> > > > >> > > the
> > > > >> > >>>>>>> password file, to get the user defined key.  Here is a
> > > > >> variation
> > > > >> > > on
> > > > >> > >>>>>>> the
> > > > >> > >>>>>>> idea:
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> - During OpenHPI build, a random key is generated.
> > > > >> > >>>>>>> This
> > > > >> random
> > > > >> > > key
> > > > >> > >>>>>>> becomes part of the daemon's binary code, but is never
> > > part of
> > > > >> > > the
> > > > >> > >>>>>>> source code.  Someone with enough time and patience
> > > could
> > > > >> derive
> > > > >> > > the
> > > > >> > >>>>>>> key
> > > > >> > >>>>>>> from the binary, but this would at least be difficult.
> > > > >> > >>>>>>> - The same key generated above becomes part of an
> > > encrypting
> > > > >> > >>>>>>> application
> > > > >> > >>>>>>> that is supplied with OpenHPI.  Again, it is only part
> > > of the
> > > > >> > > binary,
> > > > >> > >>>>>>> not the source code.
> > > > >> > >>>>>>> - During install, user-entered passwords can be
> > > encrypted (and
> > > > >> > > stored
> > > > >> > >>>>>>> to /var/lib/openhpi) using the encrypting application,
> > > much as
> > > > >> > > Mohan
> > > > >> > >>>>>>> has
> > > > >> > >>>>>>> proposed.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> Now some criticisms:
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> 1) For major distributions, the build code must be
> > > totally
> > > > >> > > automated.
> > > > >> > >>>>>>> No user interaction can be required.  So only a "make
> > > install"
> > > > >> > > that
> > > > >> > >>>>>>> generates it's own key can be used.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> 2) For some distributions, such as Debian, the output
> > > > >> > >>>>>>> of
> > > the
> > > > >> > >>>>>>> automated
> > > > >> > >>>>>>> build is generally publicly available.  It will be
> > > difficult,
> > > > >> in
> > > > >> > >>>>>>> these
> > > > >> > >>>>>>> distributions, for the generated key to avoid showing
> > > > >> > >>>>>>> up
> > > in
> > > > >> the
> > > > >> > > build
> > > > >> > >>>>>>> output.  (The simplest implementation would involve
> > > setting a
> > > > >> > > "make"
> > > > >> > >>>>>>> variable with the generated key, then passing the key
> > > into the
> > > > >> > > daemon
> > > > >> > >>>>>>> compile using "-D".  But this exposes the key in the
> > > build
> > > > >> > > output.)
> > > > >> > >>>>>>> Maybe there is a way to use a temporary file to hold
> > > > >> > >>>>>>> the
> > > key
> > > > >> > > instead.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> 2) Again, for major distributions, the install code
> > > > >> > >>>>>>> must
> > > be
> > > > >> able
> > > > >> > > to
> > > > >> > >>>>>>> be
> > > > >> > >>>>>>> totally automated.  People routinely do automated
> > > installs in
> > > > >> > > order
> > > > >> > >>>>>>> to
> > > > >> > >>>>>>> replicate systems.  So requiring a user to be at the
> > > keyboard
> > > > >> > > during
> > > > >> > >>>>>>> OpenHPI install may not be a viable option.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> 3) People must be able to make changes to the OpenHPI
> > > > >> > > configuration
> > > > >> > >>>>>>> file, then restart the daemon.  If they change the
> > > > >> > >>>>>>> file,
> > > how
> > > > >> do
> > > > >> > > they
> > > > >> > >>>>>>> get
> > > > >> > >>>>>>> new passwords into the system?  Do they have to
> > > > >> > >>>>>>> re-enter
> > > all
> > > > >> the
> > > > >> > >>>>>>> passwords?  Only the new ones?  How is this managed?
> > > > >> > >>>>>>> Is
> > > > >> there a
> > > > >> > > new
> > > > >> > >>>>>>> OpenHPI application that looks at the conf file,
> > > determines
> > > > >> what
> > > > >> > >>>>>>> passwords need to be stored, and asks the system
> > > administrator
> > > > >> > > for
> > > > >> > >>>>>>> these?  This seems to be a fairly complex application.
> > > What
> > > > >> if
> > > > >> > > there
> > > > >> > >>>>>>> are 50 different systems being managed?  Does the
> > admin
> > > have
> > > > >> to
> > > > >> > >>>>>>> enter 50
> > > > >> > >>>>>>> passwords?  Won't the sysadmin just keep these
> > > > >> > >>>>>>> passwords
> > > in a
> > > > >> > > file
> > > > >> > >>>>>>> for
> > > > >> > >>>>>>> reference, defeating the purpose of the exercise?
> > When
> > > the
> > > > >> > > passwords
> > > > >> > >>>>>>> change (since IT departments are fond of requiring
> > such
> > > > >> changes),
> > > > >> > >>>>>>> how do
> > > > >> > >>>>>>> the new passwords get entered?
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> Having criticized the ideas, let me offer that I think
> > > there
> > > > >> are
> > > > >> > >>>>>>> solutions to all the above.  They are mainly offered
> > to
> > > avoid
> > > > >> > > some
> > > > >> > >>>>>>> pitfalls as the code is implemented.  But I think
> > there
> > > will
> > > > >> need
> > > > >> > > to
> > > > >> > >>>>>>> be
> > > > >> > >>>>>>> a fairly substantial application to manage these
> > > passwords for
> > > > >> > >>>>>>> OpenHPI.
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> Lastly, having said all that, I wonder whether this
> > > > >> > >>>>>>> sort
> > > of
> > > > >> > >>>>>>> application
> > > > >> > >>>>>>> has already been developed.  Are there existing
> > > > >> > >>>>>>> "keyring
> > > > >> > > managers"
> > > > >> > >>>>>>> that
> > > > >> > >>>>>>> could be used instead of developing one specifically
> > > > >> > >>>>>>> for
> > > > >> OpenHPI?
> > > > >> > >>>>>>>
> > > > >> > >>>>>>> Best of luck,
> > > > >> > >>>>>>> Bryan Sutula
> > > > >> > >>>>>>>
> > > > >> > >>>>>>>
> > > > >> > >>>>>>>
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > >>>>>>> Live Security Virtual Conference Exclusive live event
> > > > >> > >>>>>>> will cover all the ways today's
> > > security
> > > > >> and
> > > > >> > >>>>>>> threat landscape has changed and how IT managers can
> > > respond.
> > > > >> > >>>>>>> Discussions
> > > > >> > >>>>>>> will include endpoint security, mobile security and
> > the
> > > > >> latest in
> > > > >> > >>>>>>> malware
> > > > >> > >>>>>>> threats.
> > > > >> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > >>>>>>> _______________________________________________
> > > > >> > >>>>>>> Openhpi-devel mailing list
> > > > >> > >>>>>>> Ope...@li...
> > > > >> > >>>>>>> https://lists.sourceforge.net/lists/listinfo/openhpi-
> > > devel
> > > > >> > >>>>>>
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > >>>>>> Live Security Virtual Conference Exclusive live event
> > > > >> > >>>>>> will cover all the ways today's
> > > security
> > > > >> and
> > > > >> > >>>>>> threat landscape has changed and how IT managers can
> > > respond.
> > > > >> > >>>>>> Discussions
> > > > >> > >>>>>> will include endpoint security, mobile security and the
> > > latest
> > > > >> in
> > > > >> > >>>>>> malware
> > > > >> > >>>>>> threats.
> > > > >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > >>>>>> _______________________________________________
> > > > >> > >>>>>> Openhpi-devel mailing list
> > > > >> > >>>>>> Ope...@li...
> > > > >> > >>>>>> https://lists.sourceforge.net/lists/listinfo/openhpi-
> > > devel
> > > > >> > >>>>>
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > >>>>> Live Security Virtual Conference Exclusive live event
> > > > >> > >>>>> will cover all the ways today's
> > > security
> > > > >> and
> > > > >> > >>>>> threat landscape has changed and how IT managers can
> > > respond.
> > > > >> > >>>>> Discussions
> > > > >> > >>>>> will include endpoint security, mobile security and the
> > > latest
> > > > >> in
> > > > >> > >>>>> malware
> > > > >> > >>>>> threats.
> > > > >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > >>>>> _______________________________________________
> > > > >> > >>>>> Openhpi-devel mailing list
> > > > >> > >>>>> Ope...@li...
> > > > >> > >>>>> https://lists.sourceforge.net/lists/listinfo/openhpi-
> > deve
> > > > >> > >>>>> l
> > > > >> > >>>>
> > > > >> > >>>>
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > >>>> Live Security Virtual Conference Exclusive live event
> > will
> > > > >> > >>>> cover all the ways today's
> > > security and
> > > > >> > >>>> threat landscape has changed and how IT managers can
> > > respond.
> > > > >> > >>>> Discussions
> > > > >> > >>>> will include endpoint security, mobile security and the
> > > latest in
> > > > >> > >>>> malware
> > > > >> > >>>> threats.
> > > > >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > >>>> _______________________________________________
> > > > >> > >>>> Openhpi-devel mailing list
> > > > >> > >>>> Ope...@li...
> > > > >> > >>>> https://lists.sourceforge.net/lists/listinfo/openhpi-
> > devel
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > >>> Live Security Virtual Conference Exclusive live event will
> > > > >> > >>> cover all the ways today's
> > > security and
> > > > >> > >>> threat landscape has changed and how IT managers can
> > > respond.
> > > > >> > > Discussions
> > > > >> > >>> will include endpoint security, mobile security and the
> > > latest in
> > > > >> > > malware
> > > > >> > >>> threats.
> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > >>> _______________________________________________
> > > > >> > >>> Openhpi-devel mailing list
> > > > >> > >>> Ope...@li...
> > > > >> > >>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > > > >> > >>
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > >> Live Security Virtual Conference Exclusive live event will
> > > > >> > >> cover all the ways today's security
> > > and
> > > > >> > >> threat landscape has changed and how IT managers can
> > respond.
> > > > >> > > Discussions
> > > > >> > >> will include endpoint security, mobile security and the
> > > latest in
> > > > >> > > malware
> > > > >> > >> threats.
> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > >> _______________________________________________
> > > > >> > >> Openhpi-devel mailing list
> > > > >> > >> Ope...@li...
> > > > >> > >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------
> > > > >> > > ------
> > > > >> > > Live Security Virtual Conference Exclusive live event will
> > > > >> > > cover all the ways today's security
> > > and
> > > > >> > > threat landscape has changed and how IT managers can
> > respond.
> > > > >> > > Discussions
> > > > >> > > will include endpoint security, mobile security and the
> > > > >> > > latest
> > > in
> > > > >> > > malware
> > > > >> > > threats.
> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > > _______________________________________________
> > > > >> > > Openhpi-devel mailing list
> > > > >> > > Ope...@li...
> > > > >> > > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > > > >> > >
> > > > >> > >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------------
> > > > >> > > Live Security Virtual Conference Exclusive live event will
> > > > >> > > cover all the ways today's security
> > > and
> > > > >> > > threat landscape has changed and how IT managers can
> > respond.
> > > > >> Discussions
> > > > >> > > will include endpoint security, mobile security and the
> > > > >> > > latest
> > > in
> > > > >> malware
> > > > >> > > threats.
> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > > _______________________________________________
> > > > >> > > Openhpi-devel mailing list
> > > > >> > > Ope...@li...
> > > > >> > > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > > > >> >
> > > > >> >
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------------
> > > > >> > Live Security Virtual Conference Exclusive live event will
> > > > >> > cover all the ways today's security
> > > and
> > > > >> > threat landscape has changed and how IT managers can respond.
> > > > >> Discussions
> > > > >> > will include endpoint security, mobile security and the latest
> > > in
> > > > >> malware
> > > > >> > threats.
> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> > _______________________________________________
> > > > >> > Openhpi-devel mailing list
> > > > >> > Ope...@li...
> > > > >> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > > > >>
> > > > >>
> > > > >>
> > > > >> ----------------------------------------------------------------
> > -
> > > > >> -
> > > ------------
> > > > >> Live Security Virtual Conference
> > > > >> Exclusive live event will cover all the ways today's security
> > and
> > > > >> threat landscape has changed and how IT managers can respond.
> > > > >> Discussions
> > > > >> will include endpoint security, mobile security and the latest
> > in
> > > > >> malware threats.
> > > > >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > >> _______________________________________________
> > > > >> Openhpi-devel mailing list
> > > > >> Ope...@li...
> > > > >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > >
> > > --
> > > Mohan <mo...@fc...>
> > >
> > >
> > > ---------------------------------------------------------------------
> > -
> > > -
> > > -------
> > > Everyone hates slow websites. So do we.
> > > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > > for free today:
> > > http://p.sf.net/sfu/appdyn_d2d_feb
> > > _______________________________________________
> > > Openhpi-devel mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > 
> > -----------------------------------------------------------------------
> > -------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________
> > Openhpi-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> > 
> > -----------------------------------------------------------------------
> > -------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics Download AppDynamics Lite
> > for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________
> > Openhpi-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Openhpi-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel