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
