Pour les utilisateurs de dispositifs USB, sous FC3, que vous renvoie la commande ?

ps -ef |grep hotplug |wc -l

Moi ca renvoie 129 (!)

J'ai des soucis d'USB depuis l'installation de ma FC3.
J'ai fait tous les upgrade recommandés. Par exemple :

- clé absolument pas reconnue (alors que FC1 ok)
- lsusb qui se boque "ad vitam aeternam"
- config de l'imprimante qui bloque pareil

Alors je cherche...

A+

JC
JCLL a écrit:
ps -ef |grep hotplug |wc -l
Moi çà renvoie 1.
ca veut rien dire marcet
ps -ef |grep hotplug |wc -l me renvoie 1 aussi mais si tu fais juste ps -ef |grep hotplug, tu verras qu'il te retrouve juste un process corespondant à ta recherche sur hotplug, donc nib !

600 5377 5291 0 15:19 pts/1 00:00:00 grep hotplug

question pourquoi compter le nombre de ligne ?
est-ce que ce serait pas encore un effet de selinux (désactiver avec 'setenforce 0' sous root 'su -')?
Quel est l'apport de SELinux (à part les emmerdes) en supposant bien entendu qu'on ne se place pas du point de vue de la NSA ?
<troll>
ben je suis pas spécialiste de la sécurité mais aujourd'hui être sous linux avec son petit iptable qui va bien c'est plus suffisant pour éviter de se faire hacker salement.
</troll>
personnellement je suis un peu dépassé par la conf de selinux pour l'instant ...
sinon il y a bastille qui permet de sécuriser pas mal de point sur ton système préféré...
C'est effectivement pas évident à gérer.
A l'install, je me suis contenté de mettre "Avertir" dans la config SELinux et pour le moment il me fout une paix royale.

Mais, j'aime bien comprendre ce que je fait. Bon c'est un autre sujet. Pour le moment place au préparatifs de la fête...

Bon réveillon à tous.
Quel est l'apport de SELinux (à part les emmerdes) en supposant bien entendu qu'on ne se place pas du point de vue de la NSA ?
Absolument a rien... Si tu es sur ta machine tout seul a la maison. La ou ca devient interessant, c'est quand plusieurs utilisateurs ont acces a une machine et que tu n'as pas forcement confiance en ces utilisateurs... Contrairememt au firewall qui va empecher les attaques distantes, selinux s'interessent plutot aux attaques en local (qui representent une grosse majorité des attaques). Ca va permettre de renforcer (modifier) les controles d'acces pour eviter que le premier mec mal intentioné qui passe te fasse un buffer over flow pour gagner un acces root. C'est surtout dans ce genre d'attaques que selinux intervient. Mais il est clair que pour 99 % des utilisateurs de ce forum, selinux est totalement inutile!! C'est pour ca que je trouve ca dommage de l'activé par defaut. Et puis en general les gens qui ont a l'activé savent ce qu'ils font.
Salut !

Tu peux m'expliquer ta remarque sur ps -ef |grep hotplug | wc -l ?

Je voulais seulement savoir si c'était normal que j'ai 129 process faisant appel au hotplug... Je pense que non.

Tu penses que mon pb vient de selinux (connais pas) ??? C'est bien ca ?

A+

JC
Merci beaucoup Maître Valhalla pour ces précisions.

Bon réveillon à toi !!!
  • [supprimé]

Merci, et bonne année a toi!!!

valhalla, qui n'a pas la force de se connecter
Le point de vue de valhalla est fondé mais semble un peu restrictif ... SELinux est une évolution importante en matière de sécurité, y compris pour des machines "mono utilisateur"... Je m'explique.

Les éléments de base sont à l'adresse: http://fedora.redhat.com/docs/selinux-faq-fc3/

SELinux (Security-Enhanced Linux) repose sur les principes suivants:

* mise en oeuvre du contrôle d'accès obligatoire (Mandatory Access Control (MAC)) au sein du noyau en respectant le schéma Linux Security Modules (LSM) framework [c'est du blabla ?... cela pour dire que l'approche est normalisée, documentée et auditable; il ne s'agit pas d'une pure initiative Red Hat mais de normes et outils qui émergent et vont se propager sans doute dans le monde Linux]

