Community-Firmware für den TXT

[LarsKusch]

Wäre es möglich dass ich den Betrag euch/dir gebe und ihr/du ihn dann auf GitHub stellst, da ich keinen GitHub Account habe und keinen anlegen möchte(vielleicht könnte man nochmal das Englisch korrigieren falls es Verständnis Probleme geben sollte? Es kommt wahrscheinlich eh erst ein zwei bis drei Wochen. )
Erstellende Grüße,
Lars

[LarsKusch]

Der Beitrag ist fertig https://1drv.ms/f/s!Ah2MpyuJo7fJySGoORcILCfDdxWG nehmt euch bitte da einfach eine der Datein die ihr braucht und packt es zu Github? (das Bild ist leider nur in der Word und OpenOffice
Datei enthalten)

[hvn]

Hi,

I just tried the community firmware and it looks nice. Just 2 remarks:
1: the WLAN states a list of networks to choose from. After choosing my own, selecting WPA2 and giving my password, it states "connected". However, a DHCP IP address apparently isn't requested or accepted and seemingly a static IP address can't be entered either. I checked on my modem/router and it shows the MAC-address without IP-address. Am I doing something wrong?
2: when choosing the TXT menu, I can't find a way to get back to the community menu.

Thanks,

hvn

[richard.kunze]

Hello hvn,

I just tried the community firmware and it looks nice.

Nice to hear this.

1: the WLAN states a list of networks to choose from. After choosing my own, selecting WPA2 and giving my password, it states "connected". However, a DHCP IP address apparently isn't requested or accepted and seemingly a static IP address can't be entered either. I checked on my modem/router and it shows the MAC-address without IP-address. Am I doing something wrong?

No, you're not doing anything wrong. The firmware should request an IP address via dhcp when connected to a WLAN router.

One possible reason for the failure could be that the connection is just good enough to contact the router, but the dhcp handshake fails due to packet loss.

You can check this by moving the TXT closer to the router and trying to reconnect. If you have SSH access to the TXT (via USB cable), you can trigger the reconnect by issuing the command "sudo ifdown wlan0" followed by "sudo ifup wlan0". The output of the latter command should be something along these lines:

Code: Alles auswählen

Successfully initialized wpa_supplicant
Could not read interface p2p-dev-wlan0 flags: No such device
udhcpc (v1.24.1) started
Sending discover...
Sending discover...
Sending discover...
Sending select for 192.168.0.30...
Lease of 192.168.0.30 obtained, lease time 43200
deleting routers
adding dns 192.168.0.2

2: when choosing the TXT menu, I can't find a way to get back to the community menu.

A short press of the blue on/off button gets you back to the community menu (this works for all apps, not just for the original TXT gui). Just make sure that you don't press the button too long, because holding it down for more than three or four seconds will shut down the TXT.

[hvn]

Thank you for you response
Some questions:
- I didn't have to use the USB, since it does have an WLAN address via dhcp now, what's the (standard) username for use with ssh? The official username is ROBOPro, but is there any set in this kernel?
- what's the device id? According to the FT-gui it is TXT-1680, but that doesn't show up in the WiFi list on my computer.

hvn

[richard.kunze]

I didn't have to use the USB, since it does have an WLAN address via dhcp now, what's the (standard) username for use with ssh? The official username is ROBOPro, but is there any set in this kernel?

The standard username for SSH is "ftc", and by default, there is no password set. After setting a password (login via ssh and use the "passwd" command to do this), the ftc user can use "sudo" to get root access as well.

I strongly recommend to set a password for the "ftc" user, by the way, because with the community firmware your TXT is accessible from your LAN at the least and may be (depending on your network settings) accessible from the whole internet.

what's the device id? According to the FT-gui it is TXT-1680, but that doesn't show up in the WiFi list on my computer.

This is because the community firmware configures the TXT to act as a WLAN client (like your PC) and not as a WLAN access point as the original firmware does. A WLAN client does not have a "device id" (the technical term here is "service set identfifier" or "SSID" for short) that shows up on a WiFI list, instead it connects to an existing access point (usually a router).

The closest thing to a "device id'" with the community firmware is the hostname of your TXT within your local network. But setting the hostname is up to your router, so I can't really say what hostname your TXT will end up with.

