Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Lug Giu Mag Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen
Peccato e redenzione

Mentre lavoricchiavo alla mia piattaforma di blogging (che ha già pure un nome!) è saltato fuori un peccato mortale:

Peccato

Per fortuna c'è stata la redenzione immediata:

redenzione

-quack

Technorati tags:

Pubblicato mercoledì 6 febbraio 2008 alle 4:14 PM - 5 commenti so far
Archiviato in: Codice, Cazzate

Grazie Drummond!

ms-yahooSabato scorso ad una cena con amici mi è stata posta la fatidica domanda su che ne penso dell'OPA di MS su Yahoo. Sabato scorso la mia opinione era sintetizzabile come "non lo so/non so se per Microsoft l'OPA sia cosa buona, solo il futuro ci dirà". Non pensavo solo al collasso delle azioni, che in prospettiva del merge rimane un giochetto finanziario a somma algebrica zero. Semplicemente non avevo elementi per farmi una mia opinione, non sempre allineata: mi piace immaginare che da lassù, negli uffici dei CEO, il punto di Vista è così completo che anche mosse bizzarre hanno un senso molto pratico.

Due giorni fa invece è apparso questo post di David Drummond, Senior Vice President, Corporate Development and Chief Legal Officer in Google. In sintesi dice che Google ne pensa tutto il male possibile, che questo merge non sa' dda' fa', che il monopolio blah blah blah, ecc.

Grazie David, il tuo post ha sciolto tutti miei dubbi! Di una cosa da azionista MS sono arciconvinto: ogni volta che Google frigna, vuol dire che la rotta intrapresa è quella giusta; sperando ora che l'affare vada in porto. Aldilà del fatto, che proprio in virtù dell'acquisizione di DoubleClick, stavolta non c'è niente da frignare. Vero David? Wink

-quack

disclaimer: questo post, come del resto tutti gli altri, rappresenta le opinioni libere di un azionista MSFT e non sono collegate in nessuna forma o maniera a posizioni ufficiali delle compagnie menzionate (Google, Yahoo e Microsoft)

Technorati Tags:

Pubblicato martedì 5 febbraio 2008 alle 8:46 PM - 6 commenti so far
Archiviato in: Microsoft, Google, Cazzate

La magia dietro UAC

Diciamolo, la feature che mi piace di più di Vista è UAC. Recentemente ho ripetuto più volte che il comportamento di default di Windows XP, di assegnare poteri immensi a tutte le applicazioni, è dannoso non solo tenendo in mente la prospettiva del malware. Un'applicazione normale, per colpa di qualche bug, potrebbe accidentalmente sovrascrivere tutti i settori dell'hard disk riempiendoli di 0. Siccome l'ho visto accadere coi miei occhi in una macchina virtuale, la possibilità che questo accada nella mia testa è stata riqualificata come "pratica" anziché solo "teorica".

Su UAC ci sarebbe ben poco da aggiungere, soprattutto dopo il post esauriente di Vik sull'argomento, ma lo scopo di questo post è di chiarire cosa avviene under the cover e di fare alcune considerazioni su due modi diversi di loggarsi in Vista.

Uno dei punti del contendere più spesso dibattuti[1] a riguardo è se convenga sia dal punto di vista della sicurezza che dell'usabilità loggarsi come amministratore (non necessariamente Administrator ma inteso come utente appartenente al gruppo degli amministratori; d'ora in poi SuperPippo) oppure come utente normale (Pippo) avendo avuto l'accortezza di creare un utente aggiuntivo di amministrazione.

Un'analisi delle differenze può aiutare a decidere meglio:

  • ai fini di ottenere l'elevazione, se ci si logga come SuperPippo (in gergo Admin Approval Mode o AAM), di default appare il cosiddetto prompt "Mi Consenta" dove basta cliccare "Continue" per proseguire:
    UAC Consenta 
    Nel caso ci si è loggati come Pippo, è necessario digitare la password di SuperPippo (o altro utente Admin) per proseguire, nello stesso gergo Over The Shoulder (OTS) authentication:
    UAC Password
  • Nel caso in cui ci si logghi come Pippo, un processo che ottiene elevazione, girerà con le credenziali di SuperPippo. Se ad esempio crea un file in %Documents% il file verrà scritto nella cartella Documents di SuperPippo e non di Pippo come ci si potrebbe aspettare!

