Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Article Discussions
»
Article Discussions by Author
»
Discuss Content Posted by Brian Kelley
»
Restricting SecurityAdmin on SQL Server...
13 posts, Page 1 of 2
1
2
»»
Restricting SecurityAdmin on SQL Server 2005/2008
Rate Topic
Display Mode
Topic Options
Author
Message
K. Brian Kelley
K. Brian Kelley
Posted Wednesday, September 01, 2010 8:10 PM
Keeper of the Duck
Group: Moderators
Last Login: Yesterday @ 1:55 PM
Points: 6,584,
Visits: 1,789
Comments posted to this topic are about the item
Restricting SecurityAdmin on SQL Server 2005/2008
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of
Introduction to SQL Server: Basic Skills for Any SQL Server User
|
Professional Development blog
|
Technical Blog
|
LinkedIn
|
Twitter
Post #979248
SQLRNNR
SQLRNNR
Posted Wednesday, September 01, 2010 8:47 PM
SSCoach
Group: General Forum Members
Last Login: Monday, May 20, 2013 1:07 PM
Points: 18,733,
Visits: 12,332
Thanks for demonstrating this vulnerability.
Jason
AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008
SQL RNNR
Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #979253
clementhuge
clementhuge
Posted Thursday, September 02, 2010 1:31 AM
SSC Journeyman
Group: General Forum Members
Last Login: Sunday, May 19, 2013 3:27 PM
Points: 89,
Visits: 285
Excellent article!
Clement
Post #979329
wmt
wmt
Posted Thursday, September 02, 2010 3:51 AM
Valued Member
Group: General Forum Members
Last Login: Yesterday @ 5:12 AM
Points: 63,
Visits: 699
Excellent, informative and slightly scarey - all at once!
Post #979379
Rob-792003
Rob-792003
Posted Thursday, September 02, 2010 6:44 AM
Forum Newbie
Group: General Forum Members
Last Login: Sunday, January 20, 2013 3:25 PM
Points: 1,
Visits: 24
Thanks for raising the awareness of this behavior!
Post #979475
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Thursday, September 02, 2010 10:04 AM
SSC-Dedicated
Group: Administrators
Last Login: Today @ 4:46 PM
Points: 31,433,
Visits: 13,745
Excellent article and I noticed this on your blog recently and was concerned.
It seems like this is a bug since essentially the securityadmin role now has no real meaning. You might as well be a sysadmin or not have this at all.
I would love to see a server level role that allowed someone to add a login, and a user for a specific database (s) only. That's the type of permissions that I often want to hand over to another person.
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #979676
croberts 36762
croberts 36762
Posted Thursday, September 02, 2010 10:50 AM
SSC-Addicted
Group: General Forum Members
Last Login: Monday, April 30, 2012 12:36 PM
Points: 404,
Visits: 442
Excellent article.
I have one question about the workaround. If a person has SecurityAdmin, could they give themselves permission to alter the LimitSecurityAdmin trigger?
Chris
Post #979713
K. Brian Kelley
K. Brian Kelley
Posted Thursday, September 02, 2010 11:09 AM
Keeper of the Duck
Group: Moderators
Last Login: Yesterday @ 1:55 PM
Points: 6,584,
Visits: 1,789
croberts 36762 (9/2/2010)
Excellent article.
I have one question about the workaround. If a person has SecurityAdmin, could they give themselves permission to alter the LimitSecurityAdmin trigger?
No. As a securityadmin, you cannot assign permissions to your own login. But that makes me think there's another attack vector that I need to test.
Steve, I would agree with you, but Microsoft was adamant this isn't to be considered a bug. And to consider securityadmin = sysadmin. However, I know folks who've converted and have controls in place assuming securityadmin is limited, so they're stuck in the middle. I wish they would consider it a bug, too, because as Chris just brought up, there are surely more attack vectors.
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of
Introduction to SQL Server: Basic Skills for Any SQL Server User
|
Professional Development blog
|
Technical Blog
|
LinkedIn
|
Twitter
Post #979727
timothyawiseman
timothyawiseman
Posted Thursday, September 02, 2010 12:16 PM
Right there with Babe
Group: General Forum Members
Last Login: Thursday, February 14, 2013 12:01 PM
Points: 743,
Visits: 900
It is definitely good to have this pointed out since a lot of people do not realize it, and this was well written and clear.
From my standpoint, it tends to be irrelevant. Even if they cannot take full control of the server someone with even the SQL Server 2000 limited version of SecurityAdmin could cause so much mischief I would never hand it to someone I would not trust with full control server. At that point, I see the value of it in keeping honest people honest. Even if they know how to bypass it easily, they are faced with the fact that they are bypassing it. This reminds them that they are doing something that is properly in someone else's domain. For an trustworthy person, that is enough; for a non-trustworthy person even limited SecurityAdmin is far too much power.
---
Timothy A Wiseman
SQL Blog:
http://timothyawiseman.wordpress.com/
Post #979799
K. Brian Kelley
K. Brian Kelley
Posted Thursday, September 02, 2010 12:21 PM
Keeper of the Duck
Group: Moderators
Last Login: Yesterday @ 1:55 PM
Points: 6,584,
Visits: 1,789
timothyawiseman (9/2/2010)
It is definitely good to have this pointed out since a lot of people do not realize it, and this was well written and clear.
From my standpoint, it tends to be irrelevant. Even if they cannot take full control of the server someone with even the SQL Server 2000 limited version of SecurityAdmin could cause so much mischief I would never hand it to someone I would not trust with full control server. At that point, I see the value of it in keeping honest people honest. Even if they know how to bypass it easily, they are faced with the fact that they are bypassing it. This reminds them that they are doing something that is properly in someone else's domain. For an trustworthy person, that is enough; for a non-trustworthy person even limited SecurityAdmin is far too much power.
Agreed, to a point. From a Principle of Least Privilege perspective, even if you trust someone to be a sysadmin, but they only should be doing the work of a securityadmin, you give them securityadmin. Only the permissions to do the job - no more, no less. And that's where this really busts audit controls.
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of
Introduction to SQL Server: Basic Skills for Any SQL Server User
|
Professional Development blog
|
Technical Blog
|
LinkedIn
|
Twitter
Post #979807
« Prev Topic
|
Next Topic »
13 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.