l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
Unification et coté monolithique n'ont pas grand chose à voir. C'est très bien que SELinux unifie les politiques d'accès (sans ironie hein), mais c'est un peu domage de devoir mettre en place tout le framework de a à z pour une politique de 3 lignes. J'ai bien conscience que vu la nature et les ambitions de SELinux il n'est pas possible de découper le framework en pleins de petits morceaux utilisables séparément, mais je préfère quand même l'approche biba de FreeBSD.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Sur quelle distribution ? Parceque si les outils pour les ACL sont intégrés, c'est rare que les FS aient les ACL activés par défaut. Je change pas de sitrib tous les deux jours, mais l'année dernière il n'y avait guère que Suse et Fedora qui activaient les ACL par défaut.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça.
Tout simplement faire démarrer un service en écoute sur un port local non privilégié et rajouter une règle firewall pour faire le lien. Ca évite de devoir lancer tout un tas de service en utilisateur root (même si après les privilèges redescendent - c'est quand même pas top).
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
Même avec un VCS, à un moment ou à un autre il va bien falloir aller écrire dans /var/www (ou autre répertoire) et là sans les ACL tu as deux solutions : soit tu donnes le groupe www a tous les utilisateurs susceptible de devoir modifier le site (ou faire un commit si tu préfères), soit tu ajoutes l'utilisateur apache dans 200 groupes.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ).
Alors distinguons bien deux cas :
a) Il s'agit d'un utilisateur avec un compte et un uid qui est logué en console et qui utilise, par exemple, psql - et là avec les labels multiples le mec il peut toujours se brosser pour accéder au contenu d'un tablespace qui n'est pas autorisé. (Je pensais que tu parlais de ce cas là)
b) Il s'agit d'un utilisateur logué à distance (par exemple sur le port 5432 via réseau) - et là de toutes les façons les accès se font via le serveur, sous l'uid du serveur. La seule chose qu'apporte SE-Postgres dans ce cas c'est que les restrictions et les droits ne sont plus validé seulement contre le système interne à Postgres mais aussi vis à vis d'un jeu de police de sécurité SELinux. Cependant si le plugin est compromis (ce qui implique qu'il n'était pas lui même protégé par une policy - ce qui serait idiot je l'admet) SE Linux ne verra rien passer des requètes faites à PostgreSQL.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
La question est de quoi ai-je besoin pour faire confiance à l'autre machine ? Si c'est juste tester la présence d'une clef ipsec est très bien dans le rôle, si j'ai besoin de plus que ça il faut que je sache le valider chez une machine tiers. A aujourd'hui si j'ai besoin de plus que la présence d'une clef privée, il faut que je maintienne le serveur complètement - ce qui peut être lourd. CIPSO était supposé répondre à ce problème - on devait être capable de s'envoyer des paquets certifiés qui anoncnet que le serveur distant est bien en train de faire tourner un apache à jour avec mod_rewrite désactivé, que le routeur machin droppe les paquets DHCP ver telle ou telle branche réseau, que les url de type xxx://#!!%/*.truc sont interdite etc.
Est-ce que aujourd'hui c'est possible vis à vis d'une machine que je n'administre pas ? Oui/partiellement/non ?
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 4.
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
Unification et coté monolithique n'ont pas grand chose à voir. C'est très bien que SELinux unifie les politiques d'accès (sans ironie hein), mais c'est un peu domage de devoir mettre en place tout le framework de a à z pour une politique de 3 lignes. J'ai bien conscience que vu la nature et les ambitions de SELinux il n'est pas possible de découper le framework en pleins de petits morceaux utilisables séparément, mais je préfère quand même l'approche biba de FreeBSD.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Sur quelle distribution ? Parceque si les outils pour les ACL sont intégrés, c'est rare que les FS aient les ACL activés par défaut. Je change pas de sitrib tous les deux jours, mais l'année dernière il n'y avait guère que Suse et Fedora qui activaient les ACL par défaut.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça.
Tout simplement faire démarrer un service en écoute sur un port local non privilégié et rajouter une règle firewall pour faire le lien. Ca évite de devoir lancer tout un tas de service en utilisateur root (même si après les privilèges redescendent - c'est quand même pas top).
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
Même avec un VCS, à un moment ou à un autre il va bien falloir aller écrire dans /var/www (ou autre répertoire) et là sans les ACL tu as deux solutions : soit tu donnes le groupe www a tous les utilisateurs susceptible de devoir modifier le site (ou faire un commit si tu préfères), soit tu ajoutes l'utilisateur apache dans 200 groupes.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ).
Alors distinguons bien deux cas :
a) Il s'agit d'un utilisateur avec un compte et un uid qui est logué en console et qui utilise, par exemple, psql - et là avec les labels multiples le mec il peut toujours se brosser pour accéder au contenu d'un tablespace qui n'est pas autorisé. (Je pensais que tu parlais de ce cas là)
b) Il s'agit d'un utilisateur logué à distance (par exemple sur le port 5432 via réseau) - et là de toutes les façons les accès se font via le serveur, sous l'uid du serveur. La seule chose qu'apporte SE-Postgres dans ce cas c'est que les restrictions et les droits ne sont plus validé seulement contre le système interne à Postgres mais aussi vis à vis d'un jeu de police de sécurité SELinux. Cependant si le plugin est compromis (ce qui implique qu'il n'était pas lui même protégé par une policy - ce qui serait idiot je l'admet) SE Linux ne verra rien passer des requètes faites à PostgreSQL.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
La question est de quoi ai-je besoin pour faire confiance à l'autre machine ? Si c'est juste tester la présence d'une clef ipsec est très bien dans le rôle, si j'ai besoin de plus que ça il faut que je sache le valider chez une machine tiers. A aujourd'hui si j'ai besoin de plus que la présence d'une clef privée, il faut que je maintienne le serveur complètement - ce qui peut être lourd. CIPSO était supposé répondre à ce problème - on devait être capable de s'envoyer des paquets certifiés qui anoncnet que le serveur distant est bien en train de faire tourner un apache à jour avec mod_rewrite désactivé, que le routeur machin droppe les paquets DHCP ver telle ou telle branche réseau, que les url de type xxx://#!!%/*.truc sont interdite etc.
Est-ce que aujourd'hui c'est possible vis à vis d'une machine que je n'administre pas ? Oui/partiellement/non ?