Gå til innhold

UAC får stryk av Sophos


Anbefalte innlegg

Men, skal vi se. UAC har egentlig ikke vært helt på topp siden den om. Den skaper problemer for alle... Men vi skal se litt på dette, så er det faktisk Sophos som kommer med dette... et egentlig dårlig stykke anti-virus og firewall program... jeg mener hvor mange programmer har dere vært borti som sier følgende: Successfully cleaned file for infection. og søker du samme fil engang til så er viruset der fortsatt... Og firewallen tar knekken på TCP/IP når den aktiviseres.... Ja ja, sophos kan vifte fingeren i mot MS for UAC. Men vi Brukere burde vifte fingeren mot Sophos for den dritten de selger...

Lenke til kommentar
Videoannonse
Annonse

Kult å se att det er mange oppegående mennesker på forumet. Som mange av dere sier: UAC er til for å tillate standardbrukere for å kunne gjøre admin oppgaver. Det er ikke en sikkerhetsmekanisme. Derimot så er det sikrere å kjøre som standardbruker vs. adminbruker og UAC muliggjør dette. :)

 

Sophos "rapporten" er helt fjern, vil anbefale alle å lese kilden. De tok de 10 siste unike "threats" som ble oppdaget og kjørte det mot Win7... De sier ingenting (som jeg finner) om hva de forskjellige "threats"'ene gjør eller hvordan de virker.

 

Microsoft selv påpeker att man bør bruke antivirus på Windows7, f.eks. Security Essentials (fantastisk program). :)

Lenke til kommentar

Jeg kjører x64 xp hjemme og har da verken UAC, noe antivirus eller noe annet lignende.

Jeg bare har deaktivert de forskjellige sikkerhetshull, porter og enkelte funksjoner som .VBS scripting og lignende, som jeg har lagret snarveier for å raskt re-aktivere om jeg skulle ha behov for det, hvilket jeg forsåvidt aldri/sjelden har. Det vil si den standard konfigurasjonen som er i Windows åpner for mange muligheter og måter å utnytte systemet på, jeg tviler på det er så annerledes i W7, var det ikke i vista ihvertfall - men om man tar seg litt tid til å gå igjennom hva som er aktivert og lager noen registry/batch filer for å tweake systemet, så er faktisk det meste gjort mht sikkerhet på programmer/nett bruk.

 

Det er ikke nødvendig å gå helt stokk over stein om du bruker nettet trygt og vet noen lunde hva du gjør på.

Lenke til kommentar

Problemet er jo det at å bruke PC er som å kjøre fort rundt en bane som Nurburgringen.

Vi her på HW er generelt sett racing bil førere, vi vet hvordan landet ligger, vi kan banen, vi vet når vi må bremse, når vi skal gi på etc etc og vi holder oss på banen.

 

Mens nybegynnerne og de som ikke kan å bruke PC er de som soper ut i første sving og får problemene og svineriet og blir overkjørt.

UAC og anti virus programmer har en tendens til å bli som traction control systemene, vi misliker de, det er svært sjelden vi trenger sånt.

 

Har selv svært sjeldent vært borti virus på egen maskin, men blir kallt inn til taue opp de som har sopet ut av banen kan man si.

UAC blir nok koblet ut hos meg på første dagen, pluss diverse annet sikkerhets dill dall.

Tross alt, de fleste her kan gjøre det helt trygt, bare man klarer å holde seg i skinnet og vet hvor man setter føttene sine.

I tilegg så vil jeg tro at de fleste har ruterne i de "Proffe" sine hjem er satt opp til å ikke være så glad i å svare på ping og da blir det straks vanskeligere og du er ikke ett attraktivt mål for programmer som utnytter sikkerhetshull osv.

Lenke til kommentar
Jeg synes at følgende løsning er en langt mer opplysende måte å kjøre med administratorrettigheter. Noe sånt må da MS ha kunnet implementert f.eks på toppen av skrivebordet, i stedet for en boks man bare trykker Ja/Nei på.

post-30930-1257374358_thumb.png

Bildet viser ikke hvordan økingen av tilgangsnivå foregår. I GNU/Linux er dette vanlig å gjøre gjennom et eller annet grensesnitt mot sudo.

 

Som standard vil ikke sudo spørre om passord i en periode etter første autorisering/autentisering. I mellomtiden kan et et ondsinnet program som kjører på samme tty, pts eller X-terminal - uten hindring - gjøre skade. Man kan deaktivere "friperioden", men da står man ikke igjen med noe annet enn en litt mer fleksibel su.

 

UAC-dialogen dukker allerede opp som en egen, isolert prosess slik at ingen trojaner skal få muligheten til å enten endre på dialogen eller snappe opp passordet.

Lenke til kommentar
Som standard vil ikke sudo spørre om passord i en periode etter første autorisering/autentisering. I mellomtiden kan et et ondsinnet program som kjører på samme tty, pts eller X-terminal - uten hindring - gjøre skade. Man kan deaktivere "friperioden", men da står man ikke igjen med noe annet enn en litt mer fleksibel su.

 

Kilde?

 

