creating registry key in HKEY_LOCAL_MACHINE accessible by all

Hello,

Basically I have an application (dll) that allows admins to configure a system wide configuration that is accessible (read-only) by normal users. The system wide configuration is stored in HKEY_LOCAL_MACHINE\Software.

The code of course works on Windows 2000/XP but not on Vista because of, as I suspect, the fact that the information is stored in the virtual store under HKEY_CURRENT_USER.

When the admin stores the new configuration and a normal user attempts to use the configuration (in a different security context) they receive a unknown registry key error as the information is, of course, not available.

As I understand reading through the forum setting the "run-level" using a manifest file allows me to skip the virtualization and write directly to HKEY_LOCAL_MACHINE.

I have however tried to use a manifest file, but no luck so far. Any ideas Am approaching this correctly

manifest file:

---
< xml version="1.0" encoding="UTF-8" standalone="yes" >
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="5.6.0.0"
type="win32"
name="app.dll"/>
<description>App</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
---

command line to load the manifest into the app.dll:

---
mt.exe" -nologo -manifest app.dll.manifest -outputresource:app.dll;2
---

Regards,

Tom Rixom

Software Development for Windows Vista14

Execution levels only apply to exes. Dlls run at the same level as the application that loads them.

Thanks for the quick response.

The dll is part of the EAPHost infrastructure in Vista and it is unclear in which security context the dll is called (Sometimes SYSTEM, sometimes user, sometimes ...).

What other approaches might I try

Regards,

Tom Rixom

It's difficult to answer this question without understanding the scenario better, primarily how often the key needs to be updated.
If it's only the creation that matters, the installation step should take care of it.
If it's appropriate for standard users to update it afterwards, an ACL can take care of this.

If it's updated at runtime too (and relaxing access is not appropriate), and you can't guarantee that the dll is going to be loaded "elevated" (SYSTEM or admin) before it's loaded as standard user, then HKLM is probably not a good location.

Even outside of UAC, the user might not be an admin at all (more and more common in the enterprise).
If he's an admin, with UAC on, he may never run anything elevated for days.

Depending on your scenario, 2 keys (one in HKLM, one in HKCU (not used when the other exists )) might be an alternative.

Hi,

again thanks for the response.

>It's difficult to answer this question without understanding the scenario better, primarily how
> often the key needs to be updated.

The scenario is that I have a system wide configuration and a user specific configuration. They are
split up into two, system wide in HKEY_LOCAL, user specific in HKEY_USER.

The problem I think I am having is that even though I am an Administrator of the system when
configuring the system wide I am still not able to get the right permissions to write in HKEY_LOCAL.
This is because how EAPHost loads the application dll.

>If it's only the creation that matters, the installation step should take care of it.
>If it's appropriate for standard users to update it afterwards, an ACL can take care of this.

I am thinking the problem is in the ACL, again this works on Windows 2k/XP. An admin creates
a special key with an ACL for the Everyone SID (Read) and an ACL for the Admin SID (Read/Write).
Please see the code below that shows how I set the ACL. Reading through the code I am thinking
maybe the "BUILTIN\Administrators" ACL is incorrect.

> If it's updated at runtime too (and relaxing access is not appropriate), and you can't guarantee
> that the dll is going to be loaded "elevated" (SYSTEM or admin) before it's loaded as standard
> user, then HKLM is probably not a good location.

What other options do I have to allow users access to a global configuration in the registry

> Even outside of UAC, the user might not be an admin at all (more and more common in the enterprise).
> If he's an admin, with UAC on, he may never run anything elevated for days.

> Depending on your scenario, 2 keys (one in HKLM, one in HKCU (not used when the other exists ))
> might be an alternative.

Which is my scenario.

But I do understand correctly that if I don't have write privileges in the HKEY_LOCAL it will
be "virtualized"

Regards,

Tom Rixom

------------------
....
PSID pAdminSID = NULL;
PSID pEveryoneSID = NULL;
PACL pACL = NULL;
PSECURITY_DESCRIPTOR pSD = NULL;
EXPLICIT_ACCESS ea[2];
SID_IDENTIFIER_AUTHORITY SIDAuthWorld =
SECURITY_WORLD_SID_AUTHORITY;
SID_IDENTIFIER_AUTHORITY SIDAuthNT = SECURITY_NT_AUTHORITY;
SECURITY_ATTRIBUTES sa;

