vdr nur als root?

  • Ich versuche gerade einen vdr auf einer Strato VM ans Laufen zu bringen (Ubuntu 12.04 LTS).

    Da e-tobi down ist musste ich mal mit der Vanilla Vorlieb nehmen:


    Code
    ii vdr 2.0.3-1 amd64 Video Disk Recorder for DVB cards
    
    ii vdr-plugin-streamdev-client 0.6.0+git20130305-5 amd64 VDR Plugin to stream Live-TV to other VDR's - client part
    
    ii vdr-plugin-streamdev-server 0.6.0+git20130305-5 amd64 VDR Plugin to stream Live-TV to other VDR's - server part



    Das bringt dann beim Start folgenden Fehler


    Code
    stopping after fatal fail (vdr: cap_set_proc failed: Operation not permitted)


    Das sieht mir aus wie folgendes Problem:


    https://www.mail-archive.com/d…debian.org/msg320506.html


    Dort wurde dieser Bug ausgiebig diskutiert, allerdings vor vier Jahren.


    Natürlich startet der vdr wenn er als root läuft, aber ist das wirklich empfehlenswert?

    Bis jetzt war mir das immer völlig egal bei internen Maschinen, wenn das jedoch im Netz läuft scheint mir das nicht gut zu sein.


    Wie schätzt ihr das Risiko ein wenn der vdr als root auf einer öffentlichen Maschine ausgeführt wird?


    Nächstes Problem streamdev-client:


    streamdev-client.RemoteIp = 93.xxx.xxx.xxx


    Der Parameter heisst zugegebener Weise RemoteIp, und er arbeitet NICHT wenn man einen hostnamen einträgt.Bug oder Feature? Auf jeden Fall in dem Kontext sehr lästig.


    Klaus

  • Normalerweise startet der VDR bei dem in den Debian-Paketen mitgelieferten Init-Skript als root und droppt dann die nicht benötigten Privilegien. Der von dir verlinkte Bugreport geht von dem speziellen Fall aus, dass der Root-Nutzer diese Privilegien nie hatte. Eigentlich sollte es genügen den VDR als normaler User statt als root zu starten, um den Fehler loszuwerden.


    Der VDR ist IMHO nicht dafür geeignet außerhalb eines vertrauenswürdigen Netzwerks zu laufen. SVDRP und VTP sind unverschlüsselt und besitzen keine sichere Möglichkeit für eine Authentifizierung. Wenn würde ich eine VPN-Verbindung zum Server aufbauen und den Rest tunneln, dann ist es auch kein Problem in der Client-Konfiguration eine IPv4-Adresse für den Server anzugeben.

    Ich versuche gerade einen vdr auf einer Strato VM ans Laufen zu bringen (Ubuntu 12.04 LTS).

    Wie schätzt ihr das Risiko ein wenn der vdr als root auf einer öffentlichen Maschine ausgeführt wird?

    Das viel größere Risiko ist, dass Ubuntu 12.04 seit Monaten nicht mehr gepflegt wird (falls du nicht gerade ein zahlender Ubuntu Advantage customer bist): https://lists.ubuntu.com/archi…ce/2017-March/000217.html - damit hast du potentiell noch ganz andere Probleme durch in der Zwischenzeit bekannt gewordenen Sicherheitslücken bei den ganzen anderen aus dem Netzwerk erreichbaren Diensten auf dem Server...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich habe mir den Code in VDR gerade mal näher angeschaut. Der Name 'DropCaps()' ist wohl etwas irreführend, denn eigentlich macht er an dieser Stelle keinen "drop", sondern *setzt* die Caps, so daß nur noch genau die erwünschten drei vorhanden sind. Man müsste hier wohl erst prüfen, welche der Caps überhaupt vorhanden sind. Aber das sollte vielleicht jemand implementieren, der sich mit diesen Funktionen auskennt... ;-).


    Klaus

  • OHHHHHH NO!


    Weil ich den Server zur freien Verfügung hatte habe ich heute im Laufe des Tages ein aktuelleres Ubuntu installiert:


    Ubuntu 16.04 LTS 64bit


    Natürlich gab es auch ein neueres VDR Paket.


    Und zwar:


    Code
    dpkg -l |grep vdr
    ii  vdr 2.2.0-5build1 amd64 Video Disk Recorder for DVB cards
    ii  vdr-plugin-streamdev-client 0.6.1+git20150213-3 amd64 VDR Plugin to stream Live-TV to other VDR's - client part
    ii  vdr-plugin-streamdev-server 0.6.1+git20150213-3 amd64 VDR Plugin to stream Live-TV to other VDR's - server part

    Auch hat sich die ganze Startlogik geändert und der eigentliche daemon ist jetzt in /usr/lib/vdr/runvdr und nicht mehr der vdr selber (wie noch im Ubuntu vorher).


    Ist jetzt so ein bischen wie bei der ct / e-tobi.


    Natürlich - das liess ja schon der Beitrag von kls befürchten - startet auch diese Version nicht:


    vdr[5394]: vdr: cap_set_proc failed: Operation not permitted


    Nur: Jetzt zieht der Eintrag in /etc/defaults/vdr


    USER=root


    auch nicht mehr. Ich habe keinen Weg gefunden den vdr so ans Laufen zu bringen.


    Ich könnt in die Tischkante beissen, das ganze war ja nur ein proof of concept und eigentlich waren die Ergebnisse von gestern zufriedenstellend.


    Kann doch nicht sein das so ein Paket wie der vdr auf einer so grossen Distro nicht ans Laufen zu bringen ist. Fühl mich wie auf einer Zeitreise vor gefühlt 20 Jahren ........


    :wand


    Klaus

  • Zitat

    Das Geheimnis liegt jetzt in /etc/vdr/conf.d/00-vdr.conf

    Dort kann man den root mode erzwingen.

    Darauf muss man erst mal kommen dass es nun auch eine falsche Stelle für den Parameter gibt...


    Danke!

  • Ich habe mir den Code in VDR gerade mal näher angeschaut. Der Name 'DropCaps()' ist wohl etwas irreführend, denn eigentlich macht er an dieser Stelle keinen "drop", sondern *setzt* die Caps, so daß nur noch genau die erwünschten drei vorhanden sind. Man müsste hier wohl erst prüfen, welche der Caps überhaupt vorhanden sind. Aber das sollte vielleicht jemand implementieren, der sich mit diesen Funktionen auskennt... ;-).


    Klaus

    Der Beitrag ist zwar schon alt, das Problem besteht aber immer noch, wenn man den VDR in einem Container als User vdr laufen lassen möchte. Im Container gibt es keine Berechtigung, die Funktion cap_sys_time zu nutzen, weil die auf das Host System wirken würde (getestet mit Ubuntu 18.04 und lxc).

    Ich habe mal ein Patch gebaut, der überprüft, ob cap_sys_time verfügbar ist und falls nicht, darauf verzichtet. In dem Fall geht natürlich die Funktion "Systemzeit aus DVB setzen" nicht mehr, das macht aber in einem Container eh keinen Sinn.


    Der diff ist gegen dem aktuellen Code aus yavdr repository experimental.


    Wäre super, wenn mal jemand testen könnte, ob der Patch auch unter anderen Umgebungen läuft und vor allem keine Probleme auf "normalen" Systemen verursacht.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!