Bryan Sutula píše v St 05. 09. 2012 v 19:37 -0600: > 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.
I haven't followed the whole discussion, but there are dozens (my guess, I personally know only some of them) of projects in the distributions that store some passwords in plaintext in their configuration files that are readable by root. What is usually done is that the files are not readable by regular users by using 0600 permissions with an own user/group. Also SELinux helps here where a confined application running as root can access only files that are allowed in its policy, this helps for situation where eg. even a hacked web server can't read anything than what's under /var/www/html. Also remember that having physical access to a server makes any security measures obsolete (simplified). If there is a real demand for increasing security it should be discussed with security experts, so the result is then certifiable etc. I can provide contact withing Red Hat if needed. With regards Dan > 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
