Screen Saver Password Protection - Security Flaw

Question

Although I have always felt OS X has been a solid and secure operating system, there continues to remain one painful, and blatant security flaw. I keep thinking that Apple will address the issue, but they certainly haven't done so thus far.
Explanation:
With any good security policy, and in any secure environment, there will always be a need to "lock" (password protect) a system when not in use. That is, after 'X' period of time, the user interface is password protected so as not to allow access to the system while not in use. This is probably the most common and fundamental security measure in any environment. However, Apple's (GUI) password protection falls short in a number of ways. The only current method of password protecting the user interface is through the Screen Saver. Although at a glance it appears functional, it is a poor design and is easy to disable.
The screen saver configuration lies within two files; the ~/Library/Preferences/com.apple.dock.plist and ~/Library/Preferences/ByHost/com.apple.screensaver.<variable>.plist. It is especially important to note that both of these files are located in the users home folder, which gives them full access to the configuration files. There is absolutely nothing preventing a user from deleting these files, and thus, disabling the only mechanism to password protect the user interface. Giving the user the ability to disable or remove ANY security related configuration is a poor design.
Now initially we thought we had a solution by setting the user immutable flag on the ByHost screen saver plist using chflags. This would still allow user access, but would prohibit them from deleting the ByHost plist. Well, it sounded good in theory. However, if ~/Library/Preferences/com.apple.dock.plist is deleted, you can say goodbye to your password protected screen saver, despite locking the screen saver plist. So naturally the idea occurred to me to set the user immutable flag on ~/Library/Preferences/com.apple.dock.plist. This works, but makes it impossible to modify the Dock. Needless to say, if the Dock can't be modified, there's no point in even having it.
Now that isn't the only thing wrong with the screen saver password protection. You would expect that an administrator could unlock a users (password protected) screen saver, but you would also assume that the user was logged off as a result. Not in this case... If an admin unlocks a password protected screen saver for a user, they are now logged in as that user and have access to everything the user was doing when it was locked (email, spreadsheets, confidential information... anything). This is not the preferred method. If for some reason an admin needs to unlock a password protected screen saver, it should log off that user, not allow access to the user's session.
Finally, the biggest flaw yet. With a recent update, the password protection doesn't even work, as indicated by several people in the following threads.
http://discussions.apple.com/thread.jspa?messageID=2706417&#2706417
http://discussions.apple.com/thread.jspa?messageID=1950444&#1950444
http://discussions.apple.com/thread.jspa?messageID=2648700&#2648700
I have personally seen this issue while developing our corporate OS X image. Despite any fix or workaround, the simple fact that this has occurred is disturbing. ...As if the design wasn't bad enough, it now has the potential to stop working entirely.
Now don't get me wrong, I love OS X and prefer to work on it over any other operating system. Nonetheless, the current design for the "screen lock" is inadequate at best. For a large enterprise environment with stringent security requirements, it's far from sufficient. My hope in posting this is that someone from Apple acknowledges the design flaw and incorporates a more effective solution into the next OS.
MacBook   Mac OS X (10.4.6)  

Answer 1

One thing I forgot to mention is that "Workgroup Manager.app" is a part of the "Server Admin Tools" which can be downloaded free from Apple. Although it seems to be primarily intended to be used to configure OS X Server from an OS X Client machine, many of its functions can be used to configure the OS X Client machine itself, in the complete absence of OS X Server. Unfortunately, the 'mcx_settings' aren't really "image friendly" - as far as using them on OS X client is concerned, they are something that seem to need to be applied to user accounts individually (although it is possible to copy all of the settings at once so it isn't necessary to go through the whole configuration process for each setting for each user). I have tried tinkering and applying them to groups, but group members don't seem to automatically be restricted (I may be missing something). The "tools" are available here:
http://www.apple.com/support/downloads/serveradmintools104.html
I don't know if it would be any better than the screen saver "hot corner", but there is an option to lock the screen from the "Keychain Access" menu extra, which can normally be enabled through "/Applications" > "Utilities" > "Keychain Access.app", from its "Preferences". This setting is then stored in the "com.apple.systemuiserver.plist" file (ie independent of the "Dock"), but could in principle be controlled from 'mcx_settings' as well. The level of control seems to be incomplete - the user can still drag the item off of the menu bar, but it returns during the next login. However, it does provide convenient access to a method to lock the screen and keychains, and has a nice "padlock" icon so that its function is obvious. It is also potentially possible to assign a two-step keyboard shortcut to the "Lock Screen" item, but it would be somewhat less convenient than a direct key combo...
One other note regarding the "admin" user's ability to unlock the screensaver. The configuration file allowing the "admin" user to do this is "/etc/authorization", under 'system.login.screensaver'. Currently, the "rule" is set to 'authenticate-session-owner-or-admin'. Changing it to 'authenticate-session-owner' would be expected to remove the "admin" user's ability to unlock the screensaver, and if "Fast user switching" is available, the "admin", being unable to authenticate, should be able to switch to the "login window" from the authentication dialogue. I haven't tested this at all in "Tiger", but in "Panther", there was apparently a problem with it (which is why it had slipped my mind since at the time it was rejected as a viable option) - the person who posts here as "LittleSaint" had mentioned some problem with user logins when set up that way but I don't remember what it was, and so can't test if it has been fixed in "Tiger" (not very reassuring, and I apologize). And again, this is a setting that an "admin" would be able to reverse for themselves. Also, should "Fast user switching" become disabled for some reason, and the screen saver kicks in and the user isn't available, it might be a hassle to get back into the machine (it might be possible to do something over ssh). Nevertheless, it might be something to look in to.