Ankündigung

**makki** · 27.04.2011, 22:45

Init-script sieht wie aus (oder ist es meins?

)
"update-rc.d eibd defaults" ist unverändert richtig, auch mit squeeze..

Makki

**Sipple** · 28.04.2011, 06:33

Moin Moin

Hier mal das Startscript:

Code:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          EIBD
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start EIB-Daemon
# Description:       This file is used to start the EIB-Daemon during system startup.
#                    It should be placed in /etc/init.d.
### END INIT INFO

# Author:
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="EIB/KNX network stack"
NAME=eibd
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="-D -T -S -d -i --pid-file=/var/run/eibd.pid ipt:192.168.178.39"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
sleep 5
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
    # Return
    #   0 if daemon has been started
    #   1 if daemon was already running
    #   2 if daemon could not be started
    start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
        || return 1
    start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
        $DAEMON_ARGS \
        || return 2
    # Add code here, if necessary, that waits for the process to be ready
    # to handle requests from services started subsequently which depend
    # on this one.  As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
    # Return
    #   0 if daemon has been stopped
    #   1 if daemon was already stopped
    #   2 if daemon could not be stopped
    #   other if a failure occurred
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
    RETVAL="$?"
    [ "$RETVAL" = 2 ] && return 2
    # Wait for children to finish too if this is a daemon that forks
    # and if the daemon is only ever run from this initscript.
    # If the above conditions are not satisfied then add some other code
    # that waits for the process to drop all resources that could be
    # needed by services started subsequently.  A last resort is to
    # sleep for some time.
    start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
    [ "$?" = 2 ] && return 2
    # Many daemons don't delete their pidfiles when they exit.
    rm -f $PIDFILE
    return "$RETVAL"
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
    #
    # If the daemon can reload its configuration without
    # restarting (for example, when it is sent a SIGHUP),
    # then implement that here.
    #
    start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
    return 0
}

case "$1" in
  start)
    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    do_start
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  stop)
    [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
    do_stop
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  #reload|force-reload)
    #
    # If do_reload() is not implemented then leave this commented out
    # and leave 'force-reload' as an alias for 'restart'.
    #
    #log_daemon_msg "Reloading $DESC" "$NAME"
    #do_reload
    #log_end_msg $?
    #;;
  restart|force-reload)
    #
    # If the "reload" option is implemented then remove the
    # 'force-reload' alias
    #
    log_daemon_msg "Restarting $DESC" "$NAME"
    do_stop
    case "$?" in
      0|1)
        do_start
        case "$?" in
            0) log_end_msg 0 ;;
            1) log_end_msg 1 ;; # Old process is still running
            *) log_end_msg 1 ;; # Failed to start
        esac
        ;;
      *)
          # Failed to stop
        log_end_msg 1
        ;;
    esac
    ;;
  *)
    #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
    echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
    exit 3
    ;;
esac

:

Ich habe heute Nacht auch mal wieder eine Lösung gefunden. Steht im Script schon drin: sleep 5 gleich nach SCRIPTNAME=...
Ich würde trotzdem gerne verstehen, worauf genau der EIBD warten muss, damit das sicher klappt. Die "Nicht als root starten" Warnung ist sogar recht nützlich, weil man daran sieht, dass der EIBD ohne das sleep Kommando sehr wohl startet, sich dann aber ohne jegliche weitere Meldung wieder beendet. Ich habe auch mal stdout und error vom EIBD in Dateien umgeleitet. stdout ist danach leer, error enthält genau die bekannte Warnung "W00000001: EIBD should not run as root". Hilft mir also auch nicht weiter. In /var/log/ habe ich auch nichts gefunden.
Kann man beim EIBD Aufruf mit --error=<waskommtdarein?> und/oder --trace=<undhier?> oder sonstwie dafür sorgen, dass man mitbekommt WARUM er sich wieder beendet hat?

Gruß, Martin

**dundee** · 28.04.2011, 20:38

Hallo Martin,

Zitat von Sipple Beitrag anzeigen

