Laurentiu Cristofor's blog @microsoft.com : basic SQL Server security concepts

Basic SQL Server Security concepts: ownership, CONTROL, TAKE OWNERSHIP

lcris — Wed, 12 Aug 2009 01:39:00 GMT

I realized today that while I have discussed earlier object permissions, I have not gone into the details of object ownership. I want to cover the following here: ownership of objects, how it can be changed, and the relatively new permission CONTROL (introduced in SQL Server 2005).

Ownership: This should be pretty clear - the owner of an object is usually its creator, but a different owner can be specified at creation time using the AUTHORIZATION clause. The owner of an object has all possible permissions on that object and, most importantly, cannot be denied those permissions while he continues to be an owner.

CONTROL permission: The CONTROL permission can be used to easily grant all permissions on an entity to some principal. It's the next best thing after ownership of the entity, but it's not quite as powerful as ownership. The main difference is that a grantee of CONTROL can still be denied some other permissions on the entity. For example, I can be granted CONTROL on a table, while at the same time I can be denied SELECT on that table, preventing me from selecting from it - this can never happen to the owner, because the owner cannot be granted or denied permissions.

Changing ownership: To change the owner of an entity, we can use the ALTER AUTHORIZATION statement. Changing ownership of an object creates some interesting scenarios in terms of what should be allowed and what should not be. Basically, owners should not be able to "dump" their objects to other users who may not want them and users should not be able to "steal" objects from those that own them. To accomplish this, two checks are needed: one controls to whom ownership can be given to - we verify that the performer of the change has some right on the new owner (we check for IMPERSONATE for users and logins, ALTER or membership for roles, etc); the other check controls from whom ownership can be taken away: we require the performer of the change to have TAKE OWNERSHIP permission on the object.

Note as a corollary that a grantee of CONTROL permission on an object has the ability to take ownership of the object because CONTROL implies the TAKE OWNERSHIP permission as well - the way to prevent this would be to grant CONTROL and deny TAKE OWNERSHIP.

TAKE OWNERSHIP is thus used to selectively grant someone the ability to willingly become the owner of an object or to facilitate the change of ownership of that object.

Side effect of ownership change: A potentially surprising side effect of changing ownership of an object is that all permissions granted on that object will be lost. As always, it's a good idea to script all permissions granted on an entity before changing its ownership, so that the grants can be re-executed by the new owner, if appropriate.

Basic SQL Server Security concepts: SIDs, orphaned users, and loginless users

lcris — Fri, 26 Oct 2007 03:42:00 GMT

I am grouping here two topics (orphaned users and loginless users) that are actually very different, but I have often seen confusion between them, so I am covering them together in an attempt to dispel that confusion.

In a previous discussion of logins and users, I pointed out that the way a login gets mapped to users in databases is via its SID value. This mapping is a one to many mapping - a login maps to several users (each one in a different database), but a user maps back to a single login. When a Windows login is created, its SID value is taken to be the SID of the corresponding Windows principal, but for SQL Server specific logins the SID values are generated at creation time, unless they are explicitly provided via the SID clause of CREATE LOGIN. The SID value represents the identity of the login and is invariant for the life of the login - this is why the SID clause is not available for ALTER LOGIN.

The SID link between a login and a user can be severed when databases are moved from one server to another - this is because on the new server, there may be no login having the same SID as that user. When such a situation happens, we say that the user was orphaned - it becomes an orphan user. Orphan users can also result from the deletion of a login - in previous versions, SQL Server attempted to warn about the existence of corresponding users, but even that check would fail to detect users in databases that were offline, so SQL Server 2005 no longer performs it (it was also an expensive check, as it required accessing each database). The bottom line is that orphaned users can appear in various ways and we have to either fix them when they occur or we have to prevent them from occurring at all. The classic method for restoring the SID link was to use the sp_change_users_login procedure, but starting with SQL Server 2005 SP2, a new LOGIN clause of ALTER USER has also been made available, which helps fix Windows users in addition to SQL users - a feature that sp_change_users_login was lacking. These methods will fix the SID of a user to match that of a login, effectively remapping the user to match the login. For the preventive approach, the main tool we have available is to create logins with an explicit SID value - this will help when moving a database between two or more servers, by allowing us to create in advance SQL Server logins that not only have the same name, but the same SID value as well. This will also help with recreating a login that was inadvertently dropped.