[ski7777]

The standard username for SSH is "ftc", and by default, there is no password set. After setting a password (login via ssh and use the "passwd" command to do this), the ftc user can use "sudo" to get root access as well.

Das aktuelle Passwort-System hat jedoch eine gravierende Sicherheitslücke. Jede APP kann sich auf einer Community Firmware, welche noch kein Passwort für den Nutzer ftc hat, ein Passwort setzen und damit gutes oder auch böses tun.

Oder ich werde das ganze bald für eine Firmware-Upgrade App mit Webbrowser Unterstützung nutzen.

Raphael

EDIT 05.09.16 16:53 GMT+2 : Ausdrucksweise geändert

[MasterOfGizmo]

Da habe ich schon fast ein Exploit auf Lager. Jede APP kann sich auf einer frischen Cimmunity Firmware ein Passwort setzen und dann anfangen den TXT zu zerstören, in einem Bot-Netz mitwirken lassen, dein Heimnetzwerk angreifen, ...

Seufz ... ich habe Dir also die Schreibrechte auf das Apps-Repository wieder entzogen, damit Du genau das nicht tust. Aber danke, dass Du das vorher angekündgt hast, dass Du solche Dinge planst.

[MasterOfGizmo]

In der aktuelle c't gibt es einen Artikel über das, was mal als GUI für den TXT begonnen hat. Die Hoffnung ist, dass auch der TXT davon profitiert, wenn das durch Raspberry PI und Co Verbreitung findet. (http://www.heise.de/ct/ausgabe/2016-19- ... 05840.html)

Die TouchUI pflege ich seperat hier:
https://github.com/harbaum/TouchUI

Ich habe außerdem vorhin mal den aktuellen Stand der TouchUI-Oberfläche in das TXT-Repository integriert. Es sollte damit alles nach wie vor funktionieren. Der Launcher hat nun eine Status-Zeile oben, wo Uhrzeit und WLAN-Status angezeigt werden. Das passiert über sehr kleine Plugins, die man auch selbst nachrüsten kann, um z.B. anzuzeigen, dass ein bestimmtes Gerät am USB angeschlossen ist o.ä.

Und der ganze Launcher-Code wurde etwas aufgeräumt. Der QT-Style heisst nun TouchStyle (statt wie bisher TxtStyle), aber es gibt den TxtStyle nach wie vor, so dass Apps, die das alte Txt...-Namensschema nutzen weiter wie gehabt laufen.

[ski7777]

Seufz ... ich habe Dir also die Schreibrechte auf das Apps-Repository wieder entzogen, damit Du genau das nicht tust. Aber danke, dass Du das vorher angekündgt hast, dass Du solche Dinge planst.

Wenn ich jemanden hacken wollte, würde ich keinen Virus für ein System schreiben, bei dem ich die Nutzer an einer Hand abzählen kann. Mein Beitrag war eher als Denkanstoß zur Verbesserung der Passwortsicherheit auf dem TXT gedacht. Ich fände es besser, wenn ich wieder weiter ungestört entwickeln, releasen und updaten könnte.

Meine Idee wäre es, System-Apps mit anderen Rechten laufen zu lassen, wie Coustom-Apps. So könnten wir beim ersten hochfahren der ftc-FW zufällige Passwörter für alle Nutzer generieren lassen, welche nur von dem Nutzer für System-Apps ausgelesen werden können.
Die neuen Benutzer wären dann:

• root: Nutzer mit Systemrechten, wird von der ftc-FW nicht benutzt (nur für Entwickler)
• ftc: Nutzer mit Standartrechten, um den Launcher auszuführen (vergleichbar mit dem aktuellen ftc-Benutzer) berechtigt, um App mit ftc- und userapp-Rechten zu starten
• userapp:App für userapps, ist nicht berechtigt, um Passwörter auszulesen

Perfekt wäre es natürlich mit einem Benutzer pro App:

• userapp-uuid-einer-user-app: Nutzer ohne Schreibrechte auf Appordner einer anderen App, kann für andere Nutzer Schreibrechte auf eigenen Ordner erlauben,ist nicht berechtigt, um Passwörter auszulesen