* dans le système Linux, à la base, la sécurité repose sur un schéma simple (dit Discretionary Access Control (DAC)): les fichiers (dont les périphériques) portent des attributs (rwx), les processus sont lancés par des propriétaires et le contrôle d'utilisation d'une ressource consiste à établir les droits du propriétaire du processus sur les fichiers/ressources que ce processus sollicite. Le processus considéré, s'il y est autorisé, a dès lors tout "pouvoir" sur les objets qu'il utilise, dès lors que les droits qui lui sont conférés sur cet objet (rwx) sont conformes. On sait qu'en certaines circonstances, un uilisateur peut bénéficier de certains droits complémentaires, en héritage, par le mécanisme des setuid et setgid. Par exemple, en schématisant, pour imprimer, un utilisateur hérite de certains droits root qui lui permettent d'écrire dans un répertoire et de lancer des actions, pour lesquelles il n'a pas les droits au départ. Il hérite normalement de ces droits uniquement pour l'action considérée ...
Ce mécanisme ouvre une brèche importante: en certains cas, un utilisateur peut ainsi se voir conférer des droits supplémentaires qui normalement ne devraient pas lui être reconnus (c'est en particulier par ce moyen que des programmes "corrompus" peuvent accéder à des ressources qui normalement ne leur étaient pas accessibles).

* SELinux fournit des moyens complémentaires pour renforcer la politique de sécurité sur un système: les décisions concernant l'utilisation des ressources peuvent être très fines et ne plus seulement reposer sur l'identité de l'utilisateur mais sur des règles précises (contrôle des process et des fichiers/ressources, ce que la littérature nomme rapidement les objets ...).

Les permissions peuvent ainsi gérées sous une maille très fine pour les utilisateur, les programmes, les process, les fichiers et les ressources. Comme le dit la FAQ: "You can safely grant an application just the permissions it needs to do its function, and no more". Vous pouvvez en toute sécurité conférer à une application les strictes permissions dont elle a besoin pour réaliser sa fonction, et pas plus" ... ouah la traduction! p-))

* SELinux utilise un schéma dit role-based access control (RBAC):

- rôle pour un utilisateur
- type de contraintes (Type Enforcement (TE)).
TE utilise une table qui croise les actions
et les types d'objets (fichiers, ressources)

Un utilisateur se voit donc contrôler pour une action spécifique sur un objet donné; la maille peut ainsi être très très fine! et beaucoup plus fine que le simple contrôle opéré sur l'identité de l'utilisateur. Un exemple schématique:

alpha est propriétaire du fichier A
alpha a donné sur A les droits X pour son groupe
beta appartient au groupe d'alpha
beta peut donc normalement exécuter le fichier A

Avec SELInux, on peut fermer ce droit à beta, pour le fichier A mais pas pour un autre fichier B ...

La mise en oeuvre d'un tel dispositif peut s'avérer complexe et risque, si elle n'est pas pleinement maîtrisée, d'occasionner quelques déboires sérieux. Comme le précise la FAQ, "it became obvious that applying a single strict policy to the many environments of Fedora users was not feasible. Managing a single strict policy for anything other than default installation was going to require local expertise". Il est devenu clair [au départ, dans Fedora, SELinux était mis en oeuvre de façon stricte] qu'appliquer une stricte et unique politique à une grande variété d'environnements d'utilisateurs de Fedora n'était pas possible. Gérer une stricte et unique politique pour tout en dehors d'un schéma par défaut allait requérir une expertise (la traduction n'est pas littérale ...)

Les développeurs de SELinux ont alors révisé leurs choix et décidé de concentrer leur attentionsur certains daemons, vulnérables à des attaques qui peuvent compromettre ou détruire un système. Le reste du système tournerait alors sous le dispositif Linux standard, que SELinux soit ou non activé.

Les daemons qui sont gérés au travers de SELInux sont: dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid, and syslogd (voir /etc/selinux/targeted/src/policy/domains/program).

Nota: mysql et postgres ont notamment été rajoutés dans la version policy. Pour lister les daemons qui entrent dans le champ, passer, sous root, dans une console, la commande: /usr/sbin/sestatus -v

Quel utilisateur ne fait pas tourner syslogd? Quel utilisateur ne va pas synchroniser son horloge locale sur un serveur temps? qui n'a pas laissé tourner portmap (et nfs?).


