CHATTR

Bill wrote:

Bonjour a tous,

Je souhaiterai savoir ce qu'il en est aujourd'hui de la commande lsattr
et chattr

Est ce qu elle est encore bcp utilisée ? Cette commande a l air tres
interessante notamment pour ce qui est de la protection....

Perso j'utilise le mode +a (append)pour .ssh/authorized_keys et
.ssh/known_hosts ainsi que le mode +i (imuable si je me souviens bien) sur
ma clé privée ssh.
Pour ceux qui ont système de sauvegarde via dump le +d peut sembler utile
(je n'ai jamais tésté).
Y a t il qqun qui à déjà tésté le +A. Je me dis que par exemple ne pas
modifier l'access time sur /lib /usr/lib ne doit pas pouvoir pauser de
problème. Me trompe-je ? (je me pose la question parce que mon laptop à un
disque 4500 tours et ca rame )
--
"Mourir pour ses idees ne prouve pas qu'elles soient bonnes."
[ Yvan Audouard ]

Salut,

Perso j'utilise le mode +a (append)pour .ssh/authorized_keys et
.ssh/known_hosts ainsi que le mode +i (imuable si je me souviens bien) sur
ma clé privée ssh.

+a et +u (undeletable) sont aussi TRES TRES interessant pour des fichiers
comme .bash_history ou les fichiers de logs...

Pour ceux qui ont système de sauvegarde via dump le +d peut sembler utile
(je n'ai jamais tésté).

Le +s est sympa aussi, pour ce qui est des clefs privées etc, que l'on peut
vouloir supprimer rapidement et efficacement en cas de probleme de
piratage pour (tenter d') empecher leur recuperation.

@+
Bertrand

Bertrand wrote:

Salut,

Perso j'utilise le mode +a (append)pour .ssh/authorized_keys et
.ssh/known_hosts ainsi que le mode +i (imuable si je me souviens bien) sur
ma clé privée ssh.

+a et +u (undeletable) sont aussi TRES TRES interessant pour des fichiers
comme .bash_history ou les fichiers de logs...

Même si je ne nie pas l'utilité de ces drapeaux dans le cas de SK ou de
scripts permettant de cacher ou faire disparaitre ses traces sur un
serveur, dans le pire des cas cela ne fera que ralentir l'intru.
Ce qui peut-être fait peut-être défait (bien souvent).
Effacer chattr n'est surmeent pas la bonne solution. Existe-t-il un
drapeau dans /proc qu'on pourrait mettre à 1 et qui empêcherait
l'utilisation l'ioctl de changement des ces flags ?

Dernières questions.
Est-ce qu'un trace dans les logs est générée lorsque qu'on tente une
action sur le fichier qui est interdite par un drapeau ?
Connaissez vous une distribution utilisant ses drapeaux dans son
installation par défaut ?
Une URL sur une doc ou un article à propos de chattr ?

-=( manu )=-

Dans l'article news:<bl3ud9$h1j$1@news-reader4.wanadoo.fr>,
Manu <nobody@guzu.net.invalid> écrivait :

Bertrand wrote:

Salut,

Perso j'utilise le mode +a (append)pour .ssh/authorized_keys et
.ssh/known_hosts ainsi que le mode +i (imuable si je me souviens
bien) sur ma clé privée ssh.

+a et +u (undeletable) sont aussi TRES TRES interessant pour des
fichiers comme .bash_history ou les fichiers de logs...

Même si je ne nie pas l'utilité de ces drapeaux dans le cas de SK ou
de scripts permettant de cacher ou faire disparaitre ses traces sur un
serveur, dans le pire des cas cela ne fera que ralentir l'intru.
Ce qui peut-être fait peut-être défait (bien souvent).

Faut-il encore être root, car ces attributs ne sont modifiables que par
root. Du moins pour les attributs les plus intéressants (+i,+a, ...).
De plus faut-il connaître cette fonctionnalité des systèmes de fichiers
ext2/3, ce qui est rarement le cas.

Effacer chattr n'est surmeent pas la bonne solution. Existe-t-il un
drapeau dans /proc qu'on pourrait mettre à 1 et qui empêcherait
l'utilisation l'ioctl de changement des ces flags ?

Non. Mais l'utilisation d'un kernel patché avec grsec (par exemple) permet
de limiter l'utilisation de ces attributs et de ceux qui peuvent les
modifier.

Dernières questions.
Est-ce qu'un trace dans les logs est générée lorsque qu'on tente une
action sur le fichier qui est interdite par un drapeau ?

Non. Avec grsec oui.

Connaissez vous une distribution utilisant ses drapeaux dans son
installation par défaut ?

Non.

Une URL sur une doc ou un article à propos de chattr ?

Le man ? :) Car que dire de plus sur son utilisation simple.

--
TiChou

TiChou wrote:

Faut-il encore être root, car ces attributs ne sont modifiables que par
root. Du moins pour les attributs les plus intéressants (+i,+a, ...).
De plus faut-il connaître cette fonctionnalité des systèmes de fichiers
ext2/3, ce qui est rarement le cas.

Je ne pense pas que cela soit une excuse suffisante. Par exemple, si
peut/veut modifié les fichiers de logs ou changer un binaire c'est très
certainement qu'on est root.

Non. Mais l'utilisation d'un kernel patché avec grsec (par exemple) permet
de limiter l'utilisation de ces attributs et de ceux qui peuvent les
modifier.

Bah j'ai cherché dans la conf et dans le patch et j'ai rien trouvé.
Sur mon système, qui n'a peut-être pas la bonne option activée, un test
rapide genre:
# touch REMOVEME
# chattr +i REMOVEME
# rm REMOVEME
rm: remove write-protected file `REMOVEME'? y
rm: cannot unlink `REMOVEME': Operation not permitted
#

ne génère aucune trace dans les logs...

Une URL sur une doc ou un article à propos de chattr ?

Le man ? :) Car que dire de plus sur son utilisation simple.

Je pensais plus à des cas pratiques déjà rencontré par des utilisateurs
avec une application précise (genre les exemples avec ssh dans les posts
précédents).

Ces attributs sont interessants contre des fausses manipulations, même
du root, mais d'un point de vue sécurité je ne trouve pas que cela
apporte grand chose (dans l'état actuel).

-=( manu )=-

Dans sa prose, TiChou nous ecrivait :

Non. Mais l'utilisation d'un kernel patché avec grsec (par exemple)
permet de limiter l'utilisation de ces attributs et de ceux qui peuvent
les modifier.

Avec LIDS, on peut forcer ces attributs au niveau kernel directement.

--
BOFH excuse #424:

operation failed because: there is no message for this error (#1014)

Dans l'article news:<bl4nfb$pn5$1@news-reader4.wanadoo.fr>,
Manu <nobody@guzu.net.invalid> écrivait :

Faut-il encore être root, car ces attributs ne sont modifiables que
par root. Du moins pour les attributs les plus intéressants (+i,+a,
...).
De plus faut-il connaître cette fonctionnalité des systèmes de
fichiers ext2/3, ce qui est rarement le cas.

Je ne pense pas que cela soit une excuse suffisante.

D'un point de vue sécurité, vous avez entièrement raison.

Par exemple, si peut/veut modifié les fichiers de logs ou changer un
binaire c'est très certainement qu'on est root.

C'est bien ce que je disais, faut-il être root. :)

Non. Mais l'utilisation d'un kernel patché avec grsec (par exemple)
permet de limiter l'utilisation de ces attributs et de ceux qui
peuvent les modifier.

Bah j'ai cherché dans la conf et dans le patch et j'ai rien trouvé.
Sur mon système, qui n'a peut-être pas la bonne option activée, un
test rapide genre:
# touch REMOVEME
# chattr +i REMOVEME
# rm REMOVEME
rm: remove write-protected file `REMOVEME'? y
rm: cannot unlink `REMOVEME': Operation not permitted
#

ne génère aucune trace dans les logs...

Le même type de test rapide :

root@pegase:/tmp# rm pwet
root@pegase:/tmp# :>pwet
root@pegase:/tmp# chattr +i pwet
chattr: Operation not permitted while setting flags on pwet
root@pegase:/tmp# dmesg|tail -1
grsec: From 192.168.150.3: use of CAP_LINUX_IMMUTABLE denied for
(chattr:30312) UID(0) EUID(0), parent (bash:30130) UID(0) EUID(0)

Vos ACLs ont-ils été chargé et configuré correctement ?

Une URL sur une doc ou un article à propos de chattr ?

Le man ? :) Car que dire de plus sur son utilisation simple.

Je pensais plus à des cas pratiques déjà rencontré par des
utilisateurs avec une application précise (genre les exemples avec
ssh dans les posts précédents).

Ces attributs sont interessants contre des fausses manipulations, même
du root, mais d'un point de vue sécurité je ne trouve pas que cela
apporte grand chose (dans l'état actuel).

Ils peuvent contrer l'utilisation de certain script kiddie, qui par exemple
lors d'une exploitation d'une faille vont tenter de créer un bindshell en
ajoutant une ligne dans le fichier /etc/inetd.conf, d'installer un rootkit
en remplaçant les fameux /sbin/ifconfig, /sbin/netstat, /bin/ps, /bin/login,
de backdooriser /usr/sbin/sshd.

Mais vous avez raison, ce qui a été fait peut être défait et ici tout ce qui
compte c'est de se donner tous les moyens possible pour limiter ce qui peut
être défait... dans le temps.

--
TiChou

Salut,

Je ne pense pas que cela soit une excuse suffisante. Par exemple, si
peut/veut modifié les fichiers de logs ou changer un binaire c'est
très certainement qu'on est root.

Dans le cas des auto-rooters, ces attributs offrent une protection trés
interessante. Pourquoi? Parce que ces machins là, soit ca marche, soit ca
marche pas. Et si ca marche pas, ca passe a la machine suivante...
(ne me dites pas "ouai mais faut mettre sa machine à jour", car d'une
part personne ne peut pretendre toujours etre patché (le moment dangereux
est celui entre le moment où l'exploit sort et le moment où vous patchez)
et personne ne peut pretendre etre invincible aux 0days).

Quand à l'exemple du .bash_history, celui que bizarrement vous avez le
moins critiqué ;), il faut savoir que la protection du +u +a est assez
illusoire pour peu que l'utilisateur sache changer une variable d'env. (le
shell va allez logger dans /dev/null tout gentillement) Ceci dit, c'est
toujours marrant d'observer les logs d'execution de GrSec et de voir que
le bonhomme s'est amusé a se planquer pour faire des betises.

Si vous n'avez pas de protection, vous ne pouvez pas accuser la personne
de faire des betises. Ou alors elle vous dira "je pensais pas que c'etait
reprehensible".
Si vous avez une protection et que la personne est passée outre, là vous
avez une bonne raison pour fermer le compte. Car le fait d'essayer de
passer outre les logs fait admettre implicitement à la personne qu'elle
veut faire une annerie...

Bah j'ai cherché dans la conf et dans le patch et j'ai rien trouvé.
Sur mon système, qui n'a peut-être pas la bonne option activée, un
test rapide genre:
...
ne génère aucune trace dans les logs...

Encore faut-il que les options de logging et les ACLs soient correctement
configurées.

Je pensais plus à des cas pratiques déjà rencontré par des
utilisateurs avec une application précise (genre les exemples avec ssh
dans les posts précédents).

C'est quand meme bien sympa de mettre des attributs un peu partout et de
remplacer chattr par une version patchée qui ne fait rien, et d'utiliser
egalement un lsattr patché qui affiche toujours -------------, ou alors qui
ne fait quelquechose que si un certain parametre est donné (mais alors il
ne faut pas stoquer de script utilisant ce parametre sur la machine, sinon
l'astuce risque d'etre vite decouverte). Soit le type part sur une autre
machine, soit il reste chez vous si votre machine l'interesse. Mais ca
permet d'eliminer une certaine categorie de "pirates", c'est donc à garder.

Je trouve que patcher les outils systeme c'est sympa. Car a chaque foi que
j'ai vu un piratage, le bonhomme utilisait -toujours- les outils presents
sur la machine.
Ok, on peut passer outre, mais ca plus GrSec, ca commence a etre assez
efficace.

Sinon, mettre des +i partout dans le chroot d'un daemon doit pouvoir
offrir une certaine protection au cas où quelqu'un arrive a entrer dans le
chroot (c'est bien beau d'avoir un shell, mais si on ne peut toucher à
rien avec...)
Avec GrSec en plus pour eviter que la personne sorte du Chroot, ca ne doit
pas etre trop mauvais niveau secu.

Il faut clairement voir les attributs de chattr comme ceux modifiés par
chmod. C'est pareil, sauf que les attributs de chattr ne peuvent être
modifiés que par root. Tout le monde parle sans arret de securisation des
droits, alors pourquoi ne pas utiliser les attributs de chattr egalement ?
Il ne faut pas rejeter une protection sous pretexte qu'elle peut etre
contournée dans certains cas. Il faut simplement en etre conscient, et il
faut aussi voir ce que la protection apporte dans les cas où elle ne peut
pas etre contournée.

Ces attributs sont interessants contre des fausses manipulations, même
du root, mais d'un point de vue sécurité je ne trouve pas que cela
apporte grand chose (dans l'état actuel).

Avec GrSec si.
Avec LIDS c'est possible egalement, je sais pas.

Maintenant peut etre que je me trompe...

@+
Bertrand

TiChou wrote:

Le même type de test rapide :

root@pegase:/tmp# rm pwet
root@pegase:/tmp# :>pwet
root@pegase:/tmp# chattr +i pwet
chattr: Operation not permitted while setting flags on pwet
root@pegase:/tmp# dmesg|tail -1
grsec: From 192.168.150.3: use of CAP_LINUX_IMMUTABLE denied for
(chattr:30312) UID(0) EUID(0), parent (bash:30130) UID(0) EUID(0)

Vos ACLs ont-ils été chargé et configuré correctement ?

Honte a moi, j'avoue ne pas m'être interessé aux ACL et au système
d'apprentissage lié aux ACL.

-=( manu )=-