View previous topic :: View next topic |
Author |
Message |
lavish Bodhisattva
Joined: 13 Sep 2004 Posts: 4296
|
Posted: Thu Mar 02, 2006 8:23 pm Post subject: grsecurity: problemi con ssh |
|
|
Salve a tutti!
Sto provando grsecurity sul mio server, ma ho dei problemi che non riesco a risolvere. Le versioni dei sw usati sono queste (con profilo hardened su x86):
[ebuild R ] sys-kernel/hardened-sources-2.6.14-r5 -build -doc -symlink 0 kB
[ebuild R ] sys-apps/gradm-2.1.8.200601212342 +pam 0 kB
[ebuild R ] net-misc/openssh-4.2_p1-r1 -X509 -chroot -hpn -ipv6 -kerberos -ldap -libedit +pam (-selinux) -sftplogging -skey -smartcard -static +tcpd 0 kB
Ora, la configurazione che ho usato come "prova" per grsec è quella di default, la riposto per comodità vostra:
Code: | nebula ~ # sed -e '/^$/d' -e '/^#/d' $* /etc/grsec/policy
role admin sA
subject / rvka
/ rwcdmlxi
role default G
role_transitions admin
subject /
/ r
/opt rx
/home rwxcd
/mnt rw
/dev
/dev/grsec h
/dev/urandom r
/dev/random r
/dev/zero rw
/dev/input rw
/dev/psaux rw
/dev/null rw
/dev/tty0 rw
/dev/tty1 rw
/dev/tty2 rw
/dev/tty3 rw
/dev/tty4 rw
/dev/tty5 rw
/dev/tty6 rw
/dev/tty7 rw
/dev/tty8 rw
/dev/console rw
/dev/tty rw
/dev/pts rw
/dev/ptmx rw
/dev/dsp rw
/dev/mixer rw
/dev/initctl rw
/dev/fd0 r
/dev/cdrom r
/dev/mem h
/dev/kmem h
/dev/port h
/bin rx
/sbin rx
/lib rx
/usr rx
/etc rx
/proc rwx
/proc/kcore h
/proc/sys r
/root r
/tmp rwcd
/var rwxcd
/var/tmp rwcd
/var/log r
/boot r
/etc/grsec h
/usr/sbin/sshd
-CAP_KILL
-CAP_SYS_TTY_CONFIG
-CAP_LINUX_IMMUTABLE
-CAP_NET_RAW
-CAP_MKNOD
-CAP_SYS_ADMIN
-CAP_SYS_RAWIO
-CAP_SYS_MODULE
-CAP_SYS_PTRACE
-CAP_NET_ADMIN
-CAP_NET_BIND_SERVICE
-CAP_SYS_CHROOT
-CAP_SYS_BOOT
subject /usr/sbin/sshd dpo
/ h
/bin/bash x
/dev h
/dev/log rw
/dev/random r
/dev/urandom r
/dev/null rw
/dev/ptmx rw
/dev/pts rw
/dev/tty rw
/dev/tty? rw
/etc r
/etc/grsec h
/home
/lib rx
/root
/proc r
/proc/kcore h
/proc/sys h
/usr/lib rx
/usr/share/zoneinfo r
/var/log
/var/mail
/var/log/lastlog rw
/var/log/wtmp w
/var/run/sshd
/var/run/utmp rw
-CAP_ALL
+CAP_CHOWN
+CAP_SETGID
+CAP_SETUID
+CAP_SYS_CHROOT
+CAP_SYS_RESOURCE
+CAP_SYS_TTY_CONFIG
subject /usr/X11R6/bin/XFree86
/dev/mem rw
+CAP_SYS_ADMIN
+CAP_SYS_TTY_CONFIG
+CAP_SYS_RAWIO
-PAX_SEGMEXEC
-PAX_PAGEEXEC
-PAX_MPROTECT
subject /sbin/klogd
+CAP_SYS_ADMIN
subject /usr/sbin/cron
/dev/log rw
|
Ovviamente non può essere completamente adeguata, ma volevo capire il perchè di questo problema con openssh:
darkstar è il client
nebula è il server con grsec
Code: | nebula ~ # gradm -S
The RBAC system is currently disabled.
lavish@darkstar ~ $ ssh -p 4022 192.168.0.4 [WORKS]
nebula ~ # gradm -E
lavish@darkstar ~ $ ssh -p 4022 192.168.0.4
ssh_exchange_identification: Connection closed by remote host
nebula ~ # gradm -a admin
Password:
nebula ~ # /etc/init.d/sshd restart
* Stopping sshd ... [ ok ]
* Starting sshd ...
lavish@darkstar ~ $ ssh -p 4022 192.168.0.4 [WORKS]
nebula ~ # gradm -u
lavish@darkstar ~ $ ssh -p 4022 192.168.0.4
ssh_exchange_identification: Connection closed by remote host |
Guardando nei logs trovo questo:
Code: | Mar 2 21:05:37 [sshd] fatal: Missing privilege separation directory: /var/empty |
Avete qualche idea?
Vi ringrazio in anticipo!
// edit: tanto per darvi ulteriori elementi: /etc/hosts.{allow,deny} non sono presenti _________________ minimalblue.com | secgroup.github.io/ |
|
Back to top |
|
|
Dece Apprentice
Joined: 23 Nov 2004 Posts: 291 Location: Bologna/Rimini Italy
|
Posted: Fri Mar 03, 2006 2:14 pm Post subject: |
|
|
Credo che il problema sia questo: il demone ssh all'inizio è eseguito con privilegi di utente root, quindi senza abilitare rbac tutto funziona. Quando però viene abilitato rbac, ssh assume il ruolo "default" (pur continuando ad avere diritti di root) che non permette di fare tutti i dovuti accessi: riavviando ssh da ruolo "admin", allora ha tuti i privilegi del ruolo admin sul sistema e può fare quel che gli pare
Il mio consiglio è creare una policy con il full learning di gradm (mi sembra gradm -F -L fileDiLog, poi un altro comando per processare il log e creare la policy.... non ho il man sotto mano ), così dovrebbe creare il ruolo "sshd" e far funzionare tutto a dovere.
Una soluzione più "grossolana" sarebbe quella di aggiungere i privilegi su /var/empty (o su /var...) nel subject /usr/sbin/sshd. Per esempio
Code: | subject /usr/sbin/sshd dpo
...
/var/empty rw
/var/log
/var/mail
... |
ma non è detto che sia sufficiente
Ciao! |
|
Back to top |
|
|
lavish Bodhisattva
Joined: 13 Sep 2004 Posts: 4296
|
Posted: Fri Mar 03, 2006 3:36 pm Post subject: |
|
|
Dece wrote: | Il mio consiglio è creare una policy con il full learning di gradm (mi sembra gradm -F -L fileDiLog, poi un altro comando per processare il log e creare la policy.... non ho il man sotto mano ), così dovrebbe creare il ruolo "sshd" e far funzionare tutto a dovere. |
è quello che sto provando ora
Mi sarebbe interessato capire realmente perchè non funzionava prima visto che mi sembrava una situazione un po' strana.. comunque finita la learning mode proverò di sicuro
Il guaio di RBAC è che non è stata ancora scritta della doc decente per versione 2
Grazie, ti farò sapere! _________________ minimalblue.com | secgroup.github.io/ |
|
Back to top |
|
|
Dece Apprentice
Joined: 23 Nov 2004 Posts: 291 Location: Bologna/Rimini Italy
|
Posted: Fri Mar 03, 2006 3:57 pm Post subject: |
|
|
lavish wrote: |
Mi sarebbe interessato capire realmente perchè non funzionava prima visto che mi sembrava una situazione un po' strana..
|
RBAC ridefinisce uno strato aggiuntivo di permessi sul sistema, che sono "prioritari" rispetto a quelli standard e più finemente definiti: paradossalmente l'utente root, nel sistema RBAC, può essere più limitato di un utente qualsiasi. Inoltre, i permessi in RBAC, non vengono controllati a partire da /, ma dalle "foglie", e ricorsivamente all'indietro: ad esempio, nel casi di /var/empty, prima vengono cercati i permessi specifici per /var/empty: se non vengono trovati, allora si cercano i permessi per /var: se non vengono trovati allora applicano i permessi per /; questo è appunto il caso di quella policy, ovvero veniva applicato il solo permesso "h" (hidden) che era riferito a /, per ssh. Spero di non essere stato troppo caotico
lavish wrote: |
Il guaio di RBAC è che non è stata ancora scritta della doc decente per versione 2
|
Vero, quando ci ho fatto la tesi ho un po' imprecato per riunire le varie cose se ti può essere utile, ti mando la parte relativa ad RBAC |
|
Back to top |
|
|
lavish Bodhisattva
Joined: 13 Sep 2004 Posts: 4296
|
Posted: Fri Mar 03, 2006 4:14 pm Post subject: |
|
|
Dece wrote: | Vero, quando ci ho fatto la tesi ho un po' imprecato per riunire le varie cose se ti può essere utile, ti mando la parte relativa ad RBAC |
Sì!!! Te ne sarei davvero grato! (Anzi... già ora ti sono grato.. diciamo che sarei ++grato )
Ti lascio l'indirizzo e-mail: lavish at gmail dot com
_________________ minimalblue.com | secgroup.github.io/ |
|
Back to top |
|
|
.:deadhead:. Advocate
Joined: 25 Nov 2003 Posts: 2963 Location: Milano, Italy
|
|
Back to top |
|
|
Dece Apprentice
Joined: 23 Nov 2004 Posts: 291 Location: Bologna/Rimini Italy
|
Posted: Fri Mar 03, 2006 6:18 pm Post subject: |
|
|
La tesi era uno studio delle varie soluzioni per l'incremento della sicurezza in Linux, in particolare per quanto riguardava il controllo dell'accesso e la suddivisione utente-superutente: avevo continuato un'altra tesi che illustrava il Mandatory Access Control e SELinux, concentrandomi su GRsecurity una tesi triennale, principalmente compilativa, ma che mi ha interessato molto |
|
Back to top |
|
|
|