C'est le premier d'une série de mises à jour qui finira avec la version finale projetée pour novembre 2013. Comme d'habitude avec une version alpha, les changements les plus visibles sont les changements de version.
Mises à jour importantes
Quelques mises à jour importantes ci-dessous :
GNOME 3.6 > 3.8.1
apache2 2.2.22 > 2.4.3
digikam 3.0.0 > 3.1.0
giflib 4.1.6 > 5.0.3
icecream 0.9.7 > 1.0.0
kernel 3.7.10 > 3.9.0
libreoffice 3.6.3.2.4 > 4.0.2.2.1
ocaml 3.12.1 > 4.00.1
qemu 1.3.0 > 1.4.0
qt-creator 2.6.2 > 2.7.0
ruby 1.9.3 > 2.0
systemd 195 > 202
wpa_supplicant 1.1 > 2.0
xorg-x11-server 1.13.2 > 1.14.1
Pour ce qui est des grands changements attendu pour la version 13.1:
Il y a quelque temps, l'équipe a posté une liste suggérée de changements pour openSUSE 13.1. L'idée derrière cela est d'accepter les changements fournis par la communauté
Pour le système de base, les changements planifiés incluent GCC actualisé en version 4.8 et l'integration des dernières version de kernel. Pour le boot il y avait une discussion pour passé entièrement sur SYSTEMD et laissant tomber SYSVINIT. De meme pour le remplaçement de MKINITRD par Dracut.
Sur l'environnement KDE la liste planifiée inclut le fait que PHONON supporte GSTREAMER 1.0 et le fait de remplacer Kopete, en grande partie non maintenu par Télépaty. Gnome devrait bouger aussi dans cette 13.1 en passant en version 3.10, en nettoyant certaines bibliothèques démodées à fond et en changeant son thème implicite pour tiré sur le vert.
Sur la sécurité la liste est simple jusqu'à présent, AppArmor sera promu comme la suite de sécurité préférée et SELinux sera actualisé.
la Roadmap de la version 13.1 est:
16 Mai 2013 - openSUSE 12.3 Milestone 1
13 Juin 2013 - openSUSE 12.3 Milestone 2
11 Juillet 2013 - openSUSE 12.3 Milestone3
08 Aout 2013 - openSUSE 12.3 Milestone4
19 Septembre 2013 - openSUSE 12.3 Béta1
10 Octobre 2013 - openSUSE 12.3 RC1
31 Octobre 2013 - openSUSE 12.3 RC2
08 Novembre 2013 - openSUSE 12.3 Gold Master
La version finale est donc attendue courant novembre
Sources:
# AppArmor et Selinux
Posté par Misc (site web personnel) . Évalué à 3.
Alors ça, c'est un sujet ou j'aimerais avoir un peu plus de détail, et je ne sais pas si des gens peuvent me répondre.
1) est ce que apparmor est mis par défaut ?
je vois assez souvent des gens qui ralent sur la présence de selinux ( et qui AMHA, rale à tort ), et je vois pareil pour apparmor, dans une moindr emesure, sur ubuntu. Quid de Suse ?
2) apparmor et selinux, sans policy, tu va pas très loin.
est ce qu'il y a plus de profiles que sur Ubuntu, ou des développements particuliers à ce niveau ?
[^] # Re: AppArmor et Selinux
Posté par Atem18 (site web personnel) . Évalué à 3.
Bonsoir, est-ce que quelqu'un pourrait globalement m'expliquer ce que sont AppArmor/Selinux et quels sont leurs différences ? Je sais que c'est lié à la sécurité, mais plus précisément, aucune idée.
Merci d'avance.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . Évalué à 10. Dernière modification le 18 mai 2013 à 00:13.
Alors, AppArmor et SELinux, ce sont 2 modules de sécurité du noyau (LSM, linux security module). L'idée est d'avoir des extensions du kernel pour accepter ou pas certaines opérations sur la base de critères externes ( voir ça comme un firewall pour les fonctions du kernel ).
Les LSM permettent plus que ces 2 la, mais je vais pas me disperser. Les 2 servent à appliquer des règles de qui a le droit de faire quoi plus souple que le simple modèle unix.
Ensuite, la ou ça diffère, c'est comment tu le fait. SELinux est un système de label couplé avec des règles. Tu mets un label sur les utilisateurs, sur les fichiers, sur les processus, etc, et tu écrit des règles pour régir l'interaction.
Par exemple, quelqu'un avec le label admin_u ( _u comme user ) a le droit de faire exec sur un fichier avec le label network_t ( _t comme type ), ce qui va donner un processus avec network-exec_t ( y a une regle qui dit comment les labels évoluent ). Et ce processus a le doit de faire tel ou tel chose, comme ouvrir un socket, et ainsi de suite.
Apparmor, c'est la même idée, sans les labels. IE, tu donnes direct les chemins de fichiers. Tu va dire "tel programme /usr/bin/toto a le droit de lire tel fichier, tel fichier, et faire tel opération". Par exemple, tu va dire que evince n'a pas le droit de lire ton .ssh, même si tu as le droit toi en tant qu'utilisateur de manipuler les fichiers. Si jamais un pdf contient un malware, il va pas piquer ta clé ssh.
Personnellement, je trouve SELinux plus souple, mais je suis partiel.
L'idée à la base, c'est de pouvoir confiner les processus et/ou les utilisateurs, ou de gérer des politiques obligatoires ( MAC, mandatory access control, par opposition à un DAC, discretionnary access control, qui sont les droits unix gérés par les utilisateurs eux mêmes, et donc potentiellement non conforme à ce que l'organisation veut ).
Ceci permet par exemple par une isolation des utilisateurs sur une plateforme comme openshift, ou chacun n'a accès qu'à son répertoire, ne voit pas les processus des autres ( http://www.youtube.com/watch?v=VaxkrSpBr6M pour les anglophones ), etc, à l'isolation des VMs les unes des autres ( voir libvirt et svirt http://namei.org/presentations/svirt-lca-2009.pdf , mais ça marche aussi avec AppArmor ), à la limitation des droits des applications bureautiques ( voir les propositions de Canonical sur le sujet : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement ), etc.
Il existe par exemple plusieurs projets de sandbox comme https://www.stgraber.org/category/arkose/ , http://danwalsh.livejournal.com/28545.html , etc.
L'idée est que si tu as une faille dans un processus confiné, en temps normal ( ie non confiné ), il peut faire ce qu'il veut. Par exemple, si je prends la main sur apache via une faille, j'ai l'accès d'un utilisateur non privilégié et de la, je peux rebondir, faire des connexions vers l'extérieur, lancer des programmes avec d'autres failles, lire des fichiers non protégés, etc. Avec SELinux/AppArmor, tu peux interdire de faire ça.
Ça implique d'avoir une politique de sécurité, mais justement, Ubuntu propose des politiques ( appelés profil ) pour certains démons, Fedora/RHEL/Centos propose une politique SELinux des plus complètes
A partir de SELinux, tu peux aussi mettre en place différents modèles de sécurité des données, souvent mis pour des organisations militaires :
modèle Bell Lapadula, ou grosso modo, chacun a une classification ( donc un label assigné ), chaque document a une classification ( donc un label aussi ), par exemple, public, privée, confidentiel, top secret, par ordre de criticité. Les gens avec l'habilitation privée peuvent écrire un document privée, confidentiel, et top secret, et ne peuvent lire que public et privé. Ce qui fait que l'information top secret ne va jamais devenir moins que top secret ( sauf personne non soumise à la politique de sécurité ).
modèle Biba, qui est l'inverse, ou tu as par exemple 3 classifications, soldat, colonel, général. Les gens de rangs le plus haut peuvent écrire des documents à destination des gens en dessous, mais pas les lire. Et tout le monde peut lire les documents venant d'en haut. Et ça permet donc de formaliser la chaine de commandement d'une armée, ou par exemple, tu es sur que les ordres viennent bien d'une personne au dessus de toi. Le soldat ne peux pas donner d'ordre à un colonel, mais le général peut.
Formaliser la politique de sécurité permet de s'assurer que personne ne va faire des conneries comme virer les droits top secret par erreur.
( ensuite, il faut je précise d'autres mesures pour éviter d'autres attaques )
Enfin bon, je pourrais parler de SELinux pendant des heures, un peu moins de AppArmor ( je connais moins ) mais j’espère que mon explication t'a aidé.
[^] # Re: AppArmor et Selinux
Posté par Anonyme . Évalué à 2.
Manque plus que Capsicum :p
Très instructif, merci.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . Évalué à 3.
Capsicum est pas un LSM, sauf erreur de ma part.
Si je dois citer tout les solutions de sécurité qui vont changer le système de permission de façon conséquente, faut que je rajoute smack (utilisé par meegoo), tomoyo et sa longue histoire, les différents modules du projet trustedbsd, bitfrost (olpc), aegis (nokia n9), le modèle d'android et sans doute une paire que je connais pas (ou qui n'ont pas de petit nom).
On a beau dire "le modèle Unix est parfait et loué soit ses codeurs", refaire la liste montre bien qu'il y a quand même du monde qui cherche à l'adapter car il est totalement inadéquat (au contraire de Sheila). Et c'est sans prendre en compte le souci que xkcd résume bien: https://www.xkcd.com/1200/ , à savoir qu'il y a aussi tout le souci d'authentification sur le réseau, et la tension entre "facilité d'utilisation" et "blocage en cas de compromission".
[^] # Re: AppArmor et Selinux
Posté par Atem18 (site web personnel) . Évalué à 2.
En effet et je t'en remercie. Pour la peine, je t'ai mis +1 à ton commentaire. :)
[^] # Re: AppArmor et Selinux
Posté par patrick_g (site web personnel) . Évalué à 5.
Et aussi pour Firefox et Chromium, ce qui est bien plus intéressant pour le particulier qui utilise un ordi personnel.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . Évalué à 2.
Oui, mais le souci, c'est que c'est pas activé par défaut. Le particulier en question veut être secure, mais si ça empêche des tas de choses genre "envoyer ma clé privée sur gmail pour faire un backup", ou "ne plus pouvoir utiliser firessh", il va raler :)
Je vois bien le nombre de gens (à commencer par des OEMs, donc des gens à priori techniques) qui commence par "faut désactiver selinux", c'est pas tip top.
Ensuite, les profiles de firefox/chromium ont aussi le souci de pas être aussi étanche qu'ils devraient, vu qu'il y a divers attaques sur les variables d’environnement, il y a dbus (qui n'est pas encore apparmor aware, et qui est selinux aware mais c'est pas trop utilisé), le keyring, etc. Les soucis pour le confinement d'application sont bien détaillé dans le document d'ubuntu que j'ai donné.
Mais c'est mieux que rien, je le concède.
[^] # Re: AppArmor et Selinux
Posté par MTux . Évalué à 2.
Oui mais dans le cadre d'une utilisation grand public ou station de travail en entreprise (non soumise à confidentialité élevée) est-ce vraiment utile ?
SELinux induit une très grande complexité et peut devenir infernal si mal paramétré.
Je tourne sur Fedora depuis longtemps, mais il n'y a que depuis la 17 que je laisse SELinux activé. Avant c'était juste impossible d'utiliser ma machine avec, j'avais sans arrêt des popup d'alertes, des logiciels qui ne se lancent pas, des services qui ne démarrent pas…
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . Évalué à 2.
On a pas du avoir les mêmes Fedora alors :)
J'ai toujours laissé SELinux installé et activé. Je dit pas que j'ai jamais eu de popups, j'ai reporté pas mal de bugs sur la policy justement, mais je dirais pas "sans arrêt des popups". Et en général, c'était pas sur les softs installés par défaut.
Les erreurs courantes que j'ai vu avec des gens et SELinux, c'est quand tu touches à la configuration des daemons en réseau ( vu qu'il y a globalement que eux qui sont confinés ). Par exemple, tu fait tourner sshd sur un autre port sans configurer selinux pour ça. Que tu décide de mettre ton ftp dans /home/monsiteweb et que pareil, tu précises pas à SELinux que c'est des objets que apache a le droit de lire et vsftpd a le droit d'écrire, etc. ou des trucs que tu installes à la mano.
Dans la configuration par défaut, en règle général, ça passe. Et plus il y a de gens qui utilisent selinux, notamment sur les versions de dev ( genre F19 en ce moment ), plus vite la policy est corrigé. Les packageurs Fedora sont assez réactifs à ce niveau.
Et pour la question de l'utilisation plus grand public, ça dépend des risques d'attaques sur ta machine.
Tu pourrais te dire par exemple qu'un simple assistant va pas avoir de souci, mais si c'est l'assistant de la directrice générale du groupe, ça reste une cible de choix. Ensuite, out of the box, l'utilisateur bureautique n'est pas protégé par SELinux dans la policy déployé par Fedora, car ses processus tournent sans confinement même si des choses comme le fait de bloquer ptrace ( http://lwn.net/Articles/491440/ ) aident à sécuriser. Pour ce genre d'utilisateur, je pense que le confinement tel que Canonical le prévoit va servir une fois que ça sera au point.
Et sinon, SELinux est aussi la technologie qui permet d'avoir xguest ( https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Confining_Users-xguest_Kiosk_Mode.html ), et visiblement, lightdm se base sur apparmor pour son utilisateur guest. Donc il y a des avantages, même si c'est minime par rapport à tout ce qu'on pourrait faire.
[^] # Re: AppArmor et Selinux
Posté par MTux . Évalué à 3.
Le problème c'est que les utilisateurs en entreprise ils marquent leurs mots de passe sur des papiers :)
Nous avons aussi eu le cas d'un directeur qui a tapé du poing sur la table pour que nous l'autorisions à mettre un mot de passe super court sinon il l'oubliait tout le temps.
On a beau avoir un SI super sécurisé, ça sert à rien si les utilisateurs mettent la clé sous le tapis…
[^] # Re: AppArmor et Selinux
Posté par oinkoink_daotter . Évalué à 3.
Comme tu l'as indiqué, Bell-Lapalluda garantie la confidentialité des données : une personne de niveau n ne peut lire les données de niveau n+1 et ne peut écrire au niveau n-1.
Biba, lui, garantit l'intégrité des données : une personne de niveau n ne peut lire que les données de niveau supérieur ou égal au sien et ne peut écrire qu'au niveau inférieur ou égal au sien. L'idée, c'est que plus tu montes dans les niveaux et plus les données sont réputées intègres. En gros on se méfie des données de niveau inférieur au sien qui peuvent être "fausses" ou "vérolées" (en fait on interdit la lecture). Ca permet par de gérer des notions de niveau d'intégrité dans un OS : je ne veux pas que le fonctionnement de mon service FTP anonyme ne foute la grouille dans mon serveur web. Ca devient compliqué à mettre en place quand les niveaux ont des relations (pour ça il y a des exceptions).
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . Évalué à 2.
Ah oui, c'est un exemple plus parlant que celui de l'armée :)
En fait, si tu veux avoir des relations, il faut pas juste rajouter un 3eme élément qui est considéré comme étant "hors de la politique de sécurité" et qu'on suppose être capable de décider et de suivre la politique, donc de vérifier l'intégrité ( ou dans le cas de Bell-Lapaluda, de forcer la déclassification des données ) ?
IE, dans le cas que tu donnes, un humain comme l'admin de la machine.
En fait, je réalise ( je réalise beaucoup ce matin ) qu'on utilise les dites politiques de sécurité parce qu'on fait pas confiance aux programmes pour avoir un minimum de jugement pour dire "ça, c'est louche", mais l'armée fait pareil vis à vis de ses membres, en demandant à ne pas réfléchir aux ordres mais en devant compenser ça par des politiques stricts. Au final, l'armée gère presque des machines biologiques.
[^] # Re: AppArmor et Selinux
Posté par kadalka . Évalué à -10.
@Misc
Pourquoi ne pas nous gratifier de vos compétences dans le domaine ?
(sans faire étalage de vos connaissances pour autant bien sûr: la confiture ce n'est pas top…)
C'est mon souhait mais je crains d'être seul…
# 12.3 ?
Posté par claudex . Évalué à 6.
Je suppose qu'il faut faire un
s/12.3/13.1/?« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.