Forum Linux.général liste des fichiers linux à "sécuriser" (owner:group, permissions, setuid/setgid, sticky bit)

Posté par  . Licence CC By‑SA.
1
23
juil.
2023

Bonjour,
J'ai cherché sur les moteurs de recherche et demandé à chatgpt, mais je ne trouve pas une liste "générique" de fichiers à vérifier sous linux pour des questions de sécurité.

J'entend par sécurité notamment le fait que si un utilisateur accède à l'os avec un utilisateur non root, qu'il ne puisse pas faire n'importe quoi.

Jai trouvé ce lien qui est pas mal : https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html mais il n'y a pas tout, des commandes aussi basiques que useradd/adduser, groupadd/addgroup ou (…)

Forum Linux.général Chemin standard pour un "prefix" local à l'utilisateur

Posté par  (site web personnel) .
Étiquettes :
1
20
jan.
2012

Bonjour.

Actuellement quand je fait configure/make/make install ou cmake ou tout autre construction à partir des sources, j'installe les choses dont je serai le seul à me servir dans mon /home.

Du coup je me retrouve avec une arborescence du type
/home/local
/home/local/bin
/home/local/include
/home/local/lib/
...
/home/local/opt/eagle
/home/local/opt/opera
...

Opera par exemple semble proposer par défaut pour ce genre de choses /home/.local

D'un autre côté sous Slackware, il semble que le script d'initialisation du shell utilisateur ajoute $/home/bin au path...

(…)

/usr friendly

Posté par  (site web personnel) . Modéré par Lucas Bonnet. Licence CC By‑SA.
35
4
nov.
2011
Fedora

« Le FHS du LSB est bien, mais “ / ” est un sacré bordel, il faut tout de même l’avouer. » Ceux qui auront compris cette phrase seront certainement d’accord. Pour les autres, LSB signifie Linux Standard Base, cela définit tout un ensemble de standards autour de GNU/Linux, dont… le FHS, qui est le Filesystem Hierarchy Standard, qui définit l’emplacement des fichiers.

À la racine, c’est‐à‐dire la base du système de fichiers, notée « / », on range notamment les données et les programmes statiques dans « /usr », bien. Ensuite, on range les binaires dans « /bin » et « /sbin », et les bibliothèques dans « /lib » et « /lib64 ». Oui, mais voilà, on range aussi des binaires dans « /usr/bin » et « /usr/sbin », et des bibliothèques dans « /usr/lib » et « /usr/lib64 ».

La proposition vient de Harald Hoyer et Kay Sievers, deux développeurs Red Hat, et est soutenue par Lennart Poettering. L’héritage de 30 ans d’UNIX est clairement à simplifier. Le but est de :

  • fusionner « /bin », « /sbin » et « /usr/sbin » dans « /usr/bin » ;
  • déplacer le contenu de « /lib » dans « /usr/lib » ;
  • déplacer le contenu de « /lib64 » dans « /usr/lib64 » ;
  • créer des liens symboliques pour rester compatible :
    • « /bin » vers « /usr/bin »,
    • « /sbin » vers « /usr/bin »,
    • « /lib » vers « /usr/lib »,
    • « /lib64 » vers « /usr/lib64 ».

Facile à retenir : « sbin », c’est has been ! Hum.

Ceci faciliterait grandement le montage et démontage des systèmes de fichiers, le démarrage du système, les instantanés (snapshots), la virtualisation, etc..

/run or not /run

52
4
avr.
2011
Linux

Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.

Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.

Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.

À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.

Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.

Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.

Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.

Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.

Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !

N. D. M. : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.