Ich habe heute Nacht auch mal wieder eine Lösung gefunden. Steht im Script schon drin: sleep 5 gleich nach SCRIPTNAME=...
Ich würde trotzdem gerne verstehen, worauf genau der EIBD warten muss, damit das sicher klappt.

Bin bei Ubuntu 10.10 über ein ähnliches Problem gestolpert.
Bei mir reichte ein sleep 1.
Ich häng mit einer TPUART am Bus.
Ist ein reines Bauchgefühl, aber ich glaub, dass die serielle Schnittstelle mit ihrer Initialisierung noch nicht fertig ist und man deshalb einen sleep braucht.

**mkoegler** · 28.04.2011, 21:54

Zitat von dundee Beitrag anzeigen

Ich häng mit einer TPUART am Bus.
Ist ein reines Bauchgefühl, aber ich glaub, dass die serielle Schnittstelle mit ihrer Initialisierung noch nicht fertig ist und man deshalb einen sleep braucht.

Glaube ich eher nicht.

Das Skript hat kein Dependency zum Netzwerk deklariert - der KNXnet/IP Server braucht aber ein Netzwerk. Zur Eingrenzung würde ich es ohne aktivierten KNXnet/IP Server probieren.

Für mehr Infos müßte man den eibd mit -t1023 starten.

**makki** · 28.04.2011, 22:00

Denke auch das es das ist, bei mir steht da:
# Required-Start: $local_fs $remote_fs $network

und danach update-rc.d ..

Makki

**Sipple** · 29.04.2011, 07:18

Danke Euch allen.
Das kommt der Sache näher. Werde ich die Tage mal alles versuchen.
Die Schnittstelle (IP Tunneling) kanns eigentlich nicht sein, dann müsste das ja auch passieren wenn ich später manuell starte.

Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet? Ich habe mir meines dahingehend geändert, der EIBD startet auch mit der anderen userid, aber er wird anscheinend nicht in den Hintergrund geschoben. D.h., der Bootvorgang wird bei laufendem EIBD unterbrochen. Ich kann dann nur noch per Putty auf den Server, die Standardkonsole hängt bis ich dort CTRL-C drücke oder den Prozess über Putty kille. Dann fliegt der EIBD wieder raus und das Booten geht weiter. Ist bestimmt nur ne Winzigkeit. Dann könnte ich mal vergleichen.

Gruß, Martin

**mkoegler** · 29.04.2011, 21:53

Zitat von Sipple Beitrag anzeigen

Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet? Ich habe mir meines dahingehend geändert, der EIBD startet auch mit der anderen userid, aber er wird anscheinend nicht in den Hintergrund geschoben. D.h., der Bootvorgang wird bei laufendem EIBD unterbrochen. Ich kann dann nur noch per Putty auf den Server, die Standardkonsole hängt bis ich dort CTRL-C drücke oder den Prozess über Putty kille. Dann fliegt der EIBD wieder raus und das Booten geht weiter. Ist bestimmt nur ne Winzigkeit. Dann könnte ich mal vergleichen.

Dann wird die -d Option an den EIBD wahrscheinlich nicht übergeben.
Ansich sollte es kein Problem sein - bei der Verwendung von start-stop-daemon (wie im oben angeführten Skript) müßte man einfach nur --chuid und --group angeben.

**makki** · 29.04.2011, 22:40

Zitat von Sipple Beitrag anzeigen

Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet?

Leider nein, ich bevorzuge ein "chmod a+rw /tmp/eib" nach dem starten im Init-script..
Ich bin security-freak aber sehe auch ehrlichgesagt wenig Sinn darin. KNX ist nunmal "by design" völlig Sicherheitsfrei (ob das nun so gut ist, stünde auf einem anderen Blatt..)

Hier ist IMHO nun nicht der Punkt, damit (security) anzufangen, um etwas sicherer zu machen als es jemals sein kann.
Indem man z.B. lokale unix-user aussperrt wo im Regelfall jeder im LAN sowieso Vollzugriff hat leuchtet mir wenig ein, das user/chmod-gefummel nervt IMHO nur

Makki

