Impact of Least Privilege in System Services

re: Impact of Least Privilege in System Services

Antti Nivala — Fri, 20 Oct 2006 09:17:07 GMT

The lack of SeBackupPrivilege prevents our M-Files software from installing on Vista (upgrade from one version to another fails). The impact to us is severe and it seems it will require major rework to get the installation system run on Vista given this limitation. Are you sure that this limitation is worth adding given that it will prevent the installation of some applications on Vista? Ours surely cannot be the only one.

Our MSI package has a CA that requires SeBackupPrivilege because it calls RegLoadKey. We call RegLoadKey because during an upgrade (not related to MSI upgrade), we need to migrate each user's settings in the registry from the old version's key to the new version's key. After copying the settings, we uninstall the old version, which deletes the settings from each user's registry hive in the same way.

Is there any way our MSI package could modify the other users' HKCU settings in Vista?

Any chance on you allowing RegLoadKey in CAs, perhaps in some other way than putting SeBackupPrivilege back?

re: Impact of Least Privilege in System Services

prsTM — Thu, 26 Oct 2006 16:36:17 GMT

My service is trying to create a pipe that's writeable by any user account. I've tried to set the security attributes two ways. Both of them work fine on XP, but on Vista, the user process gets an Access Denied on its CreateFile call.

Any help you-all can provide would be most welcome.

The first method I used was fairly straightforward:

SECURITY_DESCRIPTOR sd;

::InitializeSecurityDescriptor( &sd,SECURITY_DESCRIPTOR_REVISION );

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

SECURITY_ATTRIBUTES sa = { sizeof(SECURITY_ATTRIBUTES),

&sd,

FALSE };

And the second one more complex, provided by another developer:

CSharedSecurityDescriptor sd;

if ( !sd.Init() )

{

DWORD dw = ::GetLastError();

ReportMessage("Could not init security descriptor", true);

return 1;

}

SECURITY_ATTRIBUTES sa = {sizeof sa, &sd, FALSE};

class CSharedSecurityDescriptor : public SECURITY_DESCRIPTOR

{

public:

CSharedSecurityDescriptor()

{

Dacl = NULL;

}

bool Init(void)

{

if ( !InitializeSecurityDescriptor( this, SECURITY_DESCRIPTOR_REVISION ) )

{

return false;

}

CWellKnownSID2 sidUsers(DOMAIN_ALIAS_RID_USERS);

CWellKnownSID2 sidAdmins(DOMAIN_ALIAS_RID_ADMINS);

DWORD nACLSize = sizeof(ACL) + ((sizeof(ACCESS_ALLOWED_ACE) - sizeof(DWORD) + sizeof(CWellKnownSID2)) * 3);

PACL pACL = (PACL)LocalAlloc(LPTR, nACLSize);

if ( pACL )

{

if ( InitializeAcl( pACL, nACLSize, ACL_REVISION) )

{

//do not use the EX version - ACE inheritance is not required.

if ( AddAccessAllowedAce( pACL, ACL_REVISION, GENERIC_ALL, &sidUsers ) &&

AddAccessAllowedAce( pACL, ACL_REVISION, GENERIC_ALL, &sidAdmins ) )

{

if ( SetSecurityDescriptorDacl( this, TRUE, pACL, FALSE ) )

{

return true;

}

LocalFree( pACL );

SetSecurityDescriptorDacl( this, TRUE, NULL, FALSE ); //set NULL DACL - allow all

return false;

}

return TRUE == SetSecurityDescriptorDacl( this, TRUE, NULL, FALSE ); //set NULL DACL - allow all

}

~CSharedSecurityDescriptor()

{

BOOL bPresent = FALSE, bDefaulted = TRUE;

PACL pACL = NULL;

if ( GetSecurityDescriptorDacl( this, &bPresent, &pACL, &bDefaulted ) )

{

if ( bPresent && !bDefaulted && pACL )

{

::LocalFree( pACL );

}

protected:

struct CWellKnownSID2 : public SID //a SID with 2 sub authorities

{

CWellKnownSID2( DWORD dwSecondSubAuth )

{

SecureZeroMemory( IdentifierAuthority.Value, sizeof(IdentifierAuthority.Value) );

Revision = SID_REVISION;

SubAuthorityCount = 2;

IdentifierAuthority.Value[5] = 5; //SECURITY_NT_AUTHORITY {0,0,0,0,5}

SubAuthority[0] = SECURITY_BUILTIN_DOMAIN_RID;

m_dwSecondSubAuth = dwSecondSubAuth;

};

DWORD m_dwSecondSubAuth;

};

re: Impact of Least Privilege in System Services

Peter.Delgado — Thu, 01 Feb 2007 01:12:03 GMT

I suggest that you simply add the group Everyone or some common group (more secure) to the dacl as follows (note the use of the ATL security classes which simplifies the procedure)

-Pete

CDacl daclPerm;

CSid sidEveryone = CreateWellKnownLocalSid ( WinWorldSid );

daclPerm.AddAllowedAce ( sidEveryone, GENERIC_ALL );

CSecurityDesc sd;

sd.SetDacl ( daclPerm );

CSecurityAttributes sa ( sd );

m_hPipe = ::CreateFile ( m_PipeName, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, &sa, OPEN_EXISTING, 0, NULL) ;

In addition, the code for the function CreateWellKnownLocalSid is as follows:

CSid CreateWellKnownLocalSid ( WELL_KNOWN_SID_TYPE WellKnownSidType )

{

CSid sidRet;

DWORD dwSize = SECURITY_MAX_SID_SIZE;

PSID pSid = ::_alloca ( dwSize );

if ( ::CreateWellKnownSid ( WellKnownSidType, NULL, pSid, &dwSize) )

{

sidRet = CSid (reinterpret_cast<const SID*>( (pSid ) ) );

}

return sidRet;

}

re: Impact of Least Privilege in System Services

brianwa84 — Thu, 15 Mar 2007 05:51:28 GMT

Echoing Antti, our software uses RegLoadKey to read/write to each user's registry on install/uninstall. Losing SeBackupPrivilege makes it so that our installer/uninstaller can only successfully install/uninstall for the current user, even when MSI is running us from the LocalSystem account. I agree that numerous applications are likely to use RegLoadKey to perform some kind of per-user installation, and losing it will make MSI a much less useful installation mechanism.

re: Impact of Least Privilege in System Services

brianwa84 — Mon, 02 Apr 2007 10:50:04 GMT

Are there any changes to give any privileges back to the windows installer service, or will a better approach be to hack around it and/or use nsis or installshield or some other installation platform?

What changed in Windows Installer 4.5?

Windows Installer Team Blog — Fri, 02 May 2008 00:20:14 GMT

Apart from the feature work that we did in Windows Installer 4.5, we made a few changes to Windows Installer