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.
o) Is gcrypt a well-known libs? Is it widely recognized in embedded domain?
o) What about Solaris and FreeBSD variants?
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?
o) That uuid - is it hardware-dependent? Will it change if I replace some
peaces of
hardware?
o) How to prevent decryption if a bad guy has access to the config and to
the uuid?
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
