XACE security policy framework.

• [^]Re: XACE security policy framework. FRENCH TRANSLATION ATTEMPT

  Posté par lambda () le 16/02/2007 à 17:24. (lien). Évalué à 3.

  http://people.freedesktop.org/~ewalsh/xace_proposal.html
  
  

  The XACE (X Access Control Extension) est une gamme de "portes dérobées?" utilisée par des instructions graphiques pour sécuriser les contrôles d'accès. Le but de XACE est de clarifier et d'homogénéiser ces accès en fournissant un mécanisme commun pour des connections graphiques sécurisées. Le concepte est identique au module de sécurité linux (LSM) du noyau linux.

  --
  mail administration is very challenging, too many people get into the business without understanding enough of it .... hotmail best exemple

  • [^]Re: XACE security policy framework. FRENCH TRANSLATION ATTEMPT

    Posté par Étienne Bersac (Jabber id, page perso, ) le 16/02/2007 à 17:29. (lien). Évalué à 2.

    s/portes dérobées/crochets/
    
    C'est comme en conduite. On fait un crochet par la station d'essence, ici on fait un crochet par la fonction :).

    --
    E Ultreïa !

    • [^]Re: XACE security policy framework. FRENCH TRANSLATION ATTEMPT

      Posté par lambda () le 16/02/2007 à 17:37. (lien). Évalué à 1.

      Dans ce cas et d'après http://cedricduval.free.fr/mutt/fr/sitehtml/manual-4.html#ss(...)
      je donnerais un sens de macro ou exécution automatique qui précède une commande.

      --
      mail administration is very challenging, too many people get into the business without understanding enough of it .... hotmail best exemple

• [^]Re: XACE security policy framework.

  Posté par lambda () le 16/02/2007 à 17:29. (lien). Évalué à 2.

  A noter que LSM est un patch noyau pour la série 2.6 qui est là: http://downloads.sourceforge.net/realtime-lsm/rt-lsm-0.8.7-k(...)
  
  Même mécanisme c'est à dire grosso-modo une authentification basée sur l'uid et le gid du programme mais uniquement pour les processus graphiques pour XACE.

  --
  mail administration is very challenging, too many people get into the business without understanding enough of it .... hotmail best exemple

  • [^]Re: XACE security policy framework.

    Posté par lurker () le 16/02/2007 à 17:39. (lien). Évalué à 1.

    noter que LSM est un patch noyau pour la série 2.6

    
    
    Euh non, LSM est une partie standard du noyau 2.6, c'est là dessus que se basent SELinux ou les moins connus AppArmor ou Dazuko.
    
    Il a d'ailleurs été question de supprimer récemment cette couche du noyau : http://lwn.net/Articles/138042/
    
    Ce que tu pointes, rien qu'à voir l'url ça doit être un patch pour que le noyau RT (Ingo Molnar toussa) utilise/supporte LSM.

    --
    /o/

    • [^]Re: XACE security policy framework.

      Posté par lambda () le 16/02/2007 à 17:48. (lien). Évalué à 1.

      LSM est une partie standard du noyau 2.6

      
      J'en doute --> grep LSM config-2.6.18.2-34-default
      grep LSM config-2.6.18.2-34-default
      donnent rien c'est pas pris en charge par défaut

      --
      mail administration is very challenging, too many people get into the business without understanding enough of it .... hotmail best exemple

      • [^]Re: XACE security policy framework.

        Posté par djrom () le 16/02/2007 à 18:20. (lien). Évalué à 1.

        Je crois que par "partie standard", le post plus haut voulait dire que c'était dans les sources vanilla du noyau, sans besoin de patcher. LSM fait partie du noyau depuis 2001 ou 2002. Après, effectivement p't'être il est pas activé par défaut.
        
        Voir notamment un récit par LWN (en anglais) de récentes discussions autour de LSM: http://lwn.net/Articles/180194/

      • [^]Re: XACE security policy framework.

        Posté par lurker () le 16/02/2007 à 18:29. (lien). Évalué à 2.

        Ca prouve quoi ?
        LSM c'est une infrastructure, pas un module particulier désactivable.
        
        Tu peux regarder dans la doc qui va avec les sources de ton kernel, la présentation sur LSM : Documentations/DocBook/lsm.tmpl, ou il est indiqué que LSM va être mergé dans la branche 2.5... Désormais LSM c'est les fichiers dans security/
        
        SELinux s'appuie dessus, et est bien en standard dans le noyau... (cherche SELinux dans ton interface de configuration favorite).
        
        Sinon dans include/linux/security.h, les belles macros LSM_SETID_ID, LSM_SETID_RE...
        
        Tu me crois maintenant ;-) ?

        --
        /o/

driver radeon