So könnte eine Update-APP auch ohne zu Hilfe nahme eibner Tastatur am TXT / auf dem TXT-Bildschirm bzw. einem Webbrowser Updaten, ohne dass die APP das Passwort ändern muss.
Wie auch immer, eine Sicherheitslücke gibst!

Ich habe außerdem vorhin mal den aktuellen Stand der TouchUI-Oberfläche in das TXT-Repository integriert. Es sollte damit alles nach wie vor funktionieren. Der Launcher hat nun eine Status-Zeile oben, wo Uhrzeit und WLAN-Status angezeigt werden. Das passiert über sehr kleine Plugins, die man auch selbst nachrüsten kann, um z.B. anzuzeigen, dass ein bestimmtes Gerät am USB angeschlossen ist o.ä.

Cool!

Ich hatte die TouchUI schon etwas in deinem Repository beobachtet. Die Idee mit den Plugins für die Status-Bar ist natürlich genial. Doch was passiert, wenn ich etwas zu viele Plugins in die StatusLeiste setze? Könnte man die Leiste auch anzeigen und aktualisieren, während Apps laufen?

Diese Entwicklung ist eine Release Wert.

Raphael

P.S.: Ich würde gerne mal einen USB-Stick zum booten benutzen, jedoch funktionier das aufgrund dieser Zeile leider nicht. Könnte man da eine Erkennung einbauen, ob ein USB-Stick drin steckt? Das eigentliche botten funktioniert genauso wie bei einer SD-Karte, jedoch mit vorher einem

Code: Alles auswählen

usb start

und dem sdboot-Kommando etwas abgewandelt. Das Kommando

Code: Alles auswählen

usbboot

mit irgendwelchen Parametern hat mich nie bis zur Fehlermeldung beim mounten gebracht.

[MasterOfGizmo]

Wenn ich jemanden hacken wollte, würde ich keinen Virus für ein System schreiben

Dann verstehe ich nicht, warum Du so etwas behauptest. Selbst wenn Du es dann nicht tun willst hast Du a) das Gerücht, dass sowas passiert in die Welt gesetzt, was uns sicher keine zusätzlichen User bringt und b) jemanden anderen ggf. auf dumme Gedanken gebracht.

Wenn einer ankündigt, dass er Schaden anrichten will, dann habe ich nicht die Geduld, abzuwarten, ob er es ernst meint.

Eine Lösung wäre, beim ersten Start der Firmware den User via GUI zur Eingabe eines Passworts zu zwingen und generell keiner App besondere Rechte zu geben. Alles was Du vorschlägst, um einzelnen Apps weitreichende Rechte einräumen zu können, kann missbraucht werden. Und Dein Kommentar ist der beste Beweis dafür, dass es immer jemanden gibt, der genau das tun wird.

[ski7777]

a) das Gerücht, dass sowas passiert in die Welt gesetzt, was uns sicher keine zusätzlichen User bringt und b) jemanden anderen ggf. auf dumme Gedanken gebracht.

Gut. Dann werde ich meinen Beitrag etwas editieren, so dass es wie eine issue-Meldung geschrieben ist. Die Leute mit "dummen Gedanken" werden auch ohne meine Beihilfe Wege finden, diese umzusetzen.

Eine Lösung wäre, beim ersten Start der Firmware den User via GUI zur Eingabe eines Passworts zu zwingen und generell keiner App besondere Rechte zu geben.

Oder so. Das Passwort könnte man auch per Webinterface editieren. Da wäre https zwar wohl besser, aber wir gehen mal von einem Netzwerk ohne mitlauschende Wanzen aus.

Alles was Du vorschlägst, um einzelnen Apps weitreichende Rechte einräumen zu können, kann missbraucht werden. Und Dein Kommentar ist der beste Beweis dafür, dass es immer jemanden gibt, der genau das tun wird.

Mehr Rechte nur für Apps, welche in /opt/ftc/apps/system/ liegen. Da kann fast nichts mehr passieren.

Raphael

[ski7777]

Wie auch immer, eine OTA-Update Funktion wäre cool, und sollte auch ohne eingabe eines langen Passworts auf dem TXT Bildschirm möglich sein. Dafür gibt es in meinen Augen zwei Möglichkeiten:

