By the way,
Are there any active US export regulations about software with
cryptography?
Anton Pak
On Tue, 26 Feb 2013 19:27:02 +0400, David Mckinley
<[email protected]> 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:[email protected]]
>> Sent: Monday, February 25, 2013 5:11 PM
>> To: [email protected]
>> 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:[email protected]]
>> Sent: Monday, February 25, 2013 9:51 AM
>> To: [email protected]
>> 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:[email protected]]
>> > Sent: Monday, February 25, 2013 10:23 AM
>> > To: Anton Pak
>> > Cc: [email protected]
>> > 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 <[email protected]> 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, [email protected] 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
>> > > >> <[email protected]>
>> > > >> > 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:[email protected]]
>> > > >> > > Sent: Friday, September 07, 2012 2:37 PM
>> > > >> > > To: [email protected]
>> > > >> > > 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
>> > > >> > > <[email protected]>
>> > > >> > >> wrote:
>> > > >> > >>
>> > > >> > >>> On 09/07/2012 12:36 PM, [email protected] 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, [email protected] 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, [email protected]
>> > 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
>> > > >> > >>>>>>> [email protected]
>> > > >> > >>>>>>> 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
>> > > >> > >>>>>> [email protected]
>> > > >> > >>>>>> 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
>> > > >> > >>>>> [email protected]
>> > > >> > >>>>> 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
>> > > >> > >>>> [email protected]
>> > > >> > >>>> 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
>> > > >> > >>> [email protected]
>> > > >> > >>> 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
>> > > >> > >> [email protected]
>> > > >> > >> 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
>> > > >> > > [email protected]
>> > > >> > > 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
>> > > >> > > [email protected]
>> > > >> > > 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
>> > > >> > [email protected]
>> > > >> > 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
>> > > >> [email protected]
>> > > >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >
>> > --
>> > Mohan <[email protected]>
>> >
>> >
>> > ---------------------------------------------------------------------
>> -
>> > -
>> > -------
>> > 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
>> > [email protected]
>> > 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
>> [email protected]
>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
