Hi Anton, Thanks a lot for the review.
I will make the changes, HAVE_ENCRYPT, openhpi.spec etc, next week. So far we have not build successfully on solaris. So far we have been facing the dependency problems. Hope to create a mail with all the problems we faced next week. That could give the text for the bug. Mohan On Fri, 2013-04-05 at 09:29 +0400, Anton Pak wrote: > 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 -- Mohan <[email protected]> ------------------------------------------------------------------------------ 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
