Do you check for TRUSTWORTHY databases as part of your security audits?
7December 30, 2015 by Kenneth Fisher
I ran a twitter poll the other day Do you check for databases with trustworthy turned on when you do security audits?
I wasn’t surprised (although a little disappointed) that out of the 9 people the answered only one person was, and of the rest 5 didn’t even know what TRUSTWORTHY is. I even had one person ask me later. That’s somewhat scary because under the right circumstances if you give me a database with TRUSTWORTHY turned on I can take over your instance. I’m NOT going to show you how but it isn’t terribly difficult.
So what is the TRUSTWORTHY database property? If turned on then SQL Server trusts the contents of the database. Not terribly clear if you ask me.
I haven’t been able to find a whole lot out about all of the details of it but here are a few that I do know.
- It will allow you to impersonate server level permissions. This has some scary potential if you aren’t careful about it.
- If you restore or attach a database this setting is automatically turned off.
- msdb is the only database with TRUSTWORTHY automatically set on.
Because of the potential to use instance level security from inside of the database you need to be particularly careful when granting access to one of these databases. Like I said above, with the right access (and one or two other things) a user in a trusted database can take over the instance.
So my recommendation is that when you are doing a security audit you should include a check for TRUSTWORTHY databases (sys.databases.is_trustworthy_on = 1). For any TRUSTWORTHY database you find you want to carefully check the permissions of the database owner and those of the users of the database.
SELECT sys.server_principals.name as Owner, sys.databases.* FROM sys.databases LEFT OUTER JOIN sys.server_principals ON sys.databases.owner_sid = sys.server_principals.sid WHERE is_trustworthy_on = 1
SQL Studies 
Sound advice!
Also keep in mind, you may break things when you turn it off ( e.g. Service broker ) ! So it’s not _only_ a user authority thing.
You are absolutely right. And msdb HAS to have trustworthy for a number of reasons. I’m just advocating being aware of which DBs have TRUSTWORTHY turned on and being particularly careful of who you give elevated rights (impersonation, db_owner etc) on those DBs.
[…] Kenneth Fisher asks if you check TRUSTWORTHY settings on your databases: […]
As a part of my nightly maintenance procedure, I run the following code that now incorporates your trustworthy check:
It shows me if a database suddenly appears somewhere other than where it should be, the recovery model, and trustworthiness. I also look at the status code as it should be either 65536 or 65544 for my environment: any other value and I know that I need to look at it.
I know sysdatabases is deprecated and will eventually be removed, I haven’t taken the time yet to rewrite the code for the more current sources.
Thanks for the post! Very important information to keep track of!
Glad I could help! Great script. Don’t forget that msdb is supposed to be trustworthy 🙂
Thanks for sharing this tip. I should run some checkup on our database if there’s some security issues. Its been two months since the last time check up.
Yea, with all the hype about recovery planning (don’t get me wrong, super, super important) people tend to forget that you have to do security checkups every now and again too 🙂