This is related to the following issue: https://issues.apache.org/jira/browse/VCL-562
I created this issue as a result of a security situation we had a couple years ago. A staff member had updated several images including some base images. In the process of doing so, additional user accounts were manually added to the images. I assume the accounts were used to test the default user profile. Some of the accounts had the weakest password imaginable. The accounts were not deleted prior to capturing the image. VCL will not alter existing accounts in the image except for accounts used for a reservation. In addition, VCL will not automatically enable the OS's firewall if it was disabled prior to capture (something we should consider). As a result, images could be loaded with the firewall disabled containing user accounts with bad passwords. To make matters worse, derivative images were captured from the base images causing the problem to spread. The imagerevisioninfo table gets updated when a Windows image is loaded under certain circumstances. One purpose is to help identify image revisions which may have additional user accounts which may have bad passwords. The backend code uses the 'windows_ignore_users' and ' windows_disable_users' entries in the variable table to determine this. 'windows_ignore_users' should contain a comma-separated list of user account names which are known to be OK. The schema currently contains 'Administrator,cyg_server,root,sshd,Guest'. If the backend code sees any users other than these or the reservation user(s), it will add or update an entry in imagerevisioninfo. If you have software in an image which requires an additional user such as 'sasuser', it would report this. To reduce the false positives reported in the table, the windows_ignore_users variable should be extended to include the known-good user names. Nothing is done to an account in the image which simply is not included in the list of 'windows_ignore_users'. 'windows_disable_users' should contain a comma-separated list of known-bad user names. The list is empty in the schema by default. If the backend finds a user account in an image revision matching 'windows_disable_users', a long random password is set on the account and the account is disabled. The state of the firewall is also checked. If the backend finds an image revision with the firewall disabled, a imagerevisioninfo entry will be added or updated regardless of the user accounts it finds in the image revision. I didn't want to add additional columns to imagerevision becuase it's likely that imagerevisioninfo could occasionally be purged of certain entries. For example, when you get a bunch of false positives and add an account name to 'windows_ignore_users'. The false-positives could be purged. In this case, it's safer and easier to clear part of imagerevisioninfo rather then modifying entries in imagerevision. So currently, the table would only be used by examining it directly in the database, checking images, and updating the variables accordingly. Features could be added to the frontend to incorporate its functionality. In the future, I could imagine this table being extended. Support for checking Linux images could be added, though I don't see an urgent need at the moment. Software inventory could also be added. This would probably be implemented via one or more other tables but the idea is similar. -Andy On Thu, Jan 29, 2015 at 8:42 AM, Josh Thompson <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Just wondering - what the imagerevisioninfo table used for? > > Thanks, > Josh > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlTKONQACgkQV/LQcNdtPQMWDACbBFtLNyat/cOn4mR/7Xyo3gLY > bYkAni6w521CvHJ7L+VYB//5k4Q0hr03 > =3frs > -----END PGP SIGNATURE----- > >
