CreateFileMapping security problems

[Michael Weir]

I am writing a perfmon dll for a service that logs on as "Local System".  Both the service code and the perfmon DLL use the same code for creating a shared memory area for sending over data.  The problem is that the perfmon DLL cannot open/create the mapped memory when the service created it first.  When the service logs in as my local user, there is no problem. 

 

Any help would be much appreciated.

 

Here's the code:

> // Create an Everybody-can-do-anything security descriptor
> SECURITY_DESCRIPTOR sd;
> SECURITY_ATTRIBUTES sa;
>
> sa.nLength = sizeof(SECURITY_ATTRIBUTES);
> sa.bInheritHandle = TRUE;
> sa.lpSecurityDescriptor = &sd;
>
> SECURITY_ATTRIBUTES* pSA = &sa;
>
> BOOL bWorked = ::InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION);
> if (bWorked != TRUE) {
>     d_EventLog.Error("Failed to initialize security descriptor for shared memory");
>     rc = S_FALSE;
> }
> else {
>     // Create a new mapping for the performance counters
>     hNewMapping = ::CreateFileMapping( (HANDLE) 0xFFFFFFFF,
>                                        pSA,
>                                        PAGE_READWRITE,
>                                        0,
>                                        newSize,
>                                        d_sSharedMemoryName.c_str()
>                                        );
>     if (hNewMapping == NULL) {
>         rc = ::GetLastError();

WILL RETURN 5 HERE.
>         d_EventLog.Error("Problem in ::CreateFileMapping rc=%i", rc);
>     }
>     else {
>         ...

>

BTW, this works the same when I use OpenMappedFile in addition to CreateFileMapping.

[William DePalo [MVP VC++ ]]

"Michael Weir" <mw...@transres.com> wrote in message
news:#Kz3BJS2CHA.1728@TK2MSFTNGP12...

> I am writing a perfmon dll for a service that logs on as "Local System".
> Both the service code and the perfmon DLL use the same code for
> creating a shared memory area for sending over data. The problem
> is that the perfmon DLL cannot open/create the mapped memory
> when the service created it first. When the service logs in as
> my local user, there is no problem.

Try adding this line after you initialize the security descriptor:

SetSecurityDescriptorDacl(&sd, TRUE, (PACL) NULL, FALSE);

Regards,
Will

[Michael Weir]

Thanks. I tried it, and it works.

The only (apparent) effect of the SetSecurityDescriptorDacl call is to set
the Control field on the SD to SE_DACL_PRESENT. The documentation for this
flag says "Indicates a security descriptor that has a DACL. If this flag is
not set, or if this flag is set and the DACL is NULL, the security
descriptor allows full access to everyone. " Previously the flag was not
set, and now it is set but the DACL is NULL. It looks a bit like the first
clause quoted from the docs is incorrect, and that "if this flag is not set"
is not sufficient to grant access to everyone.

Thanks very much for the help.

"William DePalo [MVP VC++ ]" <depalow...@compuserve.com> wrote in
message news:#67vNnS2...@TK2MSFTNGP11.phx.gbl...

[William DePalo [MVP VC++ ]]

"Michael Weir" <mw...@transres.com> wrote in message

news:e0CEOxb...@TK2MSFTNGP09.phx.gbl...

> Thanks. I tried it, and it works.

You are welcome.

> The only (apparent) effect of the SetSecurityDescriptorDacl call is to set
> the Control field on the SD to SE_DACL_PRESENT. The documentation for
this
> flag says "Indicates a security descriptor that has a DACL. If this flag
is
> not set, or if this flag is set and the DACL is NULL, the security
> descriptor allows full access to everyone. " Previously the flag was not
> set, and now it is set but the DACL is NULL. It looks a bit like the
first
> clause quoted from the docs is incorrect, and that "if this flag is not
set"
> is not sufficient to grant access to everyone.

To those of us (me included) who don't "major in security" it is confusing.
As I understand the issue is there is a difference between a NULL DACL
present and empty DACL. I took this from an article in the MSDN on security
by Ruediger Asche:

"The semantics of ACLs leave wide room for variation, so this behavior can
be implemented in several ways. By convention, an SD that has a NULL DACL is
unprotected (that is, every attempt to access the object that is associated
with the SD will succeed), whereas an SD with a DACL that is empty (it has
no ACEs) is fully protected (that is, access to the object associated with
the SD will fail)."

Regards,
Will