I forrige del av denne artikkelserien, begynte jeg å forklare hva de ulike User Account Control relaterte innstillinger group policy gjøre. Selv om Windows Vista og Server 2008 tilbyr hundrevis flere gruppepolicyinnstillinger enn det var tilgjengelig i Windows XP og Windows Server 2003, innstillinger for brukerkontokontroll er blant de viktigste av de nye innstillingene, siden de kan fungere som en av datamaskinens primære forsvar mot malware. . I denne artikkelen vil jeg diskusjonen

User Account Control fortsette med å forklare de resterende innstillinger for brukerkontokontroll: Bare Heve Kjør som er signert og godkjent

Hvis du virkelig stoppe opp og tenke på det , den viktigste grunnen for å ha brukerkontoen kontroller i første omgang er å hindre klarert kode kjøres på arbeidsstasjoner i nettverket. Selvfølgelig er dette reiser spørsmålet om hvordan du kan avgjøre hvorvidt koden skal være klarert.

En vanlig måte å avgjøre hvorvidt koden skal være klarert, er å se på koden digitale signatur. Mange (men ikke alle) programvare utgivere signere koden sin for å bevise at koden ble skapt av utgiveren, og ikke av noen prøver å svindle utgivers identitet. Den digitale signaturen beviser også at koden ikke er blitt endret siden den ble signert.

Bare fordi en del av koden er signert betyr ikke nødvendigvis at koden er troverdig. Det er fortsatt opp til deg å bestemme om du stoler på utgiveren som signerte koden. Som du ta avgjørelser om hvilke utgivere du stoler på, kan disse utgivere legges til Windows Trusted Publisher butikken

Det er der Brukerkontokontroll. Bare Heve Kjør som er signert og godkjent gruppepolicyinnstillingen kommer inn i bildet . Når den er aktivert, utfører denne gruppen policyinnstillingen PKI signatur kontroller mot en interaktiv applikasjon som ber om heving av privilegier. Hvis et program er signert av en klarert utgiver (utgiver er oppført i Trusted Publisher Store) da rettighets forespørselen er godkjent. Dersom koden er usignert eller er signert av en utgiver som du ikke har valgt å stole på, da rettighets forespørselen er avvist.

En ting å huske på at i henhold til dokumentasjonen Microsoft, denne gruppen policyinnstillingen gjelder bare for interaktive applikasjoner. Det betyr at ting som tjenester og skript som kjører usynlig, bak kulissene ikke er berørt av denne politikken innstillingen hvis dokumentasjonen er korrekt

User Account Control. Bare Elevate UIAccess programmer som er installert på sikre steder

Denne spesielle innstillingen er litt vanskelig for alle som ikke er en utvikler, men jeg vil forklare det så enkelt som jeg muligens kan.

Nå vet du at når en bruker utfører en oppgave som krever administrative rettigheter, deretter Vista standard oppførsel er å vise en rettighetsutvidelse spørsmål til brukeren. Det du kanskje ikke vet om er at Vista beskytter dialogboks med meldingen fra kryssplattform kommunikasjon. På den måten kan en ondsinnet applikasjon ikke simulere brukerundersøkelser og gi rettighetsutvidelse til seg selv.

Selv om denne dialogboksen og noen av de andre Windows-dialogbokser (slik som den som ber brukeren om å trykke Ctrl + Alt + Delete for å logge på) er beskyttet av operativsystemet, er det noen situasjoner der en applikasjon har et legitimt behov for å kommunisere med disse ellers beskyttede dialogbokser.

For å få tilgang til disse beskyttede dialogbokser, må det søkes utformet for å inkludere et manifest fil som inneholder følgende attributt:

UIAccess = TRUE
< P> Problemet med å bruke denne egenskapen i et program er at det tillater programmet å fullstendig undergrave noen av Vistas innebygde sikkerhet. Det er der Brukerkontokontroll: Bare Elevate UIAccess programmer som er installert på sikre steder innstillingen kommer inn i bildet

