A Ovest Di Paperino

in un sistema che usa sudo l'amministratore è root(e quello non ci casca) ma anche chiunque sia nel gruppo admin(per default è questo ma si possono effettuare tutte le personalizzazioni che si vuole(/etc/sudoers è il file di configurazione)

ad esempio posso autorizzare ad eseguire un programma con i diritti ti amministrazione solo a chi appartiene al gruppo "firewall" e solo sui comandi del firewall. in tutti gli altri comandi restano utenti limitati

il tutto solo anteponendo sudo al comando stesso

in ogni caso anche senza sudo(oramai praticamente integrato in tutte le distribuzioni) si potrebbe fare grazie ai permessi ottali e ai gruppi: basta mettere i permessi giusti sui programmi di amministrazione e di sistema e inserire nei gruppi corretti gli utenti a cui si vuole far eseguire il comando

perciò sudo non colma nessuna lacuna, al massimo semplifica di molto la gestione degli utenti e dei permessi

inoltre sudo non equivale a far eseguire come root un programma ma come un generico altro utente(Switch User DO)

se non si specifica l'utente con l'opzione -u allora prende di default root come target

"""

L'implementazione per Windows, per me più immediatamente comprensibile, esegue il «gioco di prestigio» in questo modo: durante l'installazione del tool viene installato un servizio che gira con le credenziali di LocalSystem e che si pone in ascolto di «richieste» sudo. In presenza di una richiesta legittima il servizio aggiunge l'utente al gruppo degli amministratori, lancia il processo richiesto usando il nuovo token, e subito dopo rimuove l'utente dal gruppo.

"""

con tutto il rispetto, un porting che fa fare questo non è molto ortodosso, metti che un programma blocchi il ritiro dell'appartenenza al gruppo amministratori? cazzi amari

"""

La differenza con l'approccio UAC è evidente: con sudowin un qualsiasi utente potrebbe essere messo in grado di lanciare alcuni processi senza necessariamente essere parte del gruppo degli amministratori.

"""

come ho già detto sui sistemi unix può eseguire processi "dandoli" in proprietà ad un altro utente, non necessariamente root

non so se sul porting si possa fare, se no grave mancanza di chi ha fatto il porting visto che da windows 2000 in poi(che io mi ricordi) si può fare destro esegui come

ps paperino un sistema per quotare è indispensabile

Questo solo limitatamente al filesystem (o in generale ad "oggetti" a cui si può assegnare una ACL). In un OS ci sono "operazioni" che richiedono privilegi di amministratore ma che non hanno la possibilità di vedere assegnata una ACL

Teoricamente, visto che su unix tutto è un file, basterebbe considerare i permessi associati al file che rappresenta il processo. Non so però se esistono sistemi che sfruttano questa possibilità.

proviamo se ci riesco, al massimo me lo metti a posto tu?

Parlavo delle funzionalità "primitive" del sistema. Il concetto di gruppo di Amministratori è builtin in Windows mentre con *nix bisogna appunto usare sudo.

unix è una categoria

sudo è builtin in distribuzioni linux come ubuntu e anche in osx se non lo sapevi

Questo solo limitatamente al filesystem (o in generale ad "oggetti" a cui si può assegnare una ACL). In un OS ci sono "operazioni" che richiedono privilegi di amministratore ma che non hanno la possibilità di vedere assegnata una ACL: in Windows ad esempio la possibilità di far partire un servizio o di debuggare e scrivere nella memoria di un altro processo.

1 in unix tutto è un file

2 volendo si può pure andare a scrivere anche in kernel space

Questa non è una limitazione dell'implementazione, ma conferma il fatto che è molto pericoloso usare Sudo per dare selettivamente accesso alla impersonificazione (??) di root. Anche sotto *nix dare la possibilità di lanciare particolari applicazioni come root può aprire la porta ad EoP. Per questo dico che usare Sudo per lo scopo 2 richiede moooolta attenzione indipendentemente dalla piattaforma.

è proprio il contrario!!!

se io voglio che un mio sottoposto possa solo usare il comando che controlla il firewall sul mio sistema allora gli do i permessi di esecuzione solo su "iptables"

tanto per esempio