UAC-dialogen dukker allerede opp som en egen, isolert prosess slik at ingen trojaner skal få muligheten til å enten endre på dialogen eller snappe opp passordet.

 

Phhhf, det er problemet. UAC popper opp, INGENTING skal poppe opp uten at du faktisk har gjordt noe.

Lenke til kommentar

I Vista slo jeg alltid UAC av, fordi den reagerte dårlig i tide og utide, og ofte fikk installasjoner til å "henge" før UAC popper opp og man får startet.

I Win7 har jeg den på default, da den først plager meg når jeg initierer en installasjon (og nesten bare da) og ellers fungerer slik rettighetsforhøyning SKAL fungere.

Lenke til kommentar
Kilde?

Rimelig spørsmål.

Jeg tar det fra manualen til sudo:

(...)Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (15 minutes unless overridden in sudoers).

Med andre ord blir adgangstoken med berettigelsesbevis lagret, slik at autentisering ikke er nødvendig i dette tidsintervallet.

 

Heldigvis kan brukeren selv fjerne denne vha. sudo -k. Logging av kommandoer kan en angriper deaktivere ved å kjøre sudo su.

 

Fra manualen til sudoers finner du forklaringen på direktivene requiretty og tty_tickets. Er ikke førstnevnte aktivert så kan en bruker som er innlogget gjennom SSH benytte seg av en sudo-ticket som har blitt opprettet lokalt (men ikke er foreldet). tty_tickets er på som standard og fører til atferd jeg nevnte i forrige post angående tilknytning til terminal.

 

Problemet formildes noe ved at det ikke er mulig å se om en slik ticket eksisterer fra før. Dermed risikerer det ondsinnede programmet å få sudo-forsøkene logget.

 

UAC-dialogen dukker allerede opp som en egen, isolert prosess slik at ingen trojaner skal få muligheten til å enten endre på dialogen eller snappe opp passordet.

 

Phhhf, det er problemet. UAC popper opp, INGENTING skal poppe opp uten at du faktisk har gjordt noe.

UAC-dialogen dukker opp hver gang et program krever en Administrator-token eller en installasjonsfil kjøres (mønstermatching ift. filnavn, så denne kan feile hvis setup-filen har et annet navn). Påkrevd rettighetsnivå kan også settes i programfilen, for de programmer som er laget mtp. Vista og nyere. For andre programmer, så må UAC rett og slett bruke en form for heuristikk for å gjette seg til om programmet krever administratorrettigheter for å ikke feile spektakulært. I forhold til setup-filer så er dette ofte et dumt trekk, siden man ikke får noe valg om å kjøre installasjonen som vanlig bruker.

 

På en annen side så er det også greit at operativsystemet gjør en innsats for å gi brukeren tilbakemelding på at en handling krever flere rettigheter, istedenfor å gjøre det på *nix-måten: Det ikke skjer noe som helst, og brukeren lurer på hvorfor i helvete endringer utført gjennom et GUI-program ikke gjenspeiles i filsystemet. Heldigvis så ser det ut til at PolicyKit vil bli mer utbredt i fremtiden, noe som gjør det mulig å ha finkornet kontroll over de enkelthandlingene som krever ekstra rettigheter der programmene har støtte for dette.

Lenke til kommentar

Jeg logget inn som root, så virkemåten til sudo er i utgangspunktet ikke aktuelt i den sammenhengen, selv om det helt klart er et interessant tema.

Poenget mitt var at brukeren burde vært opplyst om at han kjører som administrator så lenge han har administrator-rettigheter. Systemet med å bare få opp en ja/nei-boks som deretter forsvinner er i mine øyne ikke noen god beskyttelse mot hva brukeren selv kan finne på. Erfaringsmessig er det vel brukeren som skaper flesteparten av problemene, og ikke diverse svakheter og hull. Derfor tror jeg at det ville vært bedre med en tydelig opplysende rød firkant (eller noe liknende) en eller annen plass på skjermen slik at brukeren faktisk er klar over hva han kjører som og hva det kan medføre.

Lenke til kommentar
Med andre ord blir adgangstoken med berettigelsesbevis lagret, slik at autentisering ikke er nødvendig i dette tidsintervallet.

 

Heldigvis kan brukeren selv fjerne denne vha. sudo -k. Logging av kommandoer kan en angriper deaktivere ved å kjøre sudo su.

 

Fra manualen til sudoers finner du forklaringen på direktivene requiretty og tty_tickets. Er ikke førstnevnte aktivert så kan en bruker som er innlogget gjennom SSH benytte seg av en sudo-ticket som har blitt opprettet lokalt (men ikke er foreldet). tty_tickets er på som standard og fører til atferd jeg nevnte i forrige post angående tilknytning til terminal.

 

Problemet formildes noe ved at det ikke er mulig å se om en slik ticket eksisterer fra før. Dermed risikerer det ondsinnede programmet å få sudo-forsøkene logget.

 

Jeg ser problemet, men det er en ting da: Dette krevet at applikasjonen klarer å få til å skaffe rettigheter til å kjøre fra brukerns konto, der er ikke å stand til å gjøre dette eksternt :p

Men du har et godt poeng uansett.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...