Some people seem to think that having the possibility to change a login's SID to match that of a user would be a great feature. That is not true. Changing a login's SID would be wrong because it would attack the problem on the wrong side of the login-user relationship. When fixing the user SID, only that SID needs to be changed and this would be a database scoped operation, but when fixing a login SID, all corresponding user SIDs would have to be changed as well, otherwise we would generate more orphaned users instead of fixing them - and fixing all users mapped to a login isn't a task that can be easily performed, because it would require the availability of all databases in which the login is mapped - something that cannot be guaranteed. There is a good reason why this issue is referred to as orphaned users and not as childless logins.

So, orphaned users are an issue that normally requires some fixing, when it occurs. Loginless users, on the other hand, are an intentional construct. They are created using the WITHOUT LOGIN clause of CREATE USER and they represent standalone users that cannot map to a login (they have special SID values preventing this), so you cannot connect to a database as a loginless user, although you can impersonate one via EXECUTE AS. A loginless user is valuable in many situations where an application needs to have users that don't necessarily correspond to a human user. For example, an application may be in need to create objects from time to time and to designate an owner for them - it could do this in the caller's context, but that would mean the caller would end up owning objects he may not be aware of - it is better for the application to designate a loginless user as the owner of those objects. One of my favorite uses of loginless users is to break ownership chains (see previous discussion) by assigning different loginless users as owners. Raul has a lengthier post on the topic of loginless users that offers further examples of use, including some TSQL sample code.

Basic SQL Server Security concepts - ownership chaining: good and evil; schemas

lcris — Thu, 13 Sep 2007 21:37:00 GMT

At some point during SQL Server's history, its designers must have confronted the following problem: how to give someone permission to see parts of a table without giving him any permission on the table? Slices of a table are easily defined using views, so the problem becomes one of giving SELECT permission on a view without granting a SELECT permission on the underlying table as well. Normally, the SELECT permission on the view alone is not sufficient, because the system would check permissions once when you select from the view and a second time when the view makes reference to the underlying table, so the second check would fail if the user has no permission on the table. The solution provided for this problem in SQL Server is ownership chaining. Ownership chaining, or OC for short, will bypass the permission check that would be done when the view is referencing the table, if the owner of the view is the same as the owner of the table. Intuitively, this makes sense as the intention of the owner in granting SELECT on the view must have been made so that the user would be able to actually select from that view. This mechanism has then been extended beyond this simple example involving a view and a table - the same would hold, for example, if a procedure would use a view that would refer to a table and the caller only had EXECUTE permission on the procedure and no permissions on the view or table. This idea has proliferated so that it resulted in the extension of OC to work across databases - the so-called cross-database ownership chaining (CDOC). CDOC is a topic that goes beyond what I want to cover in this post, so I'll only mention that these days it is disabled by default and it's a good idea to leave it like that.

So, OC provides a simple way to provide restricted access to objects and simplifies permission management. This sounds like a lot of good stuff. However, to achieve this, OC is bypassing permission checks completely, which means, of course, that it can bypass denies as well. I can deny someone access to a table and I might think that this prevents him from accessing that table, ever - I would be wrong however, as he might still access the table through OC. Ok, you'll say, but then I'm paying the price because I must have granted him access to a view or procedure that I own and which accesses the table. This is true, but is only true in an ideal world where people follow good practices and are aware of all the consequences of their actions - sadly, this is not our world. The bad aspect of OC is the fact that it weakens the semantics of a deny. A deny should have meant that in no way could a user perform the action that he is denied while the deny is in effect. OC represents an exception to this rule and exceptions to security principles are the root of evil.

All good security principles are often ignored in practice. One principle I often see ignored in the SQL Server world is the principle of executing with minimum privileges. It's often the case that people create objects as sysadmins and when they do that, who will be the owner of the object? dbo, of course. Soon enough, most objects are owned by dbo - see where I'm going with this? Having all objects be owned by dbo means OC chaining is rampant in the database. It's easy now for unintended OC to grant wrong access, especially in view of multiple users mapping to dbo. Because OC cannot be turned off (I wish there would be a database setting to do that), you must always be mindful of OC when you are designing your database and deciding the ownership of entities in it.

Let's look at schemas now. Similar to how databases can be used to separate applications in a server, schemas provide a further level of separation within a database. In SQL 2000, schemas were equated to users - schemas didn't really exist as distinct entities, but it was assumed that each user had a corresponding schema. This allowed referring to objects using a user name in place of a schema, as when saying: db1.alice.proc. In SQL Server 2005, schemas became actual objects acting as containers of other basic entities, like procedures, views, tables, etc. To keep backward compatibility with existing use, when creating a user with old procedures such as sp_adduser, both a user and a schema named after it are created and the schema will be owned by that user; when using the new DDL, however, CREATE USER would only create the user and if a schema is desired as well, it would have to be explicitly created using CREATE SCHEMA. The owner of a schema will be the default owner of all objects within that schema (in this case, the principal_id column of the sys.objects row for such objects will be marked as NULL). It is possible, however, to change the ownership of individual objects in a schema to other principals than the schema owner (in this case the principal_id column would indicate the effective owner). You can read more about schemas in this BOL article.

The reason I grouped these topics together is because both are related to object ownership. OC permits a bypassing of permission checks in references made by one object to another and schemas provide a way to specify an owner for a large collection of objects. For schemas to be effective at separating access to objects, because of OC, they should be owned by different principals. It would be a mistake to allow all schemas in the database to be owned by dbo, for an extreme example.

Today, the problem for which OC constitued a solution can be resolved in other ways. With the introduction of module signing in SQL Server 2005, it is now possible to associate permissions with a module, which allows more granular access control than OC could provide. But OC is always on by default and must be kept in mind at all times to prevent undesired side-effects from its existence. To mitigate such undesired side-effect, keep OC in mind when deciding the ownership of entities in your database. In particular, do not setup your database such that all objects are owned by dbo. Keep in mind that SQL Server 2005 allows you now to create users that are database scoped - the loginless users created via CREATE USER...WITHOUT LOGIN - these types of users are perfect for breaking ownership chains in a database.

Basic SQL Server Security concepts - permissions and special principals: sa, dbo, guest

lcris — Thu, 13 Sep 2007 01:12:00 GMT

In a previous post, I talked about the various types of principals in SQL Server. Let's have a further look in this post at permissions and at some of the hardcoded principals that ship with any installation of SQL Server.

Permissions are what allow principals (logins, users, roles, etc) to perform (or not perform) activities in SQL Server. Permissions are managed through three operations: grant, deny, and revoke (or GDR for short). A grant specifies that a principal (the grantee) is allowed to perform a specific operation; a deny specifies the reverse - that the principal (still referred to as grantee) should not be capable of performing a specific operation; finally, a revoke is simply a mechanism for erasing any previous grants or denies. The person that performs a GDR operation is referred to as the grantor, regardless of the type of operation (i.e. the grantor may perform a deny). All GDR operations have three main parts: they specify a permission name, a grantee name (the subject of the GDR operation), and optionally an entity name on which the permission takes effect (the securable - the object of the GDR operation). The securable is optional because in some cases it is implied by the permission. Sounds complicated? Let's walk through an example. Let's say Alice grants Bob the SELECT permission on table t. She would do this with a statement like:

grant SELECT on t to Bob

In this operation, Alice is the grantor (because she executes the statement), Bob is the grantee, SELECT is the permission name, and t is the securable - the object on which the SELECT permission is granted.

Depending on the scope of the securable, the permission granted is either a server permission or a database permission. When a server permission is GDRed, the securable is implicitly the server and it is not specified in the GDR statement. Grants and denies of server permissions are recorded in the catalog sys.server_permissions; grants and denies of database permissions are recorded in sys.database_permissions. Of course, a server permission can only be granted to a server principal and a database permission to a database principal (in the above example, Alice and Bob are users; if they would be only logins, without any corresponding users of the same names, the statement would be invalid). Also note that revokes, because they act as an eraser, are not recorded anywhere - they are just removing entries from these catalogs! The revoke operation is often misunderstood, but the simplest way to think about it is that is an eraser of grants or denies.

All this information gives you a good basic understanding of the permissions system. There is only one more rule that you should keep in mind at all times: denies prevail over grants. What this means is that if I am a member of two roles, one of which is granted a permission and one of which is denied that same permission, the end result is that the permission is denied to me, because the deny will take precedence over the grant. A caveat here: there is a special case when permission checks are completely bypassed - ownership chaining, which can allow a principal to access an object despite that principal being denied access to it. I'll comment on ownership chaining in a future post.

With the basics of permissions understood, let's look at some special SQL Server principals. The most notorious SQL Server login must be sa. sa is a SQL login administrator account that can be used if mixed authentication is enabled on SQL Server. sa has been infamous due to most people using weak passwords for it (often an empty password) and thus making their systems vulnerable to any attacker that could attempt a connection. The sa login is hardcoded to be a member of the sysadmin server role. sa and sysadmin membership should be regarded as representing ownership of the server system - they are the pinnacle of power in the SQL Server world! This means that the sa password should be chosen to be a strong password and that membership in the sysadmin role should not be granted around freely. sa is so powerful that you can't even deny him permissions. Because sa is builtin, most attackers are always attempting to break into this account first. SQL Server 2005 has added a number of new features that you can use to defend this account better from attacks:

1) If you don't use sa but you want to use SQL Authentication (if you don't want to use SQL authentication, you can just restrict authentication to Windows only mode), then you can disable sa using the ALTER LOGIN ... DISABLE command. A disabled login cannot be used for gaining access to SQL Server until it is enabled back again.

2) If you use sa, you should make sure that you keep password policy checks enforced for that account (this is the default behavior and something that you should keep for any login). Note that password policy checks can only be enforced if your OS is Windows 2003 or Windows Vista. Password policy checks will increase the difficulty of someone figuring out your password through brute force.

3) If you notice frequent failed attempts to connect as sa, you can rename the sa account - this will stop outright those attackers, because they'll now have to first figure out the name of a valid login to attack. You can rename sa using the ALTER LOGIN ... WITH NAME statement.

The next famous and often misunderstood principal is the database user dbo. I discussed about how users are mapped to logins via their SID values. The same holds for dbo, except the mapping of dbo is not done at user creation - dbo always exists since the database was created; instead, the login to which dbo maps is determined by what login is the owner of the database - dbo will always map to the login that is marked as the database owner. Here's a query that can be used to find who is the owner of the current database:

select suser_sname(sid) from sys.database_principals where principal_id = user_id('dbo')

The way to change the mapping of dbo to a login is by changing the database ownership. This can be done via sp_changedbowner or using the newer syntax of ALTER AUTHORIZATION. The owner of a database is also recorded in sys.databases; however, this information can become stale when moving a database from one system to another - to fix a stale entry you can always reissue a database ownership change command. The above query returning NULL, for example, would be an indication that the database was brought from another server where it was owned by a principal that doesn't exist in the current server.

The dbo denomination exists so that, within each database, the most powerful principal is clearly known. Same as sa was built in at server level, dbo is its database counterpart. Like sa, dbo is the most powerful user in a database and no permissions can be denied to him. dbo is a member of the db_owner database role, and these represent the equivalent of the sa/sysadmin pair at the database level. A final important note is that sa and sysadmin members will always map to dbo, regardless of what login is set as the database owner. Thus, dbo is a fuzzy concept that doesn't clearly identify a single principal mapped to it.

Next stop is guest; guest is a database user that was meant as a way to provide anonymous access to any database. This kind of access is however unrecommended and these days guest is disabled in all databases except some system databases. If guest is enabled, it basically allows any login that is not explicitly mapped in the database to a user, to connect to the database as guest (otherwise, the login would not be able to connect, unless sysadmin, database owner, etc). There is little point in allowing this kind of anonymous access, so by default, in user databases, guest is not granted connect permission, which effectively disables it. Note that it is not possible to effectively remove guest from a database - it cannot be dropped and attempting to drop it will just issue a REVOKE CONNECT command. You can check the permissions assigned to guest using the following query:

select permission_name, state_desc, object_name(major_id) as securable, user_name(grantor_principal_id) as grantor from sys.database_permissions where grantee_principal_id = user_id('guest')

Finally, to conclude this post, let's look at the public roles. There is a new public server role in SQL Server 2005, in addition to the public database role that existed earlier. Any server principal is implicitly a member of the public server role and any database principal is implicitly a member of the public database role. I say implicitly because the memberships are hardcoded in the system and they do not appear in the catalogs, nor can they be modified. These roles allow a simple mechanism to GDR permissions to every principal at server or database scope; you can think of them as meaning "everyone". The permissions associated with the public database role can be checked using the previous query, after replacing 'guest' with 'public'. For querying the public server role permissions, you can use the following query:

select permission_name, state_desc, suser_name(grantor_principal_id) as grantor from sys.server_permissions where grantee_principal_id = suser_id('public')

Keep in mind that permissions assigned to these roles by default are necessary for the good functioning of the system. You can revoke some of the default permissions, but that could break functionality. The grants should be inoffensive from a security point of view; if you feel otherwise, you should contact the SQL Server security team on the MSDN forums.

Basic SQL Server Security concepts - logins, users, and principals

lcris — Fri, 23 Mar 2007 20:25:00 GMT

In this post I'd like to talk about some basic SQL Server security concepts. SQL Server has a less common design that can confuse users familiar with the security features of other software products, such as Microsoft Windows OS; in particular, the difference between logins and users is one that seems to invariably confuse most new SQL Server users.

The first important thing that needs to be understood about SQL Server security is that there are two security realms involved - the server and the database. The server realm encompasses multiple database realms. All work is done in the context of some database, but to get to do the work, one needs to first have access to the server and then to have access to the database.

Access to the server is granted via logins. There are two main categories of logins: SQL Server authenticated logins and Windows authenticated logins. I will usually refer to these using the shorter names of SQL logins and Windows logins. Windows authenticated logins can either be logins mapped to Windows users or logins mapped to Windows groups. So, to be able to connect to the server, one must have access via one of these types or logins - logins provide access to the server realm.

But logins are not enough, because work is usually done in a database and databases are separate realms. Access to databases is granted via users.

Important Note: When describing a SQL Server scenario, terms like logins and users should not be used interchangeably - a login is a different concept than a user.

Users are mapped to logins and the mapping is expressed by the SID property of logins and users. A login maps to a user in a database if their SID values are identical. Depending on the type of login, we can therefore have a categorization of users that mimics the above categorization for logins; so, we have SQL users and Windows users and the latter category consists of users mapped to Windows user logins and of users mapped to Windows group logins.

Let's take a step back for a quick overview: a login provides access to the server and to further get access to a database, a user mapped to the login must exist in the database. It is important to know the difference between these two concepts of login and user and to not use these terms interchangeably.

The existence of databases as a separate realm has the advantage of allowing a database to be detached from a server instance and to be attached to another one. The operation is not without issues, as users may need to be remapped to logins in the new instance and this is a manual operation - it can be performed using sp_change_users_login or, starting with SQL Server 2005 SP2, by using a new clause of the ALTER USER statement.

Note: Users that are not mapped to a login as a result of a database move are known as orphaned users.

Another advantage is that databases as separate entities allow a better separation of distinct applications - applications can each be placed in their own database, making it harder to accidentally or maliciously access data under the control of another application.

This separation has an impact on the authorization model of SQL Server as well, as it may be expected. Permissions can be granted at both scopes: server and database. Permissions granted at server scope take effect regardless of what is the current database, but permissions granted at database scope are used only while working in that database. Server level permissions are the permissions that are assignable to logins, and database level permissions are the permissions assignable to users. To help with the management of permissions, some other entities than the logins and users we discussed so far can be used as the grantees of a permission. Collectively, in SQL Server, the entities that can be granted a permission are referred to as principals. Principals are separated into server principals and database principals according to their scope.

Important Note: While the logins discussed so far grant access to the server and thus are having a role in the authentication process, the other server principals are only used for permission management and do not help with server authentication.

Examples of server principals besides the logins discussed previously are server roles and logins mapped to certificate or asymmetric keys. Examples of database principals are database roles (fixed and flexible), application roles, users mapped to certificate or asymmetric keys, and loginless users. All of these help with the assignment of the permissions. Loginless users (created using CREATE USER ... WITHOUT LOGIN) are a special case because they can be impersonated (application roles are similar, but terminology differs - approles are set, while loginless users are impersonated).

The last concept I want to discuss here is that of execution context. The execution context is how SQL Server keeps track of who you are. As it may be expected already, the execution context is formed of a server execution context and a database execution context - these are referred to as login token and user token. The login-user token pair determines who you are in the eyes of the system. The context is initially determined upon login and changes when you switch to a different database or when an impersonation takes place. For more information on the execution context and on impersonation mechanisms, which are topics that extend well beyond the scope of this post, you can have a look at my presentation from http://cmcgc.com/Media/WMP/261115/ and its relevant demo.