Tanken er at du ikke bare ønsker noe program for å kunne bruke den UIAccess = sant. Egenskap. Hvis du bare blindt tillatt dette attributtet som skal brukes, så malware forfattere kunne bruke attributtet innen malware som en mekanisme for å utnytte systemet. En bedre tilnærming er å bare tillate troverdige programmer for å bruke denne egenskapen. En måte å sørge for at det skjer er å kun tillate programmer å bruke UIAccess = true attributt hvis de befinner seg på et sikkert sted.

Det er bare noen få steder som Windows behandler som sikker. Disse inkluderer \\ Program Files og \\ Windows \\ System32. 64-biters versjoner av Windows også behandle \\ Program Files (x86) mappen som å være sikker. Underkataloger under noen av disse stedene er også behandlet som å være sikker

User Account Control. Kjør Alle administratorer i modus for administratorgodkjenning

Du har sikkert hørt folk si at i Windows Vista, selv administratorer er behandles som vanlige brukere. Dette er gruppen policy innstilling som gjør at utsagnet sant. Denne innstillingen, som er aktivert som standard, fører administratorer å operere med et redusert sett med rettigheter. Hver gang en administrator utfører en handling som krever bruk av administrative privilegier, er administratoren bedt om å godkjenne heving av privilegier før handlingen utføres

User Account Control. Bytt til Secure Desktop Når bekreftelse for Elevation

Hvis du noen gang har mottatt en rettighetsutvidelse tekst i Windows Vista, har du sannsynligvis lagt merke til at hele skjermen gikk mørkt, og at det eneste vinduet som ikke ble formørket var rettighetstekst. Når en melding vises på denne måten, er det sagt å være vise på en sikker bordet.

Grunnen til at Microsoft bruker sikkert skrivebord er fordi det er så mange typer malware som skaper falske Windows dialogbokser i en forsøk på å lure brukere til å klikke på noe. Når operativsystemet svart ut hele skrivebordet og vise bare en heving av tilgangsteksten, er det designet for å gi brukerne tillit til at meldingen virkelig kommer fra Windows-operativsystemet, og ikke fra malware som etterligner et operativsystem teksten.

Som standard er heving av rettighetsmeldingene alltid vises på en sikker desktop. Du kan deaktivere sikre skrivebordet selv, ved å deaktivere denne gruppen policyinnstillingen

User Account Control. Virtual filer og registre Write Failures til Per Bruker Steder

Den siste av de innstillinger for brukerkontokontroll er Brukerkontokontroll: Virtual filer og registre Write Failures til Per Bruker Steder innstilling. Du har sikkert hørt folk si at mange programmer som kjørte godt under Windows XP og eldre versjoner av Windows ikke kjører i Vista på grunn av de nye sikkerhetsfunksjonene. Ofte dette utsagnet er sant, fordi et stort antall eldre applikasjoner anta at brukeren har full kontroll over det lokale operativsystemet. I Windows Vista selv administratorer ikke behandles som administratorer som standard, og dette fører til en rekke programmer for å bryte.

For å komme rundt noen av problemene knyttet til de nye sikkerhetsinnstillinger, Microsoft laget denne gruppen policyinnstillingen. Den grunnleggende ideen er at eldre applikasjoner har en tendens til å skrive data til nå forbudte områder av filsystemet og registeret. Når denne gruppen policyinnstillingen er aktivert (det er aktivert som standard), blir disse skriver mottatt og videresendt til et annet sted. Dette gjør at eldre programmer til å kjøre uten at operativsystemets integritet.

Konklusjon

Som du kan se, innstillinger for brukerkontokontroll er avgjørende for å opprettholde Vista sikkerhet. I del 5, vil jeg fortsette serien ved å utforske noen av de andre områdene hvor Microsoft har gjort endringer i gruppepolicyinnstillinger. Anmeldelser