naturale che se faccio partire un programma che mi cancella tutta la / con le credenziali di root sono scemo...ma anche con windows e osx capita così. è normale visto che è amministratore DEVE poter far di tutto sul sistema, pure far bordello!

Un programma non può bloccare quello che fa LocalSystem ma chiaramente può ri-aggiungere l'utente al gruppo degli amministratori durante l'esecuzione. Questo è un corollario a quanto detto sopra. NON USATE SUDO/SUDOWIN per dare permessi ad utenti che NON DEVONO AMMINISTRARE IL PC.

infatti è per questo che ho detto che su windows il porting non è fatto molto bene

ps su unix esiste il file sudoers e non può essere modificato nemmeno da root, previ casini inimmaginabili, infatti ha permessi 400, e può essere toccato solo con una utility speciale, "visudo"

@gino

è normale visto che è amministratore DEVE poter far di tutto sul sistema, pure far bordello!

Su questo non sono d'accordo. Ci sono casi in cui l'amministratore non dovrebbe poter fare tutto e le responsabilità dovrebbero essere assegnate a soggetti differenti. Pensa al caso in cui un amministratore non dovrebbe poter accedere a certi file riservati. Del resto un amministratore è il responsabile della manutenzione e del corretto funzionamento del sistema, ma non di altro. Root invece, correggimi se sbaglio, può fare tutto. Per cui, a meno che non si introducano altri meccanismi, non è possibile limitare i poteri di root. Per questo si preferisce non usare root.

Questo è un punto debole dal punto di vista della sicurezza. Faccio un classico esempio: per montare un filesystem, ad esempio perché un utente ha la necessità di montare un volume remoto, è necessario avere i privilegi di root. Ma questo vuol dire che un eventuale buco nel filesystem potrebbe esser usato per acquisire i privilegi di root e quindi avere potere su tutto. Questo a meno di non montare il filesystem in userspace, come viene fatto nei sistemi tipo hurd o con fuse su unix.

@Paperino

Però sfugge il concetto di "primitiva". "Primitiva" è un'operazione disponibile nel "Core" dell'OS...

Cosa è core, cosa non è core, è opinabile. A me ad esempio piacciono i core molto ridotti, tipo L4, e per i sistemi in cui il core è l'insieme dei servizi a cui si da credito oppure, da un altro punto di vista, presso cui ci si accredita.

anche se teoricamente possibile, all'atto pratico diventa impossibile assegnare una ACL a qualsiasi "micro-risorsa"

Non capisco il problema. Devi comunque implementare un meccanismo per assegnare ACL a delle risorse. Le mappi nel filesystem ed hai un metodo uniforme per trattare i permessi.

Lo sapevo. Era per questo che parlavo di *nix. Però sfugge il concetto di "primitiva". "Primitiva" è un'operazione disponibile nel "Core" dell'OS (Kernel o qualche layer più in su). Proprio in quanto *nix ha bisogno di "Sudo" per esporre il concetto di "gruppo" dovrebbe far capire che, anche se Sudo fa parte di tutte le versioni *nix dal 1980 in poi, il "core" dell'OS conosce un unico amministratore (root).

falsissimo che i gruppi non sono nativi

in unix i permessi per gruppi sono NATIVI

il fatto che tutte le distro usino solo root come amministratore non preclude il fatto che impostando bene i permessi dei file di sistema ed assegnandoli al gruppo "amministratori" tanto per mettere un nome a caso tutti quelli in quel gruppo sono alla pari di root

Questo non vuol dire che tutto si può gestire con il sistema di permessi. Si pensi alla CPU, ai ring della CPU, alle operazioni di debug. Teoricamente si potrebbe fare, ma praticamente non si fa.

alla gestione della cpu?intendi a settare le priorità dei processi eccecc?

ussì che si può farla fare solo ad una categoria di utenti! mai sentito parlare di "nice"?

Questo lo fa anche SudoWin, davvero non vedo la differenza. La mia osservazione è che l'amministratore deve essere molto accorto nel scegliere quali applicazioni permettere ed ho fatto l'esempio di notepad che - seppur innocente - è una applicazione che sotto Sudo permette una EoP.

è possibile perchè sudowin è pur sempre un porting di sudo

