Grazie.
PPs. sono niubbo, ma forse lo avevate giᅵ capito.
secondo me non serve
crei la directory di proprieta' di un certo gruppo x
le levi il permesso di accesso a chi non appartiene a quel gruppo
e quindi aggiungi a quel gruppo solo gli utenti a cui in teoria vorresti
far avere la password
non ottieni cosi' la stessa cosa?
Aspettando la risposta, faccio un po' l'avvocato del diavolo... E se qualcuno
riesce a entrare come root (crack, backdoor, exploit)?
Ciao,
--
Roberto Divia` Love at first sight is one of the greatest
Dep:PH Bat:53 Mailbox:C02110 labour-saving devices the world has ever seen
Route de Meyrin 385 ---------------------------------------------
Case Postale Phone: +41-22-767-4994
CH-1211 Geneve 23 CERN Fax: +41-22-767-9585
Switzerland E-Mail: Robert...@cern.ch
Sei fottuto. Per definizione non esiste - in *nix - alcunchᅵ che root
non possa fare. Puᅵ benissimo entrare anche in una directory con
permessi d--------- nobody.nobody.
--
Massimo Bacilieri AKA Crononauta
> Aspettando la risposta, faccio un po' l'avvocato del diavolo... E se qualcuno
> riesce a entrare come root (crack, backdoor, exploit)?
come dice l'amico lotussaro, sei nella merda che piu' merda non si puo'.
root e' dio e root accede a qualsiasi cosa.
nel caso dell'op, consiglierei di crittografare la directory
--
Euclì, nel tuo caso XNA non dovrebbe essere un'opzione, ma un obbligo.
Sei imbarazzante.
Tu cosa ti aspetti che voglia dire:
"mettere una password ad una directory"?
> Se si, come ????
criptandola.
--
|Save our planet!
Ciao |Save wildlife!
roberto |For your E-MAIL use ONLY recycled Bytes !!
|roberto poggi rpo...@softhome.net
una directory che mi richiede una ulteriore password per avervi accesso.
Criptarla andrebbe bene, ma lo trovo scomodo, il sistema che usavo mi creava
sostanzialmente una copia criptata, per avervi accesso ne creava una visibile di
volta in volta, per directory capienti la cosa ᅵ snervante.
>> Tu cosa ti aspetti che voglia dire:
>> "mettere una password ad una directory"?
>>
> intendo che una volta avuto accesso, anche come root, al sistema, mi trovo
> una directory che mi richiede una ulteriore password per avervi accesso.
Ok, e chi dovrebbe chiederti la password? ;-)
> Criptarla andrebbe bene, ma lo trovo scomodo, il sistema che usavo mi creava
> sostanzialmente una copia criptata, per avervi accesso ne creava una visibile di
> volta in volta, per directory capienti la cosa ᅵ snervante.
Ma ᅵ l'unico modo, se non vuoi riscriverti qualche pezzo di linux che
snaturi il concetto di utenti/permessi e della personalitᅵ deiforme di
root.
Si potrebbe ottenere qualcosa con le estensioni ACL, ma non credo
tu possa limitare anche root.
> Si potrebbe ottenere qualcosa con le estensioni ACL, ma non credo
> tu possa limitare anche root.
Linux Capabilities e puoi limitare *anche* root (però non risolve il
problema di Alessandro). Questo giusto per sfatare il mito di "root può
sempre tutto in Linux". :)
--
Vide
Come giᅵ detto da leandro installati encfs con cryptkeeper (entrambi nei
repositories di Ubuntu).
Quest'ultimo si mette nella tray area e ti permette di definire nuove
directory cryptate e di accedervi previa richiesta password.
Per accedere ai dati crittati non vengono copiati dati (cosa alquanto
stupida per altri motivi) ma si accede alla dir tramite un ulteriore layer
gestito con Fuse.
http://en.wikipedia.org/wiki/EncFS
--
Flavio Visentin
Nel messaggio <hcn9tv$ec$3...@news.albasani.net> un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)
Diciamola tutta: linux Capabilities *non* limita root, limita solo
quello che può fare un'applicazione avviata come root. È diverso.
Tradotto: le capabilities possono aiutare a proteggere da exploit in
quelle applicazioni che per vari motivi sono avviate suid, ma non
proteggono certo se un malintenzionato arriva a una shell di root.
> Tradotto: le capabilities possono aiutare a proteggere da exploit in
> quelle applicazioni che per vari motivi sono avviate suid, ma non
> proteggono certo se un malintenzionato arriva a una shell di root.
Falso. Una shell root può non riuscire a cambiare i permessi a file. Se
togli CAP_CHOWN e CAP_SYS_BOOT sei dio solo se hai accesso fisico alla
macchina.
--
Vide
Pensare alla sicurezza basandosi sul limitare un utente root/administrator è
peggio che non pensarci affatto.
L'utente root/administrator non è un '''uomo solo''' da tenere a bada in
qualche modo, ma è un utente a capo di un esercito di comandi, programmi,
moduli, ecc., a cui può ordinare di fare quello che non è in grado di fare
direttamente, in sintesi può facilmente prendere il controllo totale del
sistema.
L'unica possibilità sarebbe di impedire all'utente root/administrator
qualsiasi tipo di creazione, modifica, variazione, ecc. su qualsiasi
componente del sistema, cioè bisognerebbe ridurre i privilegi dell'utente
root/administrator ad un livello inferiore a quello di un utente normale.
P.S. C'è un programma presente su tutti i sistemi unix e windows che spesso
viene utilizzato per aggirare in pochi minuti i tentativi di limitazione
dei privilegi dell'utente root/administrator.
PP.SS. Anche in windows hanno pensato di limitare i privilegi di
administrator, aggiungendo utenti come SYSTEM e facendo in modo che
admnistrator non potesse avere nessun tipo accesso a parti delicate per la
sicurezza, peccato che tali limitazioni sono da anni aggirabili (e non per
una cattiva implementazionem a semplicemente perché administrator può e
deve interagire con funzioni che hanno i privilegi necessari).
PPP.SSS. L'idea di limitare root/administrator è vecchia di decenni, quindi
sarebbe il caso di domandarsi, possibile che a questa cosa non ci abbiano
pensato prima? dov'è che non funziona questa idea? forse è meglio che mi
documenti su questa cosa?
> Pensare alla sicurezza basandosi sul limitare un utente root/administrator
> è peggio che non pensarci affatto.
Io contesto l'asserzione "root è dio". Chi ha accesso fisico e accesso root
è $DIVINITA, root è "solo" molto, molto, molto potente.
--
Vide