**Jockel** · 29.04.2011, 23:30

Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet?

Ich hätte eins für Suse, aber eigentlich sollte es doch reichen im Skript bei start-stop-daemon den User mit dem Parameter -c anzugeben. Die user muß natürlich existieren und passende Rechte haben.

Den Sinn darin sehe ich auch nicht so sehr im Einschränken des Zugriffs auf den Eibd sondern mehr im Schutz des Rechners bei einer potentiellen Sicherheitslücke im eibd. Ob das zu Hause im privaten Netzwerk nötig ist, sei mal dahin gestellt.

Grundsätzlich gebe ich Makki aber recht, mich nervt es auch wenn SW meint mich in der Beziehung bevormunden zu müssen.

**makki** · 30.04.2011, 00:08

Ich fühle mich gerade danach das als paranoider näher zu begründen aber wie soll ich es sagen

(bei vielem anderen würde ich genau zum gegenteil votieren!)
Ich versuchs mal:

1) hat der eibd keine solch gravierenden Lücken, weil er sehr sauber gemacht ist
2) selbst wenn, ist es sehr unwahrscheinlich das man damit mehr als einen absturz desselben herbeiführen kann
3) diesen eibd (bzw. EIB/KNX im allgemeinen) so ins Internet oder andere öffentliche Netze "durchzuschalten" verbietet sich von alleine. Wer das macht ist - mit Verlaub - irre.. Hier ist ein VPN zwingend angesagt, das erzwingt aber nicht der eibd sondern schlicht EIB/KNX
4) wenn also jemand "böses" an den Rechner mit dem eibd überhaupt irgendwie per IP rankommt, hat man eh schon ein fettes Problem!
4a) und der soll dann mittels eines noch unbekannten exploits die root-Rechte des eibd ausnutzen ?

5) was kann der Angreifer mit dem root-exploit dann anfangen? die Familienfotos vom heimischen NAS lesen (wenn der eibd darauf läuft) - wiegesagt: sowas wie der KNX muss wegen dem fehlen jeglicher Sicherheitsgedanken eh komplett gekapselt/abgeschottet werden (Vlan, Firewall, VPN, whatever)

Natürlich ist aus hehren Security-Gedanken heraus besser, jeglichen Angriffspunkt zu vermeiden bevor er entsteht und es gleich richtig zu machen. Also, läuft nicht als root usw. In Anbetracht der Kernkompetenz des eibd stellen sich aber die Fragen 1-5

Also wenn jemand nur IP-mässig Zugriff auf den Rechner hat, auf dem der eibd läuft hat man ja eh schon verloren (falls der eib ohne -i -T.. läuft ist es auch egal)

An diesem Punkt bin ich jedenfalls der Meinung das man Anwender nicht mit security ärgern muss, wo eh keine ist. Viel wichtiger ist den Umstand zu beschreiben, warum das bei KNXnet/IP eben komplett flachfällt ("Ach es kennt doch keiner meine Dyndns-IP"

)

Makki

**mkoegler** · 30.04.2011, 09:56

Zitat von makki Beitrag anzeigen

Leider nein, ich bevorzuge ein "chmod a+rw /tmp/eib" nach dem starten im Init-script..

EIBD beachtet die umask für alle im Dateisystem angelegten Objekte. Mit zB "umask 000" im Startskript kann man den Default (in den meisten Linux Distributionen, das nur der User schreiben darf) ändern.

**mkoegler** · 30.04.2011, 12:35

Zitat von makki Beitrag anzeigen

1) hat der eibd keine solch gravierenden Lücken, weil er sehr sauber gemacht ist
2) selbst wenn, ist es sehr unwahrscheinlich das man damit mehr als einen absturz desselben herbeiführen kann

Ich würde mich nicht trauen, solche Aussagen zu machen

Von mir gibt es jedenfalls keine solche Garantie und ich zweifle, das jemand mit entsprechenden Wissen einen richtigen Code-Audit vom eibd gemacht hat.