a proposito: su windows posso dare in modo che doppiocliccando su un eseguibile(che non può essere modificato da utenti limitati) quello parta con privilegi amministrativi o di un altro utente che mi pare? e solo quel processo?

Il porting non centra niente. Se l'amministratore da il permesso all'applicazione sbagliata i problemi sono cross-platform. Unix o Windows, fa poca differenza.

mai detto il contrario

solo che con sudowin si può avere una eop anche con notepad come dici tu...

se mi rispondi alla domanda sopra ti pongo una riflessione

Stessa cosa per sudowin. Quello di "visudo" mi sembra un artificio teoricamente "inutile" Magari all'atto pratico serve semplicemente a scoraggiare ed evidentemente funziona.

non solo

su molte distro la password di root è "annullata"

man passwd alla voce -l

ed è abilitato solo sudo

se ti sbagli a modificare sudoers e lo sputtani addio root(infatti a me il modo di gestire i permessi su ubuntu ad esempio non piace) a meno di modificare /etc/passwd con una live o altri metodi esterni al sistema

Su questo non sono d'accordo. Ci sono casi in cui l'amministratore non dovrebbe poter fare tutto e le responsabilità dovrebbero essere assegnate a soggetti differenti. Pensa al caso in cui un amministratore non dovrebbe poter accedere a certi file riservati. Del resto un amministratore è il responsabile della manutenzione e del corretto funzionamento del sistema, ma non di altro. Root invece, correggimi se sbaglio, può fare tutto. Per cui, a meno che non si introducano altri meccanismi, non è possibile limitare i poteri di root. Per questo si preferisce non usare root.

l'amministratore DEVE poter far tutto, altrimenti non è amministratore

gli altri che devono fare compiti di gestione del sistema possono ricevere i permessi di fare solo limitate cose dall'amministratore che dovrà loggarsi solo ed esclusivamente per fare ciò e per i lavori normali sul sistema avere un account limitato come gli altri

è altresì falso che si debba avere i permessi di root per montare qualcosa

1 usare sudoers

2 modificare il suid bit all'eseguibile di mount

lo sapevi?

l'amministratore DEVE poter far tutto, altrimenti non è amministratore

Ti è sfuggito il senso delle mie parole. Se l'amministratore è root ed è il dio del sistema, può vedere tutto, anche cose che in certi contesti non dovrebbe vedere. In un'organizzazione alcune informazioni sono riservate ad un certo gruppo, ad esempio chi si occupa di problematiche di sicurezza del sito materiale. Questi soggetti non hanno competenze informatiche. Chi ha l'accesso all'account root del sistema che conserva queste informazioni in pratica ha l'accesso a queste informazioni riservate, a meno che non si provveda a proteggerle con altri meccanismi. Un soggetto con competenze informatiche dovrebbe aver accesso solo a ciò che è strettamente necessario per la sua attività. Viceversa, ci si deve fidare di lui anche per cose che non gli competono.

è altresì falso che si debba avere i permessi di root per montare qualcosa

1 usare sudoers

2 modificare il suid bit all'eseguibile di mount

-r-xr-xr-x 1 root wheel 48288 21 Gen 07:00 moun

Cioè, puoi richiamare mount, ma il comando viene eseguito con i permessi di root. Devi fare così. Ma se riesci ad iniettare del codice in mount, puoi praticamente fare tutto. E' giusto?

non proprio

su una ubuntu

ls -l `which mount`

-rwsr-xr-x 1 root root 81368 2008-04-15 05:36 /bin/mount

come vedi FDG il bit di esecuzione della prima tripletta(riservata a root) non è su x ma una lettera "nuova e diversa", s: il bit suid per l'appunto!

esiste anche il setgid per il gruppo che funziona sul gruppo se non è l'owner ad eseguirlo

se io cambio il gruppo(il secondo root è il gruppo) in montatori(lo so è brutto ) ad esempio(mi loggo come root anche se su ubuntu in modo predefinito non si può )

#chown root:montatori /bin/mount

e poi metto il setgid bit attivo

#chmod g+s /bin/mount

da quel punto lì tutti gli appartenenti al gruppo montatori potranno eseguire mount e in quel caso il comando partirà con i privilegi del proprietario, root in questo caso

un secondo modo era usare sudoers

