Linux/Ubuntu und Secure Boot?

C

cyberjonny

Active member
Themenstarter
Registriert
22 Sep. 2007
Beiträge
9.720
Hi miteinander,

Linux/Ubuntu mit aktiviertem Secure Boot installieren oder nicht - das ist hier die Frage!
Was spricht dafür, was dagegen?
Wo liegt der Unterschied, ob Secure Boot im UEFI/BIOS deaktiviert wird oder während der Ubuntu-Installation (beim Punkt "Drittanbieter-Software")?
Eigentich möchte ich "Drittanbieter-Software" (Treiber, Codecs etc.) schon installieren - das System soll ja rund laufen und für die üblichen Alltagsaufgaben gerüstet sein -, allerdings impliziert die hierfür notwendige Deaktivierung von Secure Boot ein mögliches Sicherheitsrisiko? Und wird Secure Boot nach der Installation der "Drittanbieter-Software" wieder aktiviert oder muss es dann deaktiviert bleiben?

Fragen über Fragen! :confused:

Kurz: Welche Einstellung macht bzgl. Secure Boot im Hinblick auf den Ubuntu-Alltagsgebrauch Sinn - und warum?

Danke euch! :)
Gruß, Jonny
 
Bei einem normalem start ohne SecureBoot startet das UEFI/BIOS einfach was es auf der Platte findet.
Wenn SecureBoot aktiviert ist, dann prüft das UEFI ob das was auf der Platte ist eine Signatur hat.
Ohne passende Signatur wird der Start verweiget.

Natürlich wird nicht die komplette Platte gecheckt sonder nur das nächste Glied in der Bootkette.

Im Auslieferungszustand sind meistens nur die Microsoft Signaturen im UEFI hinterlegt.
Nicht bei allen UEFIs kann man eigene Signaturen hinterlegen.

Deshalb haben die Macher von ubuntu einen kleinen mini bootloader gemacht und diesen von Microsoft Signieren lassen.
Mittlerweile gibt es bestimmt auch andere Signierte bootloader.

Somit solle es theoretisch möglich sein ein ubuntu mit aktiviertem SecureBoot zu installieren.

Da ich mich mit dem Thema noch nicht tiefergehend beschäftigt hab kann ich nicht sagen ob das in der Praxis problemlos klappt und/oder ob es Einschränkungen für den Alltagsbetrieb gibt.
 
Ein aktuelles Ubuntu lässt sich problemlos mit aktiviertem Secure Boot installieren, das habe ich schon ausprobiert. Und auch die Theorie hinter dem Konzept ist mir soweit bekannt (danke trotzdem, gut erklärt! :)).

Mich würde mehr interessieren, ob das auch wirklich für den Alltagsgebrauch tauglich ist bzw. wo hier ggf. Nachteile liegen.

Ganz konkret interessiert mich wie gesagt der Punkt mit der Drittanbieter-Software.
 
Mal eben schnell getestet, geht offenbar ganz gut. :thumbsup: Mal eben schnell? Aaalso: Ich hatte Mint 18 ohne SecureBoot installiert (da Win 7 daneben schon drauf). Offenbar wird dennoch die signierte Bootloaderdatei shimx64.efi standardmäßig ins UEFI installiert. Gerade mal SecureBoot im Setup aktiviert und der Mint-Start lief wie gewohnt ohne Probleme durch. Da auch ich bei der Installation die Option für proprietäre Treiber und Codecs aktiviert hatte, dürfte es doch wohl auch beim "einfachen" so Ubuntu klappen? Also mit deaktiviertem SecureBoot während der Installation und anschließendem aktivieren. Es geht ja da wohl hauptsächlich um den signierten Bootloader.

Btw: Ich hatte ein ganz anderes Problem. Hatte fast nen ganzen Tag damit verbracht, den Ubuntu-Booteintrag überhaupt zum Vorschein zu bringen. Der wollte nämlich nach mehreren Installationsversuchen und den ganzen Tipps aus dem WWW mittels BCDedit und efibootmgr, im Win, im mittels rEFInd-Stick gestarteten installierten Mint als auch über Mint-Livesystem, nicht erscheinen. (Daher weiß ich auch, dass shimx64.efi tatsächlich genutzt wird.) Dann erst ging mir auf, dass es mit meinen Sicherheitseinstellungen im BIOS zu tun haben könnte! :facepalm: Die also alle raus genommen, GRUB nochmals neu geschrieben und et jing. Weiß nicht genau, welche der diversen Einstellungen es war; da gibt's sowas wie "Bootreihenfolge sperren" oder so ähnlich, evtl. war's die.

