January 17, 2003 at 2:47 pm
Hi Folks,
From http://www.eweek.com/article2/0,3959,743410,00.asp I downloaded Microsoft-provided documentation and scripts. There are lot of REVOKE done to the PUBLIC role. It really got my nerves. I usually apply all SQL patchs from MS, and all recomended patchs from sqlsecurity.com. MS is proud with the number attacks (over 82,500 attacks) that the test box withstood; I ain't proud with the current setup of my box since the REVOKE things not done to the PUBLIC role. How are you guys doing with this issue? I really don't like to use a s/w and look all over public places for more additional security tips.
January 17, 2003 at 6:16 pm
Microsoft is aware of the issue and to be perfectly honest, security has often been thought of in hindsight. This isn't just true of Microsoft products, but the whole gamut. One of the comments from one of the security forums I'm a member of discussed that we're only now seeing the first generation of security-conscious applications. This was in regards to a post about "strike back" technology.
Microsoft has also made the public statement that Yukon is supposed to be secure out of the box. They've delayed Yukon to ensure this is the case. I say give them the benefit of the doubt. After all, Oracle made the claim that 9i was "unbreakable" until David Litchfield tore it apart.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
January 17, 2003 at 6:25 pm
We are a pure MS shop. I don't blame MS for the security holes since no vendor could say their products are perfect (acttually Oracle did!). I just wonder if someday my box is attacked because I didn't spend enough time to surf the net for more security tips not from MS.
January 17, 2003 at 6:37 pm
Revoking public role predominantly prevents investigation by users who have already passed the first layer, authentication. In other words, they already have valid access to SQL Server.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 11, 2003 at 5:51 pm
It makes sense to revoke unnecessary permissions granted to the public role. I may be wrong, but I don't remember reading anything about this in the MS SQL Server 2000 Security White Paper.
I thought that was rather odd.
February 12, 2003 at 12:47 am
There are a few issues:
1) Some applications (Microsoft Access and ODBC Data Source Administrator come immediately to mind) query against the system tables. Sysdatabases and syscharsets come immediately to mind as two such system tables that get queried.
2) There are numerous system stored procedures that provide the same information and with ownership chains in place, you'd have to revoke permission on the stored procs as well. Again, some apps use these. Two such stored procedures are sp_tables and sp_columns.
3) Information schema views don't have the luxury of using ownership chains. As a result, revoke public access to a system table and you break the information schema view that queries against it.
4) Permissions can't be assigned directly to a fixed server role. Also, for some of the fixed database roles permission is required on system tables in master. This means one of the following leaving permissions alone, adding affected users to master and giving them rights to the table(s) in question, or simply not using these other fixed roles.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply