Skip to main content

Access Controls, User Permissions and Privileges

Access controls 1258x839 19jan16 en

In my last post, What is Authorization and Access Control, I explained that we use authentication to verify identity – to prove you are who you claim to be – and also to enable an authorization policy, to define what your identity is allowed to "see and do". We then implement these authorization policies using security measures to grant or deny access to resources we want to control or protect.

The measures we use to implement authorization policies are called user access controls, user permissions or user privileges. User access control is commonly used in the Windows operating system, router or firewall documentation, but user privilege or user permission is more common to Linux documentation. You may find entire threads that discuss differences among these terms, but for introductory purposes, treat the terms as if they are interchangeable. Use the term you're most comfortable with or that you encounter most frequently in the literature that's most relevant for you.

When you define an authorization policy, you define individual or sets of users, applications or processes that can perform actions on a resource such as a database. You can be very granular with an authorization policy. You can control actions - whether individuals or groups of individuals can read, create or modify (write), delete – on individual database entries, or even individual elements (fields) of a database entry.

An Example Authorization Policy

Let's imagine a merchant database of records where each record contains a name, home address, telephone and credit card information. The merchant's IT staff defines an authorization policy that organizes access for the merchant's employees into three classes of privilege:

  1. Database administrators, Joe and Terry, can perform any action on any customer record in the database. For example, they can create a record, modify any element of any record and delete any record.

    This is an example of full access.

  2. Accounting staff, Charlotte and Bert, can read any field of any customer record including the credit card information, but they may not create, modify, or delete records or fields within records.

    Here, we allow access to the full set of records but we deny the ability to create, alter, or delete any records or fields within records.

  3. Marketing staff, Ahmed and Carlo, can read any customer record but they cannot read the credit card information, and they are not permitted to create, modify, or delete any record or field.

    Here, we allow access to the full set of records, but we deny access to specific data within each record.

These examples illustrate an important security concept, the principle of least privilege (POLP), where an organization grants users only those privileges they need to do the work they've been assigned. For example, our fictitious company has decided that marketing staff do not need to access credit cards. Our examples also illustrate role based access control (RBAC). In the examples, the company has set privileges based on the set of roles {database administrator, accounting staff, marketing staff…}.

Setting the Stage

Consider the access controls in our example, and ask, "If you're an attacker and you want to steal information you can use to fraudulently use credit card information, which user accounts would you want to gain access to?"

We'll look at how attackers try to gain access and escalate privileges in our next post.


    cheryl hunt  14:10 UTC on 25 February 2016

    Imagine my surprise upon finding out someone from has hijacked our domain name and locked it. My host ( will not give me any information because all of a sudden domain and account don't belong to us anymore according to them. And icann posts that all is well with the domain. So we are paying for a domain and hosting that doesn't belong to us and have NO web presence. So WHAT ARE OUR OPTIONS?

    David Piscitello  10:59 UTC on 24 March 2016

    Cheryl, I'm sorry you have been victimized. I wrote a post on my personal blog a while ago that explains how to go about recovering your domain and what documentation you may need to acquire. Our Security may be able to assist you with a whois history to assist you in identifying sponsoring registrar and to demonstrate that the rights to use are yours.

    David Piscitello  11:01 UTC on 24 March 2016

    The post I refer to in the above comment is

    Robert Greene  19:34 UTC on 13 April 2016

    Being a novice with access controls, permissions and privileges, I find this series very interesting and educational in a simple way. Looking forward to the next part.

    Ramya  05:08 UTC on 15 December 2016

    My partner and I absolutely love your blog and find many of your post’s to be just what I’m looking for. Does one offer guest writers to write content for you personally? I wouldn’t mind writing a post or elaborating on a lot of the subjects you write in relation to here. Again, awesome site

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."