Security of data on MLS computers

[wdoctor-p40]

So it sounds like white listing the local computer is probably the best short term option for an internet attached MLS system. Chatting with the stake folks and other posts on this forum, it sounds like the pix501 is the standard firewall in use, which only has a single "inside" interface, so making additional security domains wouldn't be possible without different hardware. As I dug around more on this site I thought it was interesting that church policy and guidelines for computer use (dated march 27 2005 linked from this site) requires any computer used for family history and MLS, must store the MLS database on an external drive when not in use.... seems like someone appreciated the implications of storing member information on a computer that has public internet access (and of course many more people would have access to the physical computer).

Hopefully these security considerations can be incorporated into future MLS software and network standards. It would be good for example to remove the admin requirement for MLS for starters and hopefully consider ways to better separate the MLS data from general use access. There are many cost effective options out there, especially if we move to open source solutions.

Thanks for the feedback!

Side note about facebook ... it looks like I saw that in the IE drop down, and when I double checed it wasn't in the actual cache, so maybe that site may have been typed in the browser, but was actually filtered at HQ.

[techgy]

If you refer to the Church instructions dated March 2005 regarding the use of the Internet on Church computers, you will see that they discourage the integration of the Internet on any computer that contains the MLS system.

If it IS necessary, then precautions are taken with additional equipment (firewalls, etc) to secure the equipment.

Our stake takes the approach, and I support it, that the Internet is NOT to be placed onto any computer that has the MLS on it. Better safe than sorry.

Techgy

[russellhltn]

Note that the Desktop 5.5 install instructions comes with a Internet Use Policy. A later email to the STS around the end of January 2007 clarified things. Clearly there have been changes since March 2005.

Rumor is you'll see more changes either this quarter or next.

[AdrianLP-p40]

Plus, unless you were actually friends before hand, I doubt someone would accept the friend invitation out of nowhere from their old Ward Clerk.

I would. Why would others reject a friend invitation, unless they knew it was spam.

You humans are so funny.
return 0;

[kd7mha]

I haven't had a chance to try this yet,

1. change the clerk account access to regular user
2. create a shortcut with
RUNAS /savecred /user:<UserName> "c:\program files\mls\mls.exe"

using an administrative account this way will prevent just anyone from having admin rights but should still allow MLS to run.

note: the path for MLS above is from memory and may not be correct

[AdrianLP-p40]

Where is setuid root when you need it

[russellhltn]

I haven't had a chance to try this yet,

1. change the clerk account access to regular user
2. create a shortcut with
RUNAS /savecred /user:<UserName> "c:\program files\mls\mls.exe"

using an administrative account this way will prevent just anyone from having admin rights but should still allow MLS to run.

note: the path for MLS above is from memory and may not be correct

Two problems. First, RUNAS doesn't support passwords. So the MLS users will have to know the password for the username used. (But you could use CPAU. But be sure to check the warranty first. )

Second, there's a good possibility that somewhere in the process, something will spawn off that will inherit the local user's rights instead of the RUNAS user and since it won't have the proper privileges. I'd love to restrict the users, but I don't want to have to run around fixing a update that failed to take because of this. And there's no way of testing updates because each one is different.

[aebrown]

I haven't had a chance to try this yet,

1. change the clerk account access to regular user
2. create a shortcut with
RUNAS /savecred /user:<UserName> "c:\program files\mls\mls.exe"

using an administrative account this way will prevent just anyone from having admin rights but should still allow MLS to run.

note: the path for MLS above is from memory and may not be correct

While I appreciate your efforts to find a more secure way to configure MLS computers, I would note that the Desktop 5.5 instructions state:

Log on to the computer, using the user name CLERK and the password *********. This is the computer administrator account. It is also the only account to be used to run MLS. Please do not allow this username or password to be changed.

Your proposal causes MLS to be run using a different account, which is contrary to the stated policy. So it may be a reasonable option for the Church to consider and perhaps even implement, but no clerk should be implementing this.

[jdlessley]

I have always had the concern about running any computer in a user profile that has administrator privileges when connected to any network - and most especially the internet. Security is difficult enough without leaving your front door wide open.

While MLS version 2.8 and earlier versions require administrative privileges to work; I don't see why. There are plenty of commercial programs and utilities out there that require administrative privileges to do perform their functions yet they are run quite successfully from any account with lesser privileges. Only the install of that program must be performed from within an administrator account. Antivirus and other security programs are a case in point.

Does anybody know if there is any development push or programming update to MLS in the works that will permit it to function on a more restricted user account?

[russellhltn]

Does anybody know if there is any development push or programming update to MLS in the works that will permit it to function on a more restricted user account?

I don't know, but Vista compliance may force an issue. From what I'm hearing, Vista does NOT like data being stored in the Program Files directory. (It shouldn't have been done from Win2k on, but now MS is getting a bit nasty about it by remapping writes to different locations.)