Ich bin ein Verfechter von guten Sicherheitskonzepten, deshalb gilt:
EIBD sollte nicht als root laufen. Eine Verwendungs als root macht für mich nur Sinn für kurze Zeit zum Fehlersuchen, deshalb gibt es die Warnung in der 0.0.5er Version.

**makki** · 02.05.2011, 02:06

Zitat von mkoegler Beitrag anzeigen

Ich würde mich nicht trauen, solche Aussagen zu machen

Ach doch, ich schon

Ich hab jetzt ein paar Tage IT-Erfahrung und der ganze EIB/KNX hat echt ganz andere Security-Probleme - die völlig ausserhalb der Sphäre des eibd liegen - als das man sich da im Detail jetzt einen Kopf um User-rechte machen müsste..
Irgendein schlauer Kopf hat mal gesagt "Man muss keine Eier legen können, um fähig zu sein faule zu erkennen" (o.ä.) Ich kann keine solchen Eier legen, aber der eibd ist kein faules, das kann ich erkennen

Ich bin ein Verfechter von guten Sicherheitskonzepten, deshalb gilt:

Grundsätzlich d'accord, man kann es auch gleich richtig machen anstatt auf das Problem zu warten.

In diesem Fall ist es nur so, das ich mal behaupte, das mind. 50% der eibd-Einsteiger Linux Neulinge sind und security eh keine Rolle (s.o.) spielt, es ärgert nur. Es gibt ja (von dem grottigen Falcon mal abgesehen) eh nichts anderes an Alternative.
Denen würde es glaube ich helfen, wenn es nach einem rudimentären Linux-Grundkurs, wget+ dpkg es nun einfach mal funktioniert, wenigstens auf einem Debian&Co. Also ein Init-Script sollte her.. (schreib ich gerne!)

Aber da würde ich halt chmod a+rw.. reinschreiben, Debians hehre security usw hin oder her, umask, ganz ehrlich, lese ich nach 15J Linux hier zum ersten mal bewusst!
Also wie soll das ein durchschnittlich begabter Quereinsteieger blicken, der gerade mal so ein Debian in der VM ans laufen bekommt?
Dem erklärt man dann, das der eibd erst in Gruppe X muss damit dann der Webserver Y und User Z - dieser hinzugefügt - damit er auch was damit anfangen kann?
Ehrlich: Keine Chance! Das muss wenn dann das .deb alleine machen, den user, die Gruppe anlegen und die Gruppe admin sowie www-data hinzufügen. Das interessiert keinen Anwender warum und wieso der daemon a in Gruppe b sein sollte

(ich spiel jetzt mal den Anwender-Anwalt..)
Und das ist übrigens IMHO auch der Grund warum es ein Ubuntu binnen kürzerster Zeit zur erfolgreichsten Desktop-distro gebracht hat: weil es Anwender eben nicht mit so einem Käse wie unnötiger security nervt aber totzdem sicher bleibt

Ergo: Die Warnung "eibd should not..root" -> Ok. Aber dann muss das .deb dafür sorgen das es nicht so ist und trotzdem funktioniert

Makki

P.S.: Sorry, ja ich bin meist sehr direkt, bitte nicht persönlich nehmen..

**Micha** · 02.05.2011, 07:30

Ergo: Die Warnung "eibd should not..root" -> Ok. Aber dann muss das .deb dafür sorgen das es nicht so ist und trotzdem funktioniert

Möchte ich so mal deutlich unterstützen. Wir verkaufen das WG mit dem eibd und TPUART auch an gewerbliche Kunden weiter und da lebt es sich einfach ruhiger, wenn man weiß, anerkannte security Regeln werden eingehalten, auch wenn es im Einzelfall übertrieben erscheint. Trotz meiner eher bescheidenen LINUX-Kenntnisse möchte ich dem Kunden ein zuverlässsiges und sicheres Gerät verkaufen können.

Wie ist ist das nun beim originären WG mit dem root-user und dem eibd ?

Gruß Micha

Ankündigung

- √ - Autostart von EIBD mit Debian Squeeze

- √ - Autostart von EIBD mit Debian Squeeze

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar