The following code creates a folder named “JWSCLTest” and applies a DACL that allows full control to everyone. The folder will inherit its security settings to child folders and files (check the afXXX flags).

const JWSCLTestFolder = 'JWSCLTestFolder';

var
  SD : TJwSecurityDescriptor;
  pSA : PSecurityAttributes;
begin
  JwInitWellKnownSIDs;

  SD := TJwSecurityDescriptor.Create;
  try
    SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil,
      [afContainerInheritAce, afObjectInheritAce], FILE_ALL_ACCESS, JwWorldSID));

    pSA := SD.Create_SA();
    try
      Win32Check(CreateDirectory(JWSCLTestFolder, pSA));
    finally
      SD.Free_SA(pSA); //remember to free pointer
    end;
  finally
    SD.Free;
  end;
end.

CreateDirectory receives a security attributes structure that is applied to the folder directly. However, in this way the parent security descriptor is not inherited to our folder. This is called a protected DACL because the inheritance flow is stopped. So we get a folder with only one Access Control Entry (ACE) : Everyone (aka World SID). To remedy that we can copy the ACEs from the parent folder to our own folder:

procedure MergeParentDACL(const Location : String; TargetSD : TJwSecurityDescriptor);
var DirSD : TJwSecureFileObject;
begin
  DirSD := TJwSecureFileObject.Create(Location);
  try
    TargetSD.DACL.AddACEs(DirSD.DACL);
  finally
    DirSD.Free;
  end;
end;

var
  DirSD : TJwSecureFileObject;

  SD, SD2 : TJwSecurityDescriptor;
  pSA : PSecurityAttributes;
begin
  JwInitWellKnownSIDs;

  SD := TJwSecurityDescriptor.Create;

  try
    SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil,
      [afContainerInheritAce, afObjectInheritAce], FILE_ALL_ACCESS, JwWorldSID));

    MergeParentDACL('.', SD);

    pSA := SD.Create_SA();
    try
      Win32Check(CreateDirectory(JWSCLTestFolder, pSA));
    finally
      SD.Free_SA(pSA);
    end;
  finally
    SD.Free;
  end;
end.

The function MergeParentDACL receives the location of the parent folder and retrieves its security settings. Then its DACL is copied to the target security descriptor. JWSCL with TargetSD.DACL.AddACEs makes sure that the order of the ACEs are still correct (first deny then allow entries) by moving them accordingly.

In addition, there is a second, much easier way to achieve the same result.

var
  SD : TJwSecurityDescriptor;
  DirSD : TJwSecureFileObject;
begin
  JwInitWellKnownSIDs;

  Win32Check(CreateDirectory(JWSCLTestFolder, nil));

  DirSD := TJwSecureFileObject.Create(JWSCLTestFolder);
  try
    SD := DirSD.GetSecurityDescriptor([siDaclSecurityInformation]);
    try
      SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil,
        [afContainerInheritAce, afObjectInheritAce], FILE_ALL_ACCESS, JwWorldSID));

      DirSD.SetSecurityDescriptor(SD, [siDaclSecurityInformation]);
    finally
      SD.Free;
    end;
  finally
    DirSD.Free;
  end;

In this way we didn’t set the security descriptor directly when the folder was created. Nevertheless we get a combination of inheritace ACEs plus the explicit one (JwWorldSID).

Note

It is always a good idea to check whether SD.DACL (in above codes) is nil and if so ignore it or create a new and empty one to be used instead. It is always possible that a file or folder comes with a nil DACL which means either no access at all (flag DACLpresent) or everyone has full access (flag DACLpresent not available).

I used the following JEDI units:

uses
  JwaWindows,

  JwsclDescriptor,
  JwsclTypes,
  JwsclConstants,
  JwsclKnownSid,
  JwsclAcl,
  JwsclMapping,
  JwsclSecureObjects,
  JwsclSid,

However there are some problems:

1. This code does not prevent the user from reverting the process DACL to the original state. An owner of the process can always change the DACL even if she is not listed in it. So the code just prevents a beginner from closing the application forcefully.
2. Any user with the DEBUG privilege can open the process with full access using OpenProcess. The taskmanager uses this way to terminate a process – if TaskManager is started with administrative rights.

The only way to prevent a restricted user from terminating the application is to run the process with a foreign account (e.g. CreateProcessAsUser) and make sure that the user is not listed in the DACL. However if this user gets the DEBUG privilege the game is over.

The following code will also be available in the example section of the source code. The application gets a file or folder name as parameter and tries to add the user with full access control. It even tries to get ownership if it can’t change the access control list.

First of all we need some JWSCL classes:

• TJwSecurityDescriptor
  A security descriptor contains all information about security of an object. It contains the owner and the access control list (also some other thing, we don’t need here)
• TJwSecureFileObject
  This class provides methods to read and write security information on a file or folder. Despite its name it does also support folders. It even supports inheritance.
  You can access a file or folder through its name, a handle or the VCL class TFileStream.
• TJwDAccessControlList
  This class contains methods to maintain a discreationary access control list (DACL). A DACL contains a list of users and their possible access on the object.
• TJwSecurityId
  Every user is identified by a unique number which is maintained by this class.
• TJwSecurityToken
  Every logged on user gets a security pass which contains information what she can do or not. We mainly use it to retrieve the user’s SID (TJwSecurityID)

These classes are stored in the JWSCL units. We use the following ones:

The units above are necessary and contain all the classes described earlier Of course we have to declare the classes:

This example also shows how we can add well known Security Identifiers (SID) to a secured object. We have to initialize them. The variable JwWorldSID will then contain the correct SID for group Everyone. If we didn’t call it, we would get nil instead.
JwInitWellKnownSIDs;

The next steps are creating the classes. We get the user name through her token and save the SID into Owner.
Later we will use the Owner instance to add it into the security information of the object.

The actual class which does all the work on the file/folder is TJwSecureFileObject. We just apply the first parameter.

Notice: A user can only change security information of an object if she has the right to do it. There are two options to allow it.

1. The user is listed in the DACL. Additionally the right WRITE_DAC is granted for her.
2. The user is the owner. In this case she don’t need to be listed and allowed in the DACL. It is automatically granted

We can check both version in one call.

This call is very easy. If we can’t change the DACL, we can try to become the owner. The only way to become an owner is to enable a privilege called SE_TAKE_OWNERSHIP_NAME. It is usually only granted to Administrators.

JwEnablePrivilege will fail, if it can’t activate the privilege. Otherwise we can set the file/folder’s owner to the token user.

The main work is done here. We get the default DACL from the existing object and adapt it.

Adaption is done by adding the user to the DACL with full control. We additionally allow the Everyone group to demonstrate the well known Sids initialized by JwInitWellKnownSIDs. The last parameters (false) define that we don’t want the list to free the given SIDs (Owner and JwWorldSid) automatically.

And finally we reset the DACL.

The DACL of the file or folder will receive the newly created control entries in addition to its existing ones. If it contains inherited entries (entries from a parent folder) they will be conserved. However if you don’t retrieve the DACL and just use an empty one, all previously existing entries which are not inherited will be removed. Of course the inherited entries will still remain intact.

And of course we free all allocated resources

Since I cut the source code into pieces, I’ll show it here in full glory

Last time we used the SecurityAttribute parameter in CreateFile to change the security descriptor of the newly created file. However this approach did not add inherited access control elements from the parent folder. We are about to change that.

Filesystem and Registry-key inheritance is implemented since Windows 2000 and also can be added to Windows NT 4 by installing an update. It is a really convenient way to set security over many files in a complex folder tree.

So what did we last time?

This code assigns a simple security descriptor. In my tests there was no way to let CreateFile add the inherited elements to the DACL. Luckily there are several ways to do so.

1. Get the inherited access elements from the parent and add them to our DACL by hand
2. Let the system handle inheritance
3. Do the second way much faster

1. Get the inherited access elements from the parent and add them to our DACL by hand

The first choice needs a lot of work to do. First we need all the inheritable access control elements from the parent folders. This would become very nasty if we had to recursively go up to all parent folders to get the elements. However we are lucky because all inherited ACEs are always available through the direct parent container (if they are not blocked).
Because I will need more time to describe this approach. I’m going to skip this part for now and discuss it in a separate blog entry.

2. Let the system handle inheritance

JWSCL supports inheritance of file, folder and registry keys with the classes TJwSecureFileObject and TJwSecureRegistryKey. We are going to use only TJwSecureFileObject for our task. However changing permissons and inheritance of a registry key is straight forward and is much the same job as it is with files and folders.

TJwSecureFileObject offers three ways to adapt security of a file or folder. You can use a file/folder handle (retrieved by CreateFile), a file or folder name or you use the VCL class TFileStream. However the last variant has some disadvantages like not being able to work with folders.

TJwSecureFileObject retrieves the DACL of the file after newly created file was opened. The method SetDACL sets the DACL back but also removes the protection flag from security descriptor control. Thus all the inherited access elements flow to the file’s access control list.

3. Do the second way which is much less to write

TJwSecureFileObject offers class methods to act with file or folders much faster. We can either restore the inheritance flow by using the file/folder name…

or reestablish the inheritance flow by using a file handle.

You can use one way or the other.

Tell me how you liked this blog entry by adding a comment.

There is also a second way to get the integrity label.