Se il primo dei due punti può rappresentare un piccolo vantaggio in termini di sicurezza (password invece che un click magari maldestro), il secondo è decisamente uno svantaggio in termini di usabilità. È però possibile loggarsi come SuperPippo e fare in modo che anziché un prompt "Mi Consenta", si venga accolti con una richiesta di password, tramite un setting disponibile via Local Security Policy:

SecPol

In realtà per i super-paranoici è possibile richiedere il three-finger-salute (CTRL+ALT+DEL) prima del prompt "Mi Consenta" o richiesta di password, tramite l'apposita opzione nelle group policy:

TrustedPath

Questa era addirittura l'opzione di default nelle prime beta di Vista, abbandonata precocemente per motivi di usabilità. Interessante è un post di Jim Allchin che dettaglia tutti i motivi che anno portato a tutte le attuali scelte di default.

Il migliore dei mondi possibili (unico utente SuperPippo, ma richiesta di password anziché "Mi Consenta") è perció solo ad una manciata di click di configurazione.

Ma dal punto di vista della sicurezza, cosa cambia tra quando ci si logga come SuperPippo e quando ci si logga come Pippo? Assolutamente niente[2].

Un facile esperimento è quello di loggarsi come SuperPippo, aprire un Command Prompt non elevato e cercare di scrivere in %SYSTEM%: il risultato è quello di Access Denied. Se si tenta l'operazione da un Command Prompt elevato, l'operazione va complessivamente in porto.

Come avviene la magia che da il titolo a questo post? Cosa succede a SuperPippo se l'AAM è attivato? Perché l'amministratore non riesce ad accedere in scrittura a folder che sono accessibili all'amministratore?

Il trucco è semplice. Nel momento in cui ci si logga come SuperPippo in AAM, il sistema crea un token[3] secondario (detto anche split-token) rimuovendo alcuni permessi associati al token dell'amministratore. I permessi che vengono rimossi sono indicati in questa pagina MSDN. Qui di sotto la differenza di permessi tra i due token, quello usato per processi che richiedono elevazione e quello usato per tutto il resto delle operazioni:

Split Token

Inoltre, e questo è il punto fondamentale per capire cosa succede quando si accede ad un file, il SID associato al gruppo Amministratori è marcato come Deny  come si può notare da questa figura:

SID

Questo significa che l'utente SuperPippo verrà considerato appartenente al gruppo degli Amministratori solamente in caso di matching di ACE di tipo Deny. Normalmente invece l'accesso ai folder per gli Amministratori è definito da una ACE di tipo Allow, per cui a tutti gli effetti, il token secondario di SuperPippo, quello usato di default, è il token di un utente "normale". Questo meccanismo accoppiato con le ACL più aggressive per default di Vista (dettagliate in questo interessantissimo articolo su TechNet) rende di fatto SuperPippo un utente normale. Ergo affermazioni come la seguente sono palesemente false:

Con Vista Microsoft prosegue con la politica di “tutti amministratori”, laddove i controllori di identità (UAC) si limitano ad evitare che un malware ne approfitti

In realtà con Vista si persegue la politica opposta: "nessun amministratore", con l'antipaticissimo UAC a tenere le chiavi del paradiso proibito.

Conclusione: tra loggarsi come SuperPippo (AAM) e loggarsi come Pippo (OTS) non c'è nessuna differenza a livello di sicurezza: se si preferisce il prompt con la richiesta di password, basta cambiare una policy per ottenere lo stesso effetto. Dal punto di vista pratico però, la modalità AAM ha qualche piccolo vantaggio di usabilità. Un ulteriore consiglio da tenere in mente, se si preferisce la modalità AAM, è quello di creare comunque un account amministrativo secondario in caso di disaster recovery.