• [^]Re: driver radeon

  Posté par Markov () le 16/02/2007 à 16:36. (lien). Évalué à 2.

  Difficile de repondra a ta question sans description precise. De plus quand Xorg sort cela ne veut plus necessairement dire que les drivers videos sont aussi update. Enfin dans la chaine d'affichage graphique il n'y pas que le driver DDX d'xorg qui gere la carte mais aussi le module DRM (kernel), le DRI et Mesa bref tout ca fait qu'il peut y avoir plusieurs sources a tes problemes.
  
  Une description plus precises aiderait, sinon cherche sur le bugzilla de freedesktop.

  • [^]Re: driver radeon

    Posté par cortex62 (page perso, ) le 16/02/2007 à 20:28. (lien). Évalué à 1.

    En effet, si ce sont les perfs 3d qui t' intéressent c' est plutôt Mesa/dri/drm qu' il faut regarder.
    En général les nouvelles de mesa mettent à jour les pilotes DRI , pour les DRM (direct rendering management) c' est plutôt le kernel.

    --
    L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.

RAndR

• [^]Re: RAndR

  Posté par Mjules (page perso, ) le 17/02/2007 à 08:47. (lien). Évalué à 2.

  Si j'ai bien suivi, RanDR 1.2 n'est pas intégré actuellement, il le sera dans le server X 1.3, qui devrait être une mise à jour compatible ABI/API avec le reste de xorg 7.2.
  Xorg 7.3 devrait être quand à lui fourni avec le serveur X 1.4

• [^]Re: RAndR

  Posté par Sylvain (Jabber id, page perso, ) le 17/02/2007 à 09:55. (lien). Évalué à 2.

  C'est pas un probleme de X.org c'est le drivers Nvidia qui fait ca,
  au lieu de t'afficher ton balayage tu as 50,51,52 qui correspond aux modes dual head etc ... C'est un hack nvidia.
  
  
  C'est pour la meme raison que le detecteur de framerate beryl marche pas avec nvidia, et qu'il faut forcer a la main son rafraichisssement ( 80 par ex )

  • [^]Re: RAndR

    Posté par Sylvain (Jabber id, page perso, ) le 17/02/2007 à 09:57. (lien). Évalué à 2.

    Why is the refresh rate not reported correctly by utilities that use the XRandR X extension (e.g., the GNOME "Screen Resolution Preferences" panel, `xrandr -q`, etc)?
    
    
    The XRandR X extension is not presently aware of multiple display devices on a single X screen; it only sees the MetaMode bounding box, which may contain one or more actual modes. This means that if multiple MetaModes have the same bounding box, XRandR will not be able to distinguish between them.
    
    In order to support DynamicTwinView, the NVIDIA X driver must make each MetaMode appear to be unique to XRandR. Presently, the NVIDIA X driver accomplishes this by using the refresh rate as a unique identifier.
    
    You can use `nvidia-settings -q RefreshRate` to query the actual refresh rate on each display device.
    
    This behavior can be disabled by setting the X configuration option "DynamicTwinView" to FALSE.
    
    
    
    http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9746/REA(...)

    • [^]Re: RAndR

      Posté par cedbor () le 17/02/2007 à 19:43. (lien). Évalué à 1.

      Ah ben voui , yavaika RTFM.
      Mais j'ai cherché au mauvais endroit et une récente interview de K. Packard m'a conforté dans mon erreur.
      Tout remarche nickel, merci.

    • [^]Re: RAndR

      Posté par benoar (Jabber id, ) le 18/02/2007 à 12:59. (lien). Évalué à 1.

      A noter qu'on a le même problème avec les ATI quand on utilise MergedFB (l'équivalent du TwinView). Et ça fait un bout de temps que ce problème existe.

      • [^]Re: RAndR

        Posté par Albert () le 18/02/2007 à 15:13. (lien). Évalué à 2.

        Enfin le probleme il est pire sur les ATI vu que cela detruit le matos et il y a assez peu de personne pour se porter volontaire pour verifier que ca et je comprend pourquoi!

        • [^]Re: RAndR

          Posté par benoar (Jabber id, ) le 18/02/2007 à 22:43. (lien). Évalué à 1.

          Gni ? Tu parles de quoi exactement là ? J'ai jamais détruit ma carte à cause de ça...

          • [^]Re: RAndR

            Posté par Albert () le 19/02/2007 à 14:27. (lien). Évalué à 4.

            Je parle de ce "petit" bug:
            
            https://bugs.freedesktop.org/show_bug.cgi?id=4552
            
            Que tu n'est pas detruit ta carte, tant mieux pour toi (moi non plus mais j'ai ete content de pas avoir fait mumuse avec MergeFB...)

            • [^]Re: RAndR

              Posté par benoar (Jabber id, ) le 20/02/2007 à 00:17. (lien). Évalué à 1.

              Oui enfin là on parle pas exactement du même problème : celui de la sélection d'un mode en MergedFB par l'interface graphique (qui bug comme généralement la fréquence ne correspond à rien, puisqu'elle est censée représenter la fréquence de 2 écrans différents, ce qui n'est pas possible et donc les devs ont choisi une valeur unique négative). Si c'est pour troller sur un bug du drivers radeon (qui n'apparait que sur des cartes encore pas vraiment supportées, ou en alpha), ce qui n'a rien à voir, change de topic...

              • [^]Re: RAndR

                Posté par Albert () le 20/02/2007 à 14:21. (lien). Évalué à 2.

                dans ce cas la il serait bienvenu que xorg (ou les distribs) desactive carrement soit l'option MergeFB soit le driver radeon pour ces cartes la car, c'est mon avis et il n'engage que moi, c'est une tres tres mauvaise image pour le xorg/linux si tu detruis ton matos...