• Wir legen einen Update-User an, welcher beim ersten booten ein Zufalls-Passwort erhält, welches man nur über eine System-App auslesen kann. Diese kann dann ungestört ein Update durchführen kann. So haben wir verschlüsselt oder unverschlüsselt ein Passwort auf der SD-Karte liegen, welches man allerhöchstens als Nutzer root-auslesen kann. User-Apps können das Passwort natürlich aufgrund des posix-Overlay nicht auslesen.
• Wir erstellen keinen zusätzlichen Benutzer und benutzen den Benutzer ftc für das Update. Die Eingabe des Passworts erfolgt dann entweder am TXT selbst oder an einem Webbrowser (unsicher, weil (noch) kein https). So könnte man auch vorher ein Passwort setzen bzw. ändern.

Ich persönlich würde Möglichkeit eins vorziehen, weil dort die einzige Sicherheitslücke ein ungesetztes des Benutzers ftc wäre (möchten wir ja beheben). Zusätzlich könnte man dem Benutzer nur Rechte für bestimmte Dateien und Ordner auf der SD-Karte geben. Möglichkeit zwei scheidet in meinen Augen wegen dem http/https Problem aus, auch könnte so eine andere App auf dem TXT als Wanze agieren und böse werden...

Diese Entwicklung ist eine Release Wert.

Was hältst du davon?


Raphael

[steffalk]

Tach auch!

...weil dort die einzige Sicherheitslücke ein ungesetztes des Benutzers ftc wäre...

Wie kann man bitte sicher sein, dass eine Sicherheitslücke, die einem gerade einfällt, die einzige ist, die existiert? Gibt's da 'nen coolen Beweis, den die Welt noch nicht kennt? Ich mein' ja nur

Gruß,
Stefan

[ski7777]

Tach auch!

...weil dort die einzige Sicherheitslücke ein ungesetztes des Benutzers ftc wäre...

Wie kann man bitte sicher sein, dass eine Sicherheitslücke, die einem gerade einfällt, die einzige ist, die existiert? Gibt's da 'nen coolen Beweis, den die Welt noch nicht kennt? Ich mein' ja nur

Gruß,
Stefan

Ok,

die einzige bekannte Sicherheitslücke.

Raphael

[richard.kunze]

In der aktuelle c't gibt es einen Artikel über das, was mal als GUI für den TXT begonnen hat. Die Hoffnung ist, dass auch der TXT davon profitiert, wenn das durch Raspberry PI und Co Verbreitung findet.

Hab ich gerade gelesen - schöner Artikel!

Ich habe außerdem vorhin mal den aktuellen Stand der TouchUI-Oberfläche in das TXT-Repository integriert. Es sollte damit alles nach wie vor funktionieren. Der Launcher hat nun eine Status-Zeile oben, wo Uhrzeit und WLAN-Status angezeigt werden. Das passiert über sehr kleine Plugins, die man auch selbst nachrüsten kann, um z.B. anzuzeigen, dass ein bestimmtes Gerät am USB angeschlossen ist o.ä.

Hmm - klingt zusammen mit dem letzten Commit bei ftrobopy ('added new input objects "resistor", "voltage", "resistor2", "trailfollower"') danach als sollte man da mal eine neue Version veröffentlichen. Mal sehen ob ich das bis zur Convention noch hinbekomme.

Das aktuelle Passwort-System hat jedoch eine gravierende Sicherheitslücke. Jede APP kann sich auf einer Community Firmware, welche noch kein Passwort für den Nutzer ftc hat, ein Passwort setzen und damit gutes oder auch böses tun.

Ja. Das war auch von Anfang an klar, das hatten wir damals als Kompromiss zwischen Sicherheit und Bequemlichkeit hingenommen. Gefallen hat mir das nie wirklich, aber bisher hatte ich da auch keine gangbare Alternative.

Inzwischen ist mir aber doch noch was eingefallen: Wir können als Alternative zur Passworteingabe bei sudo (oder anderen "gefährlichen" Aktionen) im Prinzip auch einfach einen passenden Dialog auf dem Touchscreen anzeigen, der dann den Benutzer fragt ob er die Aktion zulassen will oder nicht. Bestätigt (oder abgelehnt) wird dann ebenfalls mit einem Druck auf den Touchscreen.

