My company policy states I must put all passwords in a password safe shared with management. Is this secure?
None of the reasons you've given are valid reasons for escrowing your password. There's only a couple valid reasons for escrowing any sort of "authenticator" information. A couple others have touched on these, but I'll try to clarify a bit.
Encryption Keys: It makes absolute sense for the organization to have access to escrow copies of your encryption keys. After all, the data you're encrypting (provided you're only using your company's encryption for work purposes, of course) is their data in the end anyway. So, they need to retain access to that data in the event you lose your key or you are separated from the company. However, the encryption key should not be the same key you use for digital signatures. Also, they should not have actual access to your authenticator - the passcode you use for the key. Instead, they should have their own escrow key that works with their authenticator to decrypt your data.
Failsafe Accounts: It also makes sense that the organization should have backup copies of credentials necessary to access an Administrator-level account in the event the System Administrator's own account is locked out, or they depart the company. However, the credentials should not be for the System Administrator's own account. They should be for a local system account whose sole purpose is for emergency use. To that end, the account should also never be used for non-emergencies and its usage should be closely monitored and alerted. Traditionally, credentials for accounts like these are sealed in tamper-evident envelopes and stored in a secure, physical vault. It's conceivable that there may be digital equivalents, but I personally wouldn't trust those without a thorough review.
There's two big reasons why it's a bad idea for management to have your password. The first reason is potentially very bad for you, as it could end up causing otherwise unnecessary work for you if things go wrong. However, the second actually turns this around and makes it potentially worse for the company than it is for you if things go really wrong.
Potential For Abuse: The obvious one - managers now effectively have unrestricted access to the systems, regardless of whether they should, with the same privileges you have. Most simply this means that the managers may leverage this to do things on the system that they otherwise should not be doing. This also leaves the potential for them to bypass your position whenever they want to rush a particular change along without following standard procedure.
Loss of Non-Repudiation: Once someone else has your credentials - and, especially in a case like this where it can be proven they do - they can impersonate you on any systems where those credentials are valid. This makes it difficult to definitively prove that any actions taken by your account were actually taken by you. If a manager does decide to use your account, and ends up royally screwing up the system, it won't be very easy to use you as a scapegoat even though your account is in the logs. Worse for the company is, if you do something to royally screw up the system while your managers have your password, they'll have a harder time proving that it was actually you that did it.
TL;DR: There's no good reason I can think of for management to have any of your passwords. As for the reasons they've given:
- "If you forget your password..." another System Administrator can reset it for you. Or, management can "break the glass" on the emergency account (see "Failsafe Accounts" above) and do it themselves.
- "If you turn evil..." again you can be locked out by another System Administrator, or the emergency account.
The first reason (give you your password back in case your forgot it) is quite weak: if you forgot your password, then it is not a good password, and it would make more sense to let you reset it by choosing a new password. The second reason is totally bogus: if they cannot "lock you out" without knowing your password, then they should fire their sysadmin ASAP. He doesn't know how to right-click.
Most probably, your managers want to have the feeling of being in control and to actually manage at very close range. Possibly, they might just want to prevent the employees from using swear words as passwords because it could offend some deity somewhere. Either way, this does not highlight the competence of whoever came up with that security policy in a very positive way.
Edit: though, the policy would make some kind of sense for passwords which are used for encryption, e.g. when you protect a Zip archive with a password. That kind of password cannot be reset, and losing the password (you forget it, or you become "unavailable" due to having been struck by a bus) implies losing the data. In that case, escrowing the password makes sense. But for an authentication password, no, that's a stupid policy.
No, it is not a good idea. Thomas explained why it doesn't achieve its own goals, but it is worse than that.
Consider what happens when a rogue employee misbehaves causing damage to the company.
During the trial, you are subpoenaed to testify about logs showing that it was the employee who caused the damage, and are asked who else could log in as this employee. You truthfully answer that anyone with access to the safe including all of management could log in as that employee and your logging systems would be none the wiser.
Anything that blurs the distinction between actor and authenticating credentials seriously undermines the company's ability to use access logging to discourage misbehavior or recoup damages.
Managers often hand out passwords to subordinates when an IBAC system fails to explicitly handle delegation, but this is the reverse of that case, where the blurring affects the credentials of the much larger group of lower-level employees.