-quack

Technorati tags: ,


[1] Si veda ad esempio questo post di Jeff Atwood alquanto critico nei confronti di Vista: Microsoft didn't have the guts to make standard users the default-- as they absolutely should have-- in Windows Vista.

[2] Cioé la differenza tra autenticazione AAM (mi loggo come SuperPippo e inserisco una password o clicco consenta) e OTS (mi loggo come Pippo e inserisco la password di SuperPippo) è nulla in quanto UAC non costituisce un security boundary. Si veda questo interessante post di Russinovich, tenendo presente che uno squatting attack è estremamente complicato da portare a compimento.

[3] Un token è un oggetto di sistema che rappresenta un set di privilegi.

Pubblicato lunedì 4 febbraio 2008 alle 4:22 PM - 35 commenti so far
Archiviato in: Windows, Security

Pessima figura

Non è una notizia recente ma non per questo per chi la scopre adesso (come il sottoscritto) è meno divertente. Poco più di tre mesi fa il blog di Kim Cameron padre di CardSpace ed esperto di sicurezza a cui avevo accennato in questo post, è stato defaced. La notizia è stata subito ripresa e presentata come uno smacco per Microsoft in questo post di Zdnet.

Hacked

Quasi immediatamente è partito l'assalto dei troll e giù epiteti inqualificabili su Windows Server, IIS e tutto il web stack Microsoft.

Ma la pessima figura non è stata quella di Kim, ma di chi in tutta fretta per sputare veleno inutilmente non si è accorto che il blog di Cameron gira su uno stack BAMPW (BSD -Apache - MySQL - PHP - WordPress). Kim non ha perso occasione di fare ironia in un post sull'argomento che consiglio caldamente non solo per alcuni commenti spassosi degni del miglior talebanesimo informatico (se un blog Wordpress viene defaced per qualcuno è più facile credere che girasse su stack MS fino a qualche minuto prima e spostato ad arte dopo l'incidente che ad un baco Wordpress documentato!) ma per il suggerimento finale, una vera lezione di sicurezza coi fiocchi come solo un esperto può impartire; oltre a confermare che certi commenti finescono inevitabilmente per essere più deleteri per chi li scrive che per il target che vogliono colpire.

In questo mio post invece non c'è nessuna dietrologia: non mi piace WordPress per tanti altri svariati motivi ma non esiterei a sceglierlo come piattaforma di blog se davvero corrispondesse almeno in buona parte alle mie esigenze; e se lo facessi - come dimostra uno dei tanti commenti all'incidente - ci sarebbe sempre qualcuno che giustificherebbe la mia scelta come una colpa della concorrenza; pensiero che può essere sintetizzato con una frase rubata da un titolo di giornale di tanti anni fa: Piove, opposizione ladra!

Però non posso fare a meno di osservare che l'episodio corrobora un paio di teorie riguardo la sicurezza che condivido totalmente. Ringrazio Luca per avermi passato il link; questa perla mi era incredibilmente sfuggita.

-quack

Technorati tags: , ,

Pubblicato domenica 3 febbraio 2008 alle 6:40 PM - 8 commenti so far
Archiviato in: Cazzate, Security

PowerShell: parliamone serenamente

Rubo il titolo ad un già citato post di Enrico, per parlare stavolta di PowerShell visto che è stata più volte citata nei commenti di questo blog.

Powershell Non sono un esperto di Command Line Interface (CLI o shell), non sono mai stato un sys-admin in vita mia, e perciò mi limiterò ad un paio di osservazioni di superficie.

Prima osservazione: le shell non dovrebbero essere intese come strumenti per l'utente finale.