in ogni modo se si inietta codice in mount allora si può fare tutto

ma iniettare codice in un file che non può essere scritto da nessuno al di fuori di root(vedere permessi) significa avere già i privilegi di root e allora tanto varrebbe

da quel punto lì tutti gli appartenenti al gruppo montatori potranno eseguire mount e in quel caso il comando partirà con i privilegi del proprietario, root in questo caso

Parlo proprio di questo. Forse non mi sono spiegato bene.

ma iniettare codice in un file che non può essere scritto da nessuno al di fuori di root(vedere permessi) significa avere già i privilegi di root

Poiché quel processo ha un input, cioè il volume montato in remoto, se qualcuno scopre che dando in pasto l'input opportuno... non c'è bisogno che ti spieghi il resto.

@ paperino:

La discussione si fa interessante: forse posso rispondere ad un paio di domande.

Quando Gino dice che tutto in *nix e' un file o e' accessibile come un file, non esagera: gli stessi processi e l'hardware sono mappati come dei file in file system virtuali, /dev, /proc e (dal kernel linux 2.6) /sys. La scrittura del flag si traddurrebbe nell'accedere a /sys/cpu0 oppure, tramite i2c, a /sys/bus/i2c/devices/cpu0 (spero di non avere fatto errori: nel caso, gino e' autorizzato a correggermi ;)) ed e' possibile solo a chi ha i diritti per farlo.

Non esiste un equivalente delle Dacl o delle Sacl poiche' puoi accedere a qualsiasi cosa come se fosse un file e, quindi, usare solo i permessi (grosso modo paragonabili alle Acl). In altri termini, se non puoi accederci come un file allora non esiste.

I permessi di gruppo: non l'ho capito completamente, ma questa e' la mia interpretazione.

Consentire il permesso di esecuzione con il setguid significa consentire ad un utente del gruppo "montatori" di eseguire mount con i privilegi di root. Come gino fa notare, il permesso e' solo di esecuzione: l'utente di "montatori" non puo' leggere o scrivere su mount; qualcosa di simile accade sotto Windows giocando con le Acl di cartelle e file contenuti in esse: equivale grossomodo a poter eseguire un file (quindi leggerlo, perche' in Windows l'esecuzione di un file e' subordinata alla lettura) in una cartella su cui non si hanno diritti di lettura (no ListFolder, si TraverseFolder).

Il mio dubbio e' semplice: se mount risulta vulnerabile (ad esempio) ad un attacco di buffer overflow, gli utenti di "montatori" possono sfruttare questa vulnerablita' per aprire una shell come root? Oppure no, perche' non hanno i diritti per accedere / eseguire la shell come root?

Edward

P.S.: ho solo un'infarinatura delle Acl, ma quel poco che so e' sufficiente per farmi venire il mal di testa. Paperino, non ti ha mai preoccpato la complessita' delle Control List?

Inoltre, c'e' un testo che le spieghi in modo chiaro e dettagliato?

Purtroppo ho l'impressione che il concetto di gruppo di utenti Windows non mappi uno ad uno con quello

correggimi se sbaglio ma per poter eseguire certe operazioni, che richiedono un certo tipo di permessi, su *nix bisogna alla fin fine "impersonare root".

direi che sbagli

per fare una certa cosa basta avere i permessi di scrittura sul file a cui quella cosa è associata

infatti come ti ha detto edward tutto è un file

dentro /proc( ci sono una serie di directory e file ad esempio) alcune directory hanno come "nome" dei numeri, che sono i pid dei processi in corso

se l'utente limitato gino fosse inserito nel gruppo admin ad esempio e quel file appartenesse al gruppo admin e avesse la tripletta su admin settata correttamente allora avrebbe i poteri di far quel che vuole con quel "file"

windows=una serie di utenti con privilegi simili ed elevati ed un'altra serie con privilegi limitati+un certo grado di personalizzazione

unix=un utente root+ quanti utenti voglio personalizzati come voglio

diciamo che sotto unix la personalizzazione è molto più libera, ma un pochino più complicata che in windows

sono punti di vista e di gusti vedere quale soluzione è più comoda

