Distribution pour XGL

Autant partir du postulat que ton système est une
passoire pour tout utilisateur local, et le restera longtemps encore.

Parceque tu n'es pas capable d'utiliser sudo pour créér un vrai compte
root?

C'est un peu abrupt, comme réponse :)

Voir ici :
http://doc.ubuntu-fr.org/installation/compte_root

(Moi non plus, j'aime pas sudo)

'sudo su -'

Oui, c'est un cas de figure fréquent? Ce que je trouve risible c'est le
mec qui s'imagine qu'il va retrouver dans les logs les traces d'un hacker

Pour ça, il faut beaucoup d'optimisme. Ou alors, il faut tomber sur un
hacker débutant.

... Ou alors si c'est pour retrouver et copieusement engueuler le mec qui
a fait une connerie, voilà aussi une innovation très utile.

Pas forcément engueuler. Des fois, juste savoir ce qui a été fait permet
de résoudre un problème. Si le pauvre gars s'est trompé et ne sait pas
trop ce qu'il a fait, ça peut aider. Si c'est juste pour trouver un
coupable, c'est clair que c'est une connerie.

si ce gars a un tel comportement a risque, il ne me parait pas bien

Bonjour,


Attention, ceci n'est pas un troll, je considere que chaque distribution
(même les plus critiqué) ont leur avantage et leur problème.


Voila, je cherche une distribution qui me conviendrait.

En faite, j'ai dejà chez moi un server en mode texte qui tourne sous
Debian.
J'aime beaucoup Debian, mais voila, je souhaite aujourd'hui passer ma
station de travail (qui était encore sous Windows, car j'était étudiant
et on nous obligait a utiliser des logiciel qui n'existait pas sous
linux) sous Linux.

Bon, j'aimerais avoir de l'XGL le plus rapidement possible et un Desktop
joile a voir et bien stylé.
Mes principale application sont Firefox, OpenOffice, Thunderbird....
Ensuite, je fait beaucoup de dévellopement avec Scite, mais toute les
distrib me le permettrons sans problème.

Avant de poster ici, j'ai fait ma petite recherche et voici mes points
de vue, j'aimerais que vous me les commentiez :

Mon matos d'abord :
CM : Asus P4C800-E Delux
CPU : P4c 2.8GHz
Disque dure SERIAL ATA
GPU : NVidia GeForce 6


Debian Sarge : Trop dépasser pour XGL

Debian Etch : Impossible de l'installer depuis deja 2 semaine : je pense
que le problème est dut au disque Serial ATA, le noyaux se perd les
pedale dans le nom du disque (/dev/hda puis /dev/sdb) du coup, Fatal
error lors de l'installation de Grub.... si je ruse, que j'install une
vielle testing du moi de juillet et que j'upgrade, le noyaux ne demare
plus a cause d'un pb de udev....... Dommage, j'adore Debian....

Ubduntu : Alors, pourquoi pas ubuntu... oui mais je deteste son principe
de sudo.... alors....

Debian unstable : N'est ce pas trop instable ?? je suis pret a essayer..

Gentoo : La, je m'y interesse depuis une semaine, pourquoi pas..... mais
pourrais-je faire du XGL avec ? Sans trop trop me prendre la tête ?
Installer en Stage1 2 ou 3 ?????

Slackware : pourquoi pas, mais je ne connais pas

Suse : Pourquoi pas.... mais j'aimais bien les .deb.... enfin, je suis
tres ouvert donc

Mandriva : Le live CD m'a plus au niveau interface graphique et XGL....
mais avant je connaissait bien Mandrake jusqu'a la 6; et je n'aimais pas
trop les package RPM.... de plus, compiler un noyau sous debian est un
jeu d'enfant... sous Mandrake, je n'y était jamais arrivé...


Autre ??


J'aimerais vos point de vu OBJECTIF (en gros, les debian ça pu, Gentoo
c'est mieu sans argument, --->DEHORS ;-) )


Merci de vos conseils
Bonjour

remy <remy@fctpas.fr> wrote:

ce qui implique que l'execution se fait naturellement via l'execution
du code avec faille mais pose le probleme de la localisation du code
avec faille

Non, ce problème ne se pose pas, c'est toujours le problème de la localisation
du code avec faille dans l'espace d'adressage virtuel du processus qui se
pose, jamais de sa localisation dans l'espace physique de la mémoire machine.

Tu aurais peut être un problème comme ça si tu comptais utiliser des
débordements de buffer directement dans le noyau, dans une zone du noyau
qui ne serait pas décrite par les tables de page, si ça existe, comme par
exemple la mémoire video, les bus pci et les trucs comme ça que je ne connais
pas. En fonctionnement normal, même quand un processus fonctionne ne mod
noyau, le noyau est mappé dans l'espace d'adressage du processus, tout ça est
de la mémoire virtuelle gérée avec les tables de page et tous les débordements
de pile utilisent ces adresses virtuelles.

Et en outre, comme je disais, il y a bin d'autres moyens de devenir root. par
exemple avec cdrecord et cdrdao on pouvait dévoyer l'écriture du .cdrecordrc
ou similaire pour lui faire écrire dans /etc/passwd à la place, d'où la
possibilité triviale de devenir root. Et ça a duré jusqu'à une époque récente.
Il suffisait de précharger une librairie avent de lancer cdrecord ou cdrdao.
On peut faire des choses fantastiques en préchargeant une librairie, regarde
ce que fait fakeroot dans Debian. Si un programme suidroot est vulnérable à ce
genre de choses tu es cuit. Autant partir du postulat que ton système est une
passoire pour tout utilisateur local, et le restera longtemps encore.

il ne faudrait pas etre root pour ton attaque par hasard ?

(...)

planter un programme oui mais de la a donner des droits root
a un scripte

Il y a nettement plus simple: il suffit d'accéder à une page ayant
des scripts genre scripts cgi dans un formulaire, de bidouiller la
réponse pour que le formulaire affiche p.ex. la page
../../../../../etc/passwd (ou shadow), de prendre ce qui s'affiche,
de faire tourner un crackeur de mots de passe chez soi sur ce contenu
et puis de revenir tranquillement avec les bons mots de passe.
C'est en gros ce qui était arrivé dans le cas que j'ai évoqué ailleurs.
là je suis d'accord les scripts cgi sont une veritable passoire

mais cela s'apparente a de la force brute et donc a un mauvais choix
de mot de passe

Force brute? Un script qui merdoie et donne accès à /etc/passwd, je ne
trouve pas cela d'une grande sécurité, mais chacun ses choix...

remy <remy@fctpas.fr> writes:

legende urbaine tout cela

Rassure-moi, tu ne travailles pas dans la sécurité informatique (ou
même dans l'informatique tout court) ?

pas d'accord

donc une pile une page memoire
du code et un pointeur de retour d'un fct d'un programme qui a tous les
droits

un programme "pirate"
qui vient modifier le pointeur de retour du programme "root"
pour executer ce que tu veux

jusque là on est d'accord oui/non ?

non.

pas d'accord

donc une pile une page memoire
du code et un pointeur de retour d'un fct d'un programme qui a tous les
droits

un programme "pirate"
qui vient modifier le pointeur de retour du programme "root"
pour executer ce que tu veux

jusque là on est d'accord oui/non ?

non.

Un programme. Quelconque. Ce programme attend un input. Dans la pile
memoire, il y a un emplacement reserve pour mettre cette input (un champ
de saisie, une date, n'importe quoi). Mais derriere cet espace reserve,
il y a d'autres choses. Comme des appels de retour de fonctions.
Pour le programme, sa memoire est continue, monobloc et demarre a
l'offset 0.

MMU, etc..

Bon. Vient un bonhomme qui balance un input plus grand que prevu. Poum,
ca ecrase des trucs qu'il ne fallait pas et le programme plante.
Pourquoi est ce que ca plante? Parceque le programme qui s'attendait a
lire un code tombe sur autre chose.
Maintenant, si le gars est malin, il se debrouille pour que ce qu'il
envoie deborde l'input, et de placer les bonnes choses au bon endroit
derriere.

malin, il vise des processus tournant en root.
donc le programme, avec
les droits root, va executer du code choisi par un utilisateur. Le code
peut etre simplement: lance un /bin/sh. Et la, paf, l'utilisateur se
retrouve avec un shell root.

Oublie ces histoires de MMU, de zone memoire etc..
non na

Debian unstable : N'est ce pas trop instable ?? je suis pret a essayer..