Se a molti può sembrare ovvio, ad alcuni può sembrare una bestemmia. Credo che i nerd che abbiano imparato ad usare *nix nei vecchi laboratori dell'Università siano quelli che considerano la mia affermazione una bestemmia, abituati com'erano al solo accesso terminale. Nel lab di calcolo numerico dell'Università di Bari, nel 1992 circa, era l'unico modo di usare *nix: i pochi terminali "grafici" erano in grado solo di mostrare un'anteprima di plotting. Niente mouse, niente finestre, ma solo editor e shell testuali. Anche il DOS aveva una shell molto primitiva (Command.com) in grado di supportare loop e altre amenità, ma impallidiva a confronto delle possibilità offerte dalla Bash shell.

Seconda osservazione: le UI non dovrebbero essere intese come strumenti per l'amministrazione in larga scala

Il sys-admin non deve cliccare sulla check-box della UI di ogni singola macchina per fare il deploy di qualche policy. Qualcuno potrebbe pensare che un sistema come Windows basato prevalentemente su UI, avesse scarsissime capacità di shell scripting. Che il sys-admin Windows sia insomma costretto ad impossibili acrobazie grafiche. Niente di più scorretto, vista la combinazione di:

  • modalità Console alias Command Prompt (erede del vecchio command.com) in grado di interpretare file batch (.BAT) e command (.CMD) di bassa complessità
  • linguaggi di scripting come VBScript, disponibili in modalità Console tramite "plug-in" come Windows Scripting Host
  • layer di sistema apposito, Windows Management Instrumentation (WMI), che espone le funzionalità di alcuni componenti di sistema ai vari linguaggi di scripting
  • laddove non arriva WMI, occorre scrivere una applet Console nel proprio linguaggio di programmazione preferito (C/C++/Pascal/ecc.)

In parole povere, affermare che non si possa amministrare Windows via scripting in nessun modo, è perlomeno falso. Questo non vuol dire però la combinazione di cui sopra sia una soluzione ottimale o comparabile con altre shell tradizionali. Per colmare questa lacuna è stato rilasciato, il 30 Gennaio 2007, una nuova CLI chiamata appunto PowerShell. Power non per caso perché si integra completamente con il framework .Net. Inizialmente il piano era di rilasciare PowerShell integrandolo in Vista e come download separato per le altre piattaforme (XP e Win2k3), però motivi logistici hanno portato ad una soluzione diversa. Sarà però rilasciato come componente integrato, seppur opzionale, di Windows Server 2008.

Il numero di Maggio 2007 di Linux Magazine, dedica due pagine scritte con estrema chiarezza ad un confronto tra la Bash Shell e PowerShell. Riporto alcuni brani molto significativi:

New to the world of Windows is the way PowerShell regards everything as a filesystem and not only navigates the filesystem and drives, but the Registry, the certificate store, and environment variabels.
[...]
In PowerShell, all cmdlets  create defined objects as their output data instead of text-only output.
[...]
Although passing data objects is slightly more complex, this object orientation helps standardize operations and supports handling of complex data structures.
For example, Bash needs and external XML parser (like Saxon or Xalan-J) to parse XML files.
[...]
Bash is useful as a plain but straightforward tool for most daily tasks. If it comes to the need for advanced uses and complex data structures, you can branch out into object-oriented Python or the graphical capabilities of Tcl/Tk.

Conclusione:

PowerShell : Bash = Bash : WinConsole+VBScript+WMI

In poche parole non solo il gap è stato colmato, ma ne è stato creato uno più grosso nella direzione opposta: basti pensare alle possibilità offerte ed integrate in PowerShell, che in Bash richiedono tool esterni. Questa dicesi innovazione, parola di Linux Magazine, Maggio 2007.

-quack

P.S. è possibile rinominare 200 file già usando gli strumenti a disposizione con il Command Prompt senza neanche scomodare i vari linguaggi di scripting.

Technorati Tags:

Pubblicato venerdì 1 febbraio 2008 alle 3:45 PM - 15 commenti so far
Archiviato in: Codice