Jetzt schlag ich mich mit nem Bildschirmskalierungsproblem rum, das nach Neustart verloren geht, obwohl die Einstellung noch gesetzt ist. Sch... hohe Auflösungen bei den kleinen Screens heutzutage! :rolleyes:
 
Per DKMS erzeugte Kernelmodule - tp-smapi und acpi-call, die man für Ladeschwellen benötigt - lassen sich mit Secure Boot nicht laden.
 
Okay, das ist allerdings schon ein Nachteil, danke!


@ linrunner: Deine persönliche Meinung - Secure Boot mit Ubuntu :thumbup: oder :thumbdown: (oder :facepalm:)? :)


Ist das Risiko im Alltagsgebrauch durch das Deaktivieren von Secure Boot wirklich signifikant höher?
 
linrunner schrieb:
Per DKMS erzeugte Kernelmodule - tp-smapi und acpi-call, die man für Ladeschwellen benötigt - lassen sich mit Secure Boot nicht laden.
Zum Vergrößern anklicken....

Oha... Kann man dabei was zerschießen oder funktioniert dann nach Abschalten von SecureBoot wieder alles normal?
 
@cyberjonny: welchen konkreten Sicherheitsgewinn versprichst Du dir denn von Secure Boot? Meine Systeme sind vollverschlüsselt und booten neuerdings wieder mit CSM. Das umständliche Gefummel mit den UEFI-Booteinträgen, wenn man z.B. eine Platte umbaut oder "nur eben mal" BIOS Defaults setzen muss, will ich mir nicht mehr antun.

@harpo: nein. ja.
 
linrunner schrieb:
@cyberjonny: welchen konkreten Sicherheitsgewinn versprichst Du dir denn von Secure Boot? Meine Systeme sind vollverschlüsselt und booten neuerdings wieder mit CSM. Das umständliche Gefummel mit den UEFI-Booteinträgen, wenn man z.B. eine Platte umbaut oder "nur eben mal" BIOS Defaults setzen muss, will ich mir nicht mehr antun.
Zum Vergrößern anklicken....
Ja, ein guter Punkt, ein wirklich konkreter Sicherheitsgewinn fällt mir eigentlich überhaupt nicht ein. Es ist eher ein "theoretischer" Sicherheitsgewinn (wenn überhaupt) im Sinne von "wenn es keine Nachteile hat, kann man es ja mal aktivieren". Natürlich könnte man ein Szenario entwerfen, bei dem Secure Boot ein tatsächlicher Sicherheitsgewinn wäre, aber wie wahrscheinlich das ist, sei mal dahin gestellt. Ich denke, ich werde es auch deaktivieren. Danke!
 
linrunner schrieb:
Per DKMS erzeugte Kernelmodule - tp-smapi und acpi-call, die man für Ladeschwellen benötigt - lassen sich mit Secure Boot nicht laden.
Zum Vergrößern anklicken....

Irgendwie habe ich es hinbekommen:

Code: 
--- TLP 1.3.1 --------------------------------------------

+++ System Info
System         = LENOVO ThinkPad T490s 20NXCTO1WW
BIOS           = N2JET88W (1.66 )
Release        = Debian GNU/Linux 10 (buster)
Kernel         = 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64
/proc/cmdline  = BOOT_IMAGE=/vmlinuz-5.5.0-0.bpo.2-amd64 root=/dev/mapper/mb--vg-root ro quiet
Init system    = systemd v245 (245.6-1~bpo10+1)
Boot mode      = UEFI