Se parli dell'equivalente di setuid, la risposta è no: è stata presa in considerazione la possibilità di avere un meccanismo simile per ridurre il numero dei prompt UAC ma è stata scartata per diversi motivi su cui potrei approfondire

voglio gli approfondimenti!

P.S. in tutta la discussione non mi interessa stabilire cosa è meglio o cosa è peggio (credo che sia non deterministico in questo caso). Mi interessa mettere in luce che cercare di portare dei concetti da una piattaforma all'altra in maniera semplicistica può avere sconcertanti effetti collaterali.

sono d'accordo, non è possibile dire quale è migliore(parlo di vista perchè sotto xp è un po' meno potente il senso di utenti con privilegi diversi vero? )

Quando Gino dice che tutto in *nix e' un file o e' accessibile come un file, non esagera: gli stessi processi e l'hardware sono mappati come dei file in file system virtuali, /dev, /proc e (dal kernel linux 2.6) /sys. La scrittura del flag si traddurrebbe nell'accedere a /sys/cpu0 oppure, tramite i2c, a /sys/bus/i2c/devices/cpu0 (spero di non avere fatto errori: nel caso, gino e' autorizzato a correggermi ;)) ed e' possibile solo a chi ha i diritti per farlo.

già già

Il mio dubbio e' semplice: se mount risulta vulnerabile (ad esempio) ad un attacco di buffer overflow, gli utenti di "montatori" possono sfruttare questa vulnerablita' per aprire una shell come root? Oppure no, perche' non hanno i diritti per accedere / eseguire la shell come root?

se un programma gira con il suid attivo e il proprietario è root e il programma è bacato allora si che si può sfruttare l'exploit per la shell di root

ma accade anche in windows e in osx

sarebbe per un ladro come fare aprire la finestra dal padrone di casa ed entrare da lì mentre sta parlando col vicino

io discordo qui

Un esempio su tutti emule, che su Windows aveva bisogno di "scrivere" in "C:\Program Files". Se in Vista ci fosse stato l'equivalente di setuid, molto probabilmente i programmatori di emule durante l'installazione non avrebbero fatto altro che settare il flag sull'eseguibile con buona pace del concetto di LUA.

il suid non c'entra niente!

è stata un problema, quello di scrivere in c:\programmi(notare come mi sia venuto spontaneo usare gli / invece che \ ), probabilmente voluto

amule, la versione che gira su unix, ad esempio ha sempre usato la cartella incoming come ~/.amule/incoming quindi una cartella scrivibile e di proprietà dell'utente che fa girare amule. in piena multiutenza

secondo me la "colpa" del fatto che amule scrivesse di default nella cartella di installazione risiede nel fatto che tutti facevano girare come amministratore(che è al pari di root in un certo senso) praticamente tutto, come tu hai già detto

quindi il suid bit non avrebbe avuto assolutamente colpe. bisogna prendersela con i programmatori di emule e degli altri programmi

voglio solo far notare che su unix invece praticamente nessun programma gira come root, apparte il kernel(e fin lì spero che concorderai con me che è cosa buona e giusta che il kernel possa fare quel che gli pare ) e le coreutils fatte partire da root stesso per sua decisione

su vista da quanto ho capito si sta cercando di migrare in questa direzione. per direzione intendo "come amministratore solo il minimo indispensabile"

cioè la colpa sarebbe di xp? ma lol non pensavo proprio che saremmo arrivati al punto che io difendessi xp e tu no

Credo che Vista sia il punto di arrivo di tale migrazione "forzata". Staremo a vedere in Windows 7.

punto di arrivo? secondo me si può fare sempre qualcosa di meglio

Andanto off topic con il thread e riagganciandomi su un pezzo del testo dell'articolo vorrei dire e far notare che il fatto che su Linux vi sia generalmente un solo amministratore e programmi come sudo sono stati introdotti solo un secondo tempo ha fatto si che tutti i programmi destinati agli utenti siano stati scritti per funzionare correttamente se avviati da utenti normali, con diritti limitati... cosa spesso non vera su Windows dove l'insana abitudine di creare su sistemi condivisi tanti diversi utenti tutti "Administrator" ha fatto si che molti programmi creiono problemi se sono avviati da utenti limitati.

Non solo freeware... potrei elencare alcuni gestionali famosi e parecchio costosi che non c'e' verso di farli girare da utenti limitati nemmeno dicendo a Windows di eseguire il programma come un'altro utente etc etc... nel mio lavoro ne vendo spesso, nelle aziende si software vitali con questo difetto e alla fine fai lavorae tutti come administrators perche' diversamente del PC non sarebbero che farsene.

Avere una politica rigida come avviene su Linux obbliga chi sviluppa a seguire gli schemi invece di programmare alla cavolo...

Volevo dire un'altra cosa riguardo il permesso speciale suid, ormai nei sistemi Linux e' pressoche' inutilizzato, anzi se lo setti certi programmi si incazzano come faine rifiutandosi di avviarsi o segnalando proprio che non sono progettati per girare con suid attivo.

Io l'unico modo che conosco per settare il suid su un file e' fare come root chmod +s file ... non capisco cosa intendi per api? Solo root puo' settare suid, gli utenti normali possono usare chmod solo sui loro file ma non gli e' permesso settare il suid e mi pare giusto cosi'.

Cmq mai visto il portachiavi di KDE, kwalletmanager, non so poi se e' uguale a quello del mac perche' con i mac ho avuto solo incontri abbastanza suyperficiali, tipo reinstalla e aggiorna o poco piu'.

Cmq kwalletmanager si integra nella systray di KDE e se attivo le apps KDE lo usano per memorizzarci tutte le password, da quelle degli instant messanger tipo kopete, alle pwd del programma di posta kmail, alle pwd dei siti che navighi con konqueror, alle chiavi WiFi etc... al primo login, appena il primo programma cerca di accedere al portafogli viene chiesta la pwd del portafogli, senza di quella sei tagliato fuori da tutti i programmi che usano qualche sorta di account. Potenzialmente si potrebbe usare anche per avviare programmi come amministratore in maniera comoda e diretta, pero' attualmente non viene fatto probabilmente solo per scelta, implementarlo in kdesu sarebbe banale. Attualmente kdesu e' integrato con sudo e se setti che un utente puo' avviare un certo programma grafico come root dentro sudo, esempio stupido YaST2, quando avvii l'icona di YaST2 (che lancia precisamente: kdesu YaST2) kdesu non ti chiede nemmeno la password, YaST2 parte direttamente... Io l'ho fatto tanto il computer lo uso solo io e mi rompeva mettere sempre la pass, ma non ci peso a farlo sui PC Linux che vendo ai miei clienti o che metto nelle ditte, agli utenti normali infatti spiego che se viene chiesta la password vuol dire che "devono stare attenti a cosa fanno perche' se la mettono e poi paciugano e fanno disastri dopo sono azzi loro" e la cosa funziona bene come promemoria. Mentre nelle ditte la segretaria che usa il PC solo per leggere la posta e scrivere una lettera con openoffice non deve paciugare e basta e le pass sono lasciate solo al titolare.

Se in Vista ci fosse stato l'equivalente di setuid, molto probabilmente i programmatori di emule durante l'installazione non avrebbero fatto altro che settare il flag sull'eseguibile con buona pace del concetto di LUA

Una sana gestione dell'attributo prevede che su un certo eseguibile può essere impostato solo da root. Quindi, se non sono root non posso farlo. Se faccio fare l'installazione del software a root, cioè l'installer è eseguito da root, allora posso farlo. Ovvero, perché l'installer dovrebbe essere eseguito da root?

è stata un problema, quello di scrivere in c:\programmi...

Mi pare che ci sia un problema di mentalità con cui ci si è dovuti scontrare: molti utenti windows che io conosco hanno ancora l'abitudine a mettere la propria roba sotto C:\, come se la directory dell'utente non esistesse.

Pero' convalida la teoria che i developer preferiscono le scorciatoie.

Lo stesso problema l'abbiamo avuto anche su Mac, dove col vecchio MacOS la home dell'utente era l'intero disco. Con l'arrivo di OS X, sono compare alcune applicazioni che pretendevano col permesso dell'amministratore di installarsi in / invece che in /Applications. Però per fortuna sono sparite rapidamente; ed erano pure poche, dati che i programmatori mac informati, per fortuna la maggioranza, sapevano che dovevano chiedere al sistema le directory da usare per i diversi scopi (sbaglio o questa cosa c'è pure su Windows dai tempi del 95/98?); e questo è tornato utile su OS X.

