Si tu veux dire qu'en général il vaut mieux un truc personnalisé aux petits oignons (s'il est effectivement bien fait) qu'un truc généraliste, ben oui.
> S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
SeLinux débute pour le desktop. Mais les possibilités sont énormes. Par exemple si un utilisateur lance un programme dans son $HOME, on peut faire que ce programme (qui a été downloadé sur un signe warez) ne puisse lire .thunderbird, etc...
A l'avenir (car SeLinux débute dans le domaine du desktop), les paquets rpm/deb qui sont installés et ne sont pas signés par une source de confiance pourront avoir des privilèges limités (interditions de lire/écrire/supprimer des fichiers que le programme n'a pas créé, etc). Notons qu'un "bête" rpm est un problème puisqu'il s'installe avec les droits root. [admin@one rsync]$ rpm -q --scripts firefox
postinstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
preuninstall scriptlet (using /bin/sh):
# is it a final removal?
if [ 1ドル -eq 0 ]; then /bin/rm -rf /usr/lib/firefox-2.0.0.9/components /bin/rm -rf /usr/lib/firefox-2.0.0.9/extensions
fi
postuninstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
Le "rm -rf" pourrait être un "rm -rf /", il marcherait très bien.
Donc dans les scripts d'installation tu peux faire tout et n'importe quoi et sous le compte root. Avec SeLinux tu peux gérer ce type de problème. Problème qui se posera à l'avenir.
> Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux.
Le httpd de Fedora avec SeLinux n'a pas le droit de lire /etc (sauf /etc/httpd et quelques bricoles) ni les fichiers dans /tmp (sauf ceux créés par apache).
Il y a plein de "petites choses" dans ce gout. Et tu as ça par défaut !
Tu as ça aussi si l'administrateur à fait des conneries (par exemple un malheureux chmod -R 777 /etc). Si un utilisateur à fait chmod -R 777 ~, ben apache (ou un script d'apache) ne pourra pas y lire.
Si tu utilises mod_user (avec ou sans suexec) d'apache ça veut alors dire que $HOME/public_html est accessible. Et donc $HOME. Et donc tous les fichiers à l'intérieur dès que l'utilisateur fait un oubli. SeLinux gère ça. apache ne peut lire et écrire que dans $HOME/public_html quelque soit les conneries de l'utilisateur.
Il y a des tonnes de serveur prétendument "finenement protégé" qui ne sont pas au niveau de ce qui est fait par SeLinux sous Fedora par défaut. Par défaut sans que tu te prennes la tête. Et l'expertise que tu as n'est pas d'un administrateur qui a fait ça à l'arrache car il est sous pression, mais par des experts.
> Et là, la complexité est un handicap
La complexité est toujours un handicap/problème. Mais es-ce Selinux qui est complexe ou la sécurité qui est complexe ?
Avec chroot, les droits DAC, aussi ACL, des programmes bien sélectionnés et audités, etc et un admistrateur compétent tu peux avoir un système très sûr. Aucun doute sur ça. Pour ces cas on n'a pratiquement pas besoin de SeLinux. Ces cas sont finalement très limité.
Par contre dans pleins pleins d'autre cas, SeLinux est un atout. Ce n'est pas un atout qui ajoute forcément de la compléxité. J'ai installé bugzilla et awstats, il y a déjà des règles SeLinux, j'ai rien à faire. Plus simple que ça tu meurs.
Pour les cas spécifiques ?
Ben il y aura du boulot. Oui. Mais au lieux de te prendre la tête pour mod_user, pour bugzilla, pour awstats, etc, ben tu ne te prends la tête que pour les choses très spécifiques.
Il y a une communauté SeLinux très dynamique, tu trouveras de l'aide sans problème. SeLinux est aussi l'outil qui répond à une très vaste palette de problème (bien au-delà de ce que proposer le modèle DAC, ACL, chroot, etc). Donc au-lieu de te demander qu'elle solution il te faut dans les 10 000 addons sécurité, il te suffit de connaitre SeLinux. Ça simplifie grandement. Donc la complexité de SeLinux est très relative. D'autant plus qu'on a de plus en plus d'outil de haut niveau pour faire ses propres règles ou pour faire un audit rigoureux des règles (atout énorme de SeLinux).
SeLinux te permet aussi d'exprimer ton besoin (domaine, object, attribut, etc) et celà aussi ça simplifie la vie lorsque la situation est complexe.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 4.
> S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
SeLinux débute pour le desktop. Mais les possibilités sont énormes. Par exemple si un utilisateur lance un programme dans son $HOME, on peut faire que ce programme (qui a été downloadé sur un signe warez) ne puisse lire .thunderbird, etc...
A l'avenir (car SeLinux débute dans le domaine du desktop), les paquets rpm/deb qui sont installés et ne sont pas signés par une source de confiance pourront avoir des privilèges limités (interditions de lire/écrire/supprimer des fichiers que le programme n'a pas créé, etc). Notons qu'un "bête" rpm est un problème puisqu'il s'installe avec les droits root.
[admin@one rsync]$ rpm -q --scripts firefox
postinstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
preuninstall scriptlet (using /bin/sh):
# is it a final removal?
if [ 1ドル -eq 0 ]; then
/bin/rm -rf /usr/lib/firefox-2.0.0.9/components
/bin/rm -rf /usr/lib/firefox-2.0.0.9/extensions
fi
postuninstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
Le "rm -rf" pourrait être un "rm -rf /", il marcherait très bien.
Donc dans les scripts d'installation tu peux faire tout et n'importe quoi et sous le compte root. Avec SeLinux tu peux gérer ce type de problème. Problème qui se posera à l'avenir.
> Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux.
Le httpd de Fedora avec SeLinux n'a pas le droit de lire /etc (sauf /etc/httpd et quelques bricoles) ni les fichiers dans /tmp (sauf ceux créés par apache).
Il y a plein de "petites choses" dans ce gout. Et tu as ça par défaut !
Tu as ça aussi si l'administrateur à fait des conneries (par exemple un malheureux chmod -R 777 /etc). Si un utilisateur à fait chmod -R 777 ~, ben apache (ou un script d'apache) ne pourra pas y lire.
Si tu utilises mod_user (avec ou sans suexec) d'apache ça veut alors dire que $HOME/public_html est accessible. Et donc $HOME. Et donc tous les fichiers à l'intérieur dès que l'utilisateur fait un oubli. SeLinux gère ça. apache ne peut lire et écrire que dans $HOME/public_html quelque soit les conneries de l'utilisateur.
Il y a des tonnes de serveur prétendument "finenement protégé" qui ne sont pas au niveau de ce qui est fait par SeLinux sous Fedora par défaut. Par défaut sans que tu te prennes la tête. Et l'expertise que tu as n'est pas d'un administrateur qui a fait ça à l'arrache car il est sous pression, mais par des experts.
> Et là, la complexité est un handicap
La complexité est toujours un handicap/problème. Mais es-ce Selinux qui est complexe ou la sécurité qui est complexe ?
Avec chroot, les droits DAC, aussi ACL, des programmes bien sélectionnés et audités, etc et un admistrateur compétent tu peux avoir un système très sûr. Aucun doute sur ça. Pour ces cas on n'a pratiquement pas besoin de SeLinux. Ces cas sont finalement très limité.
Par contre dans pleins pleins d'autre cas, SeLinux est un atout. Ce n'est pas un atout qui ajoute forcément de la compléxité. J'ai installé bugzilla et awstats, il y a déjà des règles SeLinux, j'ai rien à faire. Plus simple que ça tu meurs.
Pour les cas spécifiques ?
Ben il y aura du boulot. Oui. Mais au lieux de te prendre la tête pour mod_user, pour bugzilla, pour awstats, etc, ben tu ne te prends la tête que pour les choses très spécifiques.
Il y a une communauté SeLinux très dynamique, tu trouveras de l'aide sans problème. SeLinux est aussi l'outil qui répond à une très vaste palette de problème (bien au-delà de ce que proposer le modèle DAC, ACL, chroot, etc). Donc au-lieu de te demander qu'elle solution il te faut dans les 10 000 addons sécurité, il te suffit de connaitre SeLinux. Ça simplifie grandement. Donc la complexité de SeLinux est très relative. D'autant plus qu'on a de plus en plus d'outil de haut niveau pour faire ses propres règles ou pour faire un audit rigoureux des règles (atout énorme de SeLinux).
SeLinux te permet aussi d'exprimer ton besoin (domaine, object, attribut, etc) et celà aussi ça simplifie la vie lorsque la situation est complexe.