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 -- 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