Damit haben wir sichergestellt, dass jemand mit physikalischem Zugang zum TXT die Aktion abgenickt hat - man kann also rein übers Netz (oder im Hintergrund aus einer nachinstallierten App) schon mal keinen Blödsinn anstellen. Und wer einen TXT in die Finger kriegt kann mit dem Ding sowieso machen was er will - das können (und wollen) wir gar nicht verhindern.

Die Umsetzung sollte sich eigentlich als PAM-Modul machen lassen, d.h. wir brauchen da auch nicht an sudo selbst rumpfuschen. Und eventuell wäre sowas ja auch für anderes Kleinzeug mit Touchscreen ganz nützlich.

Was haltet Ihr von der Idee?

[TiniTech]

"Zwei-Faktor-Authentifizierung à-la-embedded Device" - ich finde, das klingt wirklich gut. Ich habe jetzt nicht wirklich verstanden wie die Umsetzung funktionieren würde, aber das muss ich ja auch nicht. Wede bei Gelegenheit mal PAM-Modul googlen...
Aus meiner Sicht wäre nur wichtig, dass dann, wenn ein Passwort gesetzt ist und man über SSH zugreift, sudo auch ohne Touch-Zugang genutz werden kann, falls der Controller in einem Roboter nicht oder nicht so gut zugänglich ist.

[richard.kunze]

"Zwei-Faktor-Authentifizierung à-la-embedded Device" - ich finde, das klingt wirklich gut.

Nee, ist nur ein Faktor. Für zwei Faktoren bräuchte man Knopfdruck und Passwort - das wäre aber für die Anwendung eher übertrieben.

Aus meiner Sicht wäre nur wichtig, dass dann, wenn ein Passwort gesetzt ist und man über SSH zugreift, sudo auch ohne Touch-Zugang genutz werden kann, falls der Controller in einem Roboter nicht oder nicht so gut zugänglich ist.

Sollte prinzipiell eigentlich gehen. Schlimmstenfalls per Config-Einstellung, mit der man zwischen Passworteingabe und/oder Bestätigung per Touchscreen umschaltet.

[ski7777]

• Wir haben: Apps, Plugins für die Statusleiste und ein default-theme.
• Wir können Apps hinzufügen und löschen.
• Genauso könnte man auch user-Plugins hinzufügen und löschen und auch andere Themes hinzufügen und löschen.
  Ob der Launcher "on-the-air" Themes Wechseln kann weiß ich nicht, plugins auf jeden Fall mal nicht.
  Ich würde in den Ordnern plugins und themes Unterordner "system" und "user" anlegen, die existierenden Sachen dort einfügen und mit manifest Dateien versehen und die user-Ordner auf die SD-Karte verknüpfen. Zusätzlich werde ich im web-root auch zwei Verknüpfungen anlegen, um einen einfacheren Upload zu ermöglichen. Der aktuelle Upload-Button soll dann app-Zips, theme-Zips und plugin-Zips auspacken, unterscheiden, in den richtigen Ordner und dann dem Launcher vielleicht bescheid sagen. Das wechseln des themes würde ich in eine 'Settings' App verfrachten und den Store in drei Kategorien umbauen.

Raphael

[MasterOfGizmo]

Hmm - klingt zusammen mit dem letzten Commit bei ftrobopy ('added new input objects "resistor", "voltage", "resistor2", "trailfollower"') danach als sollte man da mal eine neue Version veröffentlichen. Mal sehen ob ich das bis zur Convention noch hinbekomme.

Das aktualisierte GUI ist nicht sehr intesiv getestet. Ich muss zugeben, dass ich auf dem TXT hauptsächlich meinen eigenen Kram laufen lasse und Sachen wie das Web-Interface etc kaum nutze. Vor einem Release sollte sich mal jemand mit viel Freizeit durch alle Funktionen der Firmware hangeln und schauen, ob's noch alles tut ...

Aber generell ist ein Release prima. Vor allem mein letzter Patch, der CDC-ACM anktiviert ist nett, weil der TXT damit den 3D-Drucker steuern kann