Hi Mohan!
Thank you for the patch! It looks very good.
I have only few small comments:
- Suggest using HAVE_ENCRYPT (or something like this) instead of
_GCRYPT_INCLUDED.
- OHPI_ is a better prefix for new constants. They are not recognized by
SAF anyway.
- Could you also fix openhpi.spec for RPM build in order to include gcrypt
dependency?
What kind of issues do you get on solaris?
May be we should create a bug ticket for that.
Anton Pak
On Fri, 05 Apr 2013 04:16:25 +0400, Mohan <[email protected]> wrote:
> Uploaded a new patch with changes so that --enable-encryption is added
> as an option. By default this option is turned off(No). The hpicrypt is
> built and the utils library is linked against gcrypt only if it is
> present or user explicitly asks for it. Otherwise it is turned off.
>
> Since this is similar to crypto it should not cause any problems in the
> export regulations. We also trying to find out more.
>
> We tried to build openhpi on solaris, but even the openhpi-3.2.0 does
> not build on it. We are trying to resolve the problem. If some one with
> solaris knowledge could help that will be great.
>
> Thanks
> Mohan
>
>
> On Tue, 2013-02-26 at 21:19 +0400, Anton Pak wrote:
>> 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
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