//
// Create a well-known SID for the Everyone group.
//
AllocateAndInitializeSid( &SIDAuthWorld,
1,
SECURITY_WORLD_RID,
0,
0, 0, 0, 0, 0, 0,
&pEveryoneSID ) )

//
// Create a SID for the BUILTIN\Administrators group.
//
AllocateAndInitializeSid( &SIDAuthNT,
2,
SECURITY_BUILTIN_DOMAIN_RID,
DOMAIN_ALIAS_RID_ADMINS,
0, 0, 0, 0, 0, 0,
&pAdminSID ) )

memset( &ea, 0, 2 * sizeof( EXPLICIT_ACCESS ) );

// Initialize an EXPLICIT_ACCESS structure for an ACE.
// The ACE will allow Everyone read access to the key.
ea[0].grfAcces****issions = KEY_READ;
ea[0].grfAccessMode = SET_ACCESS;
ea[0].grfInheritance= NO_INHERITANCE;
ea[0].Trustee.TrusteeForm = TRUSTEE_IS_SID;
ea[0].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
ea[0].Trustee.ptstrName = ( LPTSTR ) pEveryoneSID;

//
// Initialize an EXPLICIT_ACCESS structure for an ACE.
// The ACE will allow the Administrators group full access to the key.
//
ea[1].grfAcces****issions = KEY_ALL_ACCESS;
ea[1].grfAccessMode = SET_ACCESS;
ea[1].grfInheritance= NO_INHERITANCE;
ea[1].Trustee.TrusteeForm = TRUSTEE_IS_SID;
ea[1].Trustee.TrusteeType = TRUSTEE_IS_GROUP;
ea[1].Trustee.ptstrName = ( LPTSTR ) pAdminSID;

//
// Create a new ACL that contains the new ACEs.
//
if( ( dwRet = SetEntriesInAcl( 2, ea, NULL, &pACL ) ) == ERROR_SUCCESS )
{
//
// Initialize a security descriptor.
//
if( ( pSD = ( PSECURITY_DESCRIPTOR ) malloc( SECURITY_DESCRIPTOR_MIN_LENGTH ) ) )
{
if( InitializeSecurityDescriptor( pSD, SECURITY_DESCRIPTOR_REVISION ) )
{
//
// Add the ACL to the security descriptor.
//
if( SetSecurityDescriptorDacl( pSD,
TRUE, // bDaclPresent flag
pACL,
FALSE)) // not a default DACL
{
//
// Initialize a security attributes structure.
sa.nLength = sizeof (SECURITY_ATTRIBUTES);
sa.lpSecurityDescriptor = pSD;
sa.bInheritHandle = FALSE;

//
// Use the security attributes to set the security descriptor
// when you create a key.
//
RegCreateKeyEx( hKey,
pwcSubKey,
0,
NULL,
0,
KEY_READ | KEY_WRITE,
&sa,
phSubKey,
pdwDisposition ) != ERROR_SUCCESS )
{
...
------------------

Hi Eric,

could you maybe see anything wrong with the way I set up the ACL Has

anything changed in the way Vista handles ACLS'S apart from of course

the whole virtualization

Does this virtualization also apply to files Would it be possible to create

a file that has read/write for Admin and read for Everyone (say in the

Program Files directory) in the same situation

Regards,

Tom

There's nothing obviously wrong with the code but the easiest way to verify is for you to check the ACL from regedit.exe...

I'm not familiar with the EAP stack.
In which security context does this EAPHost run The logged on user A service

Hi Eric,

Again, thanks for the reply.

The EAPHost stack runs as the logged on user when configuring the EAP method, I verified this with the following two scenarios:

1. By default only the group Administrators of which "tom" is a member has write privileges for the registry key. In this scenario it is NOT possible to write anything to the registry key.

2. Adding the user "tom" to the registry key with write privileges. This works.

This basically means it will not be possible to get access to the HKEY_LOCAL without
elevating with for example a manifest file. But here I guess I am stuck with how the EAPHost
calls my dll.

Regards,

Tom Rixom

Hi Eric,

Just like to say I got it working by calling an .exe from my program that requires elevation.

Thanks for your help,

Tom Rixom