La conclusion, maintenant.

Un système Linux peut n'accueillir qu'un seul utilisateur en chair et en os (sans compter root, bien sûr) mais pour autant, il fait tourner de nombreux process qui réalisent des actions dont l'utilisateur n'a pas nécessairement conscience. SELinux renforce la sécurité de l'utilisateur, seul et solitaire sur sa machine, et le prémunit contre un ensemble d'actions préjudiciables, qui pourraient intervenir "à l'insu de son plein gré"... Sous sa mise en oeuvre immédiate, SELinux n'est pas contraignant même si certains rpm de certaines sources peuvent éprouver quelques difficultés à supporter les librairies SELinux (voir d'autres posts ... notamment mentionnant les symptômes douloureux: ldconfig ne fonctionne plus!). En perspective, c'est une plate forme extraordinaire pour renforcer la sécurité, pour le plus grand bénéfice des utilisateurs, même seuls face à leur machine.


Bonne année et bonne chance à SELinux!
SElinux est une avancée technique et ça ameliore la sécurité du système, donc il est normal que RH et les devs veuillent l'integrer. Certes l'interet est plus interessant pour un serveur ou une worskstation, mais un des but principal de la fedora est d'implementer les nouvelles technos interessantes, les rendre utilisable pour les passer dans la RHEL-qui elle vise ce marché.
D'ailleurs malgré les améliorations apportés,on aurait pu attendre longtemps avant qu'une distrib l'implemente et donc rende SElinux utilisable, c'est la meme situation que 4stack, si la fedora ne l'impose pas et l'ameliore, on pourrait attendre longtemps avant de l'utiliser.
Je parie qu'à Mandrake, ils doivent etre content que la fedora leur ait débrousaillé le chemin pour leur future distrib ultrasécurisé avec SElinux.
Entre la FC2 et la FC3, le progrès est net, les devs ont fait un boulot remarquable sur Selinux, notamment en passant du comportement strict à targeted qui ne met sous le controle de SElinux que quelques demons specifiques jugés les plus dangereux.
la plupart des problemes ne vient pas seulement de SElinux mais des autres softs qui ne sont pas adaptés à la gestion des droits version SElinux, ça oblige les devs à en tenir compte (comme la FC2 a obligé Nvidia a modifié son driver)
Merci Herrib pour ces compléments d'information.

Bonne année.
14 jours plus tard
A propos de SELINUX

Lors d'un boot "I" interactif , j'ai un :
demarrer le service nscd
/usr/sbin/nscd .... libselinux.so.1 failed segments .....Permission denied.



et une fois dans un terminal, je lance /usr/sbin/sestatus -v
ça donne :
[root@localhost]# /usr/sbin/sestatus -v
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 18
Policy from config file:targeted

Policy booleans:
allow_ypbind active
dhcpd_disable_trans inactive
httpd_disable_trans inactive
httpd_enable_cgi active
httpd_enable_homedirs active
httpd_ssi_exec active
httpd_tty_comm inactive
httpd_unified active
mysqld_disable_trans inactive
named_disable_trans inactive
named_write_master_zonesinactive
nscd_disable_trans inactive
ntpd_disable_trans inactive
portmap_disable_trans inactive
postgresql_disable_transinactive
snmpd_disable_trans inactive
squid_disable_trans inactive
syslogd_disable_trans inactive
winbind_disable_trans inactive
ypbind_disable_trans inactive

Process contexts:
Current context: root:system_r:unconfined_t
Init context: user_u:system_r:unconfined_t
/sbin/mingetty user_u:system_r:unconfined_t
/usr/sbin/sshd user_u:system_r:unconfined_t

File contexts:
Controlling term: root:object_r:devpts_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t
/bin/login system_u:object_r:bin_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_ t
/sbin/agetty system_u:object_r:sbin_t
/sbin/init system_u:object_r:init_exec_t
/sbin/mingetty system_u:object_r:sbin_t
/usr/sbin/sshd system_u:object_r:sbin_t
/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:shlib_t
/lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t






ma question : Comment ne plus avoir l'erreur du boot et ma protection actuelle est-elle bonne ( sachant que je veux juste surfer sur le Net et pas avoir d'intrusion qui puisse detruire mon OS) 🙁