ormai nei sistemi Linux e' pressoche' inutilizzato

Come ho scritto prima (m'ero sbagliato nel citarlo come esempio di uso del suid), su OS X:

<cite>-r-xr-xr-x 1 root wheel 48288 21 Gen 07:00 mount</cite>

Cioè, manco mount è eseguito da root.

A questo punto mi chiedo come funzioni mount su OS X...

Qualcosa di simile al portachiavi di MacOS di cui sarei curioso dei dettagli tecnici

È un password managment system (e altri tipi di autorizzazione). Cioè, fornisce la password al posto tuo, dopo che l'hai sbloccato.

Su Vista sarebbe utile per evitare di annoiare gli utenti... pardon, è meglio che non ci sia, così i programmatori windows la smettono con certe brutte abitudini. Magari col 7 potreste pesare ad aggiungerlo.

Cmq kwalletmanager si integra nella systray di KDE e se attivo le apps KDE lo usano per memorizzarci tutte le password...

Esattamente. La prima versione del portachiavi fu vista su mac anni ed anni fa in una cosa che si chiamava PowerTalk... roba morta e sepolta da tempo.

Premesso che ci sono rarissimi "installer" che non richiedono permessi di root, tali permessi sono richiesti perché si vuole che l'applicazione sia visibile a "tutti". Questo è quello che accade di default.

Il mio utente non è root ma è un generico amministratore. Senza fare sudo riesco ad installare applicazioni visibili da tutti. Devo fare sudo solo se installo servizi. Credo quindi che il problema sia solo nel modo in cui sono usati i permessi e i gruppi.

Mi interessa più che altro capire a che livello dello stack interagisce. Se c'è qualche API, ecc. Per capire meglio quali sono i rischi e valutare pro/contro. E magari inventare un toolino alla stregua di SUDOWIN che faccia la stessa cosa (wallet-WIN)?

Quello che io so non è molto. Anzi, non ti fidare di quello che ti dico. C'è un'API che ti permette di interagire col keychain. L'API è usata sia dal sistema che dalle applicazioni per gestire le password di servizi non di sistema (mail, server di rete...). Non ho notato processi di sistema che possano essere associati al keychain in qualche modo, a parte securityd che però dovrebbe occuparsi di autorizzare l'utente ad eseguire operazioni protette; a meno che securityd non gestisca pure il keychain, ma non credo. Semmai, è possibile che securityd usi l'API del keychain per recuperare automaticamente le password se il keychain è sbloccato.

Però, meglio che guardi le fonti ufficiali:

- Keychain Services Programming Guide

- Security Overview

Non vedo il bisogno di un'api di questo genere, su Linux l'installazione del software avviene tramite l'uso di package manager, che si appoggiano a repository della comunita'. L'installazione non avviene manualmente, programma per programma, lanciando un "setup.exe" alla windows, scaricando il detto setup magari da un sito trovato con google, come ho gia' detto in altri post questo modo di fare di Linux contribuisce alla sua sicurezza in quanto scaricando cose dai repository si ha ottima garanzia che il software installato non generi problemi al sistema o non contenga sorprese.

Su Linux esistono anche installer "alla windows" come quello di googleheart e alcuni giochi come quake"versione" doom3 e varie versioni di unrealtournament etc... ma in questi casi il setp avviene in locale dentro la home dell'utente, so che avviandoli come root sarebbe possibile installarli per tutti utenti nel rootfilesystem ma non ci penso nemmeno ad avviare un'installar che mi sporca tutto il sistema.

Dal mio punto di vista Linux va bene cosi' e fa bene a mantenerei questa direzione.

Aggiungo che se su Linux si prendresse a gestire il software "alla Windows" si guadagnerebbe poco di usabilita' da parte degli utenti piu' impediti (dico utenti piu' impediti perche' gran parte dei miei clienti dopo aver capito il meccanismo di installazione del software tramite l'uso di YaST lo giudicano piu' immediato che cercare su internet come facevano con Windows) ma si perderebbe un sacco in stabilita'/sicurezza/pulizia del sistema.