+++ TLP Status
State          = enabled
RDW state      = enabled
Last run       = 11:06:06 AM,   5258 sec(s) ago
Mode           = AC
Power source   = AC

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = active (recalibrate)
tp-smapi   = inactive (ThinkPad not supported)

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer                   = SMP
/sys/class/power_supply/BAT0/model_name                     = 02DL014
/sys/class/power_supply/BAT0/cycle_count                    =     11
/sys/class/power_supply/BAT0/energy_full_design             =  57020 [mWh]
/sys/class/power_supply/BAT0/energy_full                    =  57040 [mWh]
/sys/class/power_supply/BAT0/energy_now                     =  40830 [mWh]
/sys/class/power_supply/BAT0/power_now                      =      0 [mW]
/sys/class/power_supply/BAT0/status                         = Unknown (threshold may prevent charging)

/sys/class/power_supply/BAT0/charge_start_threshold         =     45 [%]
/sys/class/power_supply/BAT0/charge_stop_threshold          =    100 [%]
tpacpi-bat.BAT0.forceDischarge                              =      0

Charge                                                      =   71.6 [%]
Capacity                                                    =  100.0 [%]

marc@mb:~$

War: "sudo tlp-stat -s -b"

- - - Beitrag zusammengeführt - - -

linrunner schrieb:
@cyberjonny: welchen konkreten Sicherheitsgewinn versprichst Du dir denn von Secure Boot? Meine Systeme sind vollverschlüsselt und booten neuerdings wieder mit CSM. Das umständliche Gefummel mit den UEFI-Booteinträgen, wenn man z.B. eine Platte umbaut oder "nur eben mal" BIOS Defaults setzen muss, will ich mir nicht mehr antun.

@harpo: nein. ja.
Zum Vergrößern anklicken....


Das ist wohl wahr, ich habe kürzlich auf das UEFI/ Secureboot umgestellt, sehe mich aber nach wie vor auserstande einen Dualboot einzurichten -> Singleboot wg. UEFI ...

Wie spielst du Firmwareupdates ein ohne UEFI ?

- - - Beitrag zusammengeführt - - -

cyberjonny schrieb:
Ja, ein guter Punkt, ein wirklich konkreter Sicherheitsgewinn fällt mir eigentlich überhaupt nicht ein. Es ist eher ein "theoretischer" Sicherheitsgewinn (wenn überhaupt) im Sinne von "wenn es keine Nachteile hat, kann man es ja mal aktivieren". Natürlich könnte man ein Szenario entwerfen, bei dem Secure Boot ein tatsächlicher Sicherheitsgewinn wäre, aber wie wahrscheinlich das ist, sei mal dahin gestellt. Ich denke, ich werde es auch deaktivieren. Danke!
Zum Vergrößern anklicken....


Bei neuen Thinkpads hat man wenigstens Speicherschutz (DMA Kernel Protection) sofern Bios und Kernel mitspielen:

- - - Beitrag zusammengeführt - - -

Z.b hier gegen: https://thunderspy.io/

- - - Beitrag zusammengeführt - - -

PPS:

Linux-Kernel ACPI-Bug hebelt Schutzmechanismen von UEFI Secure Boot aus | heise online

https://www.heise.de/news/Linux-Ker...anismen-von-UEFI-Secure-Boot-aus-4786877.html

Ev. ist das alles useless ........................
 
mcb schrieb:
Wie spielst du Firmwareupdates ein ohne UEFI ?
Zum Vergrößern anklicken....
2016 war LVFS noch nicht erfunden. Fürs X220/T450s gibt es eh keine LVFS-Unterstützung, für das X1C6 ist die Abwägung der Vor- und Nachteile natürlich anders ausgefallen ;). Außerdem sorgen mittlerweile aktuelle -buntus dafür, dass eine Platte auch ohne UEFI Booteintrag gestartet werden kann :D.
 
Ja irgendwie geht das bestimmt. Nur mir fehlt das Wissen. :pinch:

- - - Beitrag zusammengeführt - - -

cyberjonny schrieb:
Hi miteinander,

...............Kurz: Welche Einstellung macht bzgl. Secure Boot im Hinblick auf den Ubuntu-Alltagsgebrauch Sinn - und warum?

Danke euch! :)
Gruß, Jonny
Zum Vergrößern anklicken....

Theoretisch ist eine Evil-Maid Attacke bei Secureboot nicht mehr möglich auf ein unverschlüsselte Bootpartition.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben