Hi Mohan,
Introduction of new mandatory dependency produces a lot of worries.
One more note:
What about encrypting only specific handler part of openhpi.conf?
On handler-level it is not so problematic to introduce new dependencies.
Some common code can be put into optional shared library.
(like libopenhpi_ssl or libopenhpi_snmp).
Anton Pak
On Mon, 25 Feb 2013 20:22:59 +0400, Mohan <[email protected]> wrote:
> 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-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
>> >>
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> 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
------------------------------------------------------------------------------
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
