Jeff Moden (3/24/2013)
opc.three (3/24/2013)
Michael L John (3/21/2013)
I stand corrected.BUT I also stand by the statement because unfortunately poor security seems to be the norm. It seems as if DBA's are so busy with everything else that security is overlooked.
I will amend the statement to be:
"xp_cmdshell CAN be a security risk"
Nope, you had it right the first time!
Leaving xp_cmdshell enabled exposes the system to the option for people in the sysadmin Role to access the server's file system using someone else's credential, namely the SQL Server service account. That leaves a gaping hole in the auditability of a system, which for me constitutes a security exposure and a threat to the system.
I would leave xp_cmdshell disabled and put up every roadblock and auditing option (e.g. Policy Based Management) to keep it disabled, and log attempts to enable it. It's just not worth it. There are so many better options out there than to allow cmd-shell and file system access through your database engine.
He didn't have it right the first time and you know it.
Not even for a second. I disagree, wholeheartedly, and you must know that by now we have reached an impasse on this topic.
Turning off xp_CmdShell is not what proper security is about.
Layering is key when securing a system and leaving xp_cmdshell enabled is one less layer of protection, regardless of how feckless you think it may be. You have to consider that sometimes (some would argue most of the time) you are not protecting from some faceless external hacker you are protecting your data and system from people who have access to it every day. I guess you are blinded by the idea that since 'any sa can bypass any roadblock' that we should not put up any roadblocks or layer our protections and auditing in any way, and I think that is a dangerous mindset when it comes to securing a system.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato