There are a few things I don't like about Secure Boot. For people that use/need hibernation support, that is gone with secure boot. There are patches to use a TPM to sign the image but it will be a pain. Microsoft basically owns the entire Secure Boot space, even the Shim loader has to be signed by Microsoft. (Although I think some UEFI installations allow you to remove factory keys) But the biggest issue is probably that it's benefits are questionable. The Shim loads a OS that is signed by a user installed key (MOK). The key can be installed via a command from the OS, so there is actually not much from stopping malware from adding the attackers key to the MOK storage region (since the OS can install a mok, the storage region is not locked down). Afaik this was already done by the BlackLotus bootkit where part of it's installation process involved adding the attackers MOK to NvRam so that the shim would load that Bootkit. It should also be mentioned that UEFI doesn't really authenticate hardware, there are also a ton of other things like Measured boot via a TPM which doesn't really have much to do with Secure Boot. The Hardware/Firmware image authentication is usually done by things like Intels Boot Guard which is a another layer down, preventing the CPU from initializing if the firmware itself isn't signed. This is actually bad in my opinion because it prevents users from installing open source firmware like coreboot or edk2 based firmware. There is currently no solution to run open source firmware if Boot Guard is enabled which is why manufacturers like System76, StarLabs, Purism don't use it.
The only thing Secure Boot stops is a slightly above average script kiddie / bot, so i suppose secureboot is just about statistically minimizing risks. I saw a video recently with a guy plugging a windows 2000 computer to the internet directly without a NAT in between, and within a few minutes it got a crypto miner or something onto it through the deep blue exploit.
I enabled secure boot on my system. It's a dual boot of Windows 11 and KDE Neon, both work with secure boot, altough I did have to run 'dpkg-reconfigure nvidia-dkms', because I have an Nvidia GPU. Then I could reboot and enroll the key for it, so that the nvidia driver would boot successfully. I also had to enroll a key for HackBGRT, because I modified the Windows boot logo.
You have some good points but I think you (vastly) overestimate Secure Boot's actual efficiency, and understimate how easy it is to bypass. Realistically, considering I will myself make a lot of modifiications to my boot code and how trivial the process of enrolling new keys is anyway, I can't see Secure Boot reducing my attack surface enough to justify the pain of managing it in a responsible way. Especially since your solution is to advice people to force-inject the signature everytime you need to, which would eventually lead the unaware user to validating malicious code himself anyway just to get their computer to boot. At least you need to explain that signing your own kernel builds without proper and educated review of the modifications made totally undermines its point, before leaving people to tinker with a wrongful feeling of security ^^"
Defense in depth isn't about every barrier being perfect, but instead having many different hurdles an attacker needs to bypass to reach your most important data or completely take control of the device. Secure Boot certainly isn't perfect, but it's one of your stronger defenses and an attacker must have a vuln ready for it to get very far into your system. Chances of that alongside necessary vuln for other barriers is vastly reduced.
I just wanted to say that Secure boot has been mandatory on all my laptops for the past 2 years, secure boot + a password to your bios = good luck on doing whatever on my laptop if you steal it I use Arch btw
@@xCwieCHRISx Some manufacturers like HP make it so that, unless the BIOS controller is replaced, BIOS remains password locked. CMOS flushing or battery replacement won't reset the master password. In my case, it's Insyde, but I'm sure others can also be locked down. It's mostly to do with the systems integrator's laziness, indifference and lack of attention or some combination thereof.
Secure boot is a headache because I couldn't get arch installed with it enabled (wouldn't even boot from usb) the reason? idk but disabling secure boot fixed it, I also don't have tpm 2, not even in software mode because my mb just doesn't have it, while they are meant as security measures they're most of the time just an awful waste of time (either you work by default or be opt in), the best security measure is not being a dumbass on the internet. I recommend disabling secure boot because unlike your video says it's still a problem to this day if you're not using windows and some distros (most that aren't ubuntu and fedora) require manual implementation from the user.
I will say this. Setting up Secureboot can be a nightmare. I have setup Fedora + Nvidia proprietary drivers + secureboot in the past, and at least at that point, the process with mokutils etc wasn't documented properly at all. I had to stitch together a few guides for much older Fedora versions and other guides to make it work. These days I've got a Framework laptop with an Archbased distro, and I can just use 'sbctl' to manage secureboot. Its SO MUCH EASIER than mokutil was. Just not sure if this would work on any Laptop. I think this goes into what you were talking about. The framework as great Linux Support, and it's UEFI supports setting the platform keys (? Or one of these, the one that has Microsoft keys by default). But still that setup, while at least nicely documented, wasn't without issues. I set this up with other stuff, and then realized that my docking station and ethernet adapter were not working. Turns out you better install the Microsoft keys too if you want support of much of these things, after I did that on a hunch, they suddenly started working again.
@@Trafotin if you mean the enrolling of MS Keys on Archbased to support Hardware, nah, that's not a dualboot system. Fedora was. But the setup I've done with sbctl REPLACES some keys that are installed by default. So on my Laptop I don't need to use a tool that MS deigned to sign, I can sign stuff myself. But if I do that I have to add back support for MS Keys, otherwise some stuff doesn't work. Not ENTIRELY sure why, perhaps they are actually signed with certs from Ms, tho that doesn't really make sense to me. It's also been a while since I've set it up, so I don't really remember. Security stuff like these is sadly complex by nature, and since I hate it I don't do it on a daily basis and forget about it after I have not done it for some time, I just remember the red flags.
@@9SMTM6 If you install the keys without the microsoft keys, you can actually brick your system. Hardware components can run their own code during boot to start up properly and this code also has to be signed. You got lucky that it was only non-essential parts of your system that stopped working - there are reports of people being unable to boot entirely. The fact that users cannot easily change the keys used by secure boot is why it is such a fatally flawed technology. There are bootloaders with publicly known vulnerabilities that are signed with the Microsoft keys. This allows attackers to bypass secure boot entirely.
@@orbital1337 oh I knew that was safe, based on documentation from Framework. The situation you're referring to was why I didn't add the MS Keys at first. I was unaware that even plug and play hardware would need them.
The real question is : is using Secure Boot relevant in any way if you basically enroll anything to it ? I believe the real attack vector is somewhere else, and if your provider or process for installing and updating kernel/firmwares is compromised, using tools to forcefully sign them will render Secure Boot useless in the real world. It's like using a firewall but allowing it to make exceptions everytime you're asked without further review... Secure Boot has a point for Windows or machines running some LTS Linux, if you're down to the point of regularly using tools to force it to run your builds without a deep understanding of the modifications you've made, it's got nothing for you really.
People are told to disable secure boot because secure boot is simply an annoying obstacle to work around. The security benefits are slim to none on a system that isn't completely locked down like these freakish modern windows kernels are.
The point engineers from Canonical and Red Hat are making is Secure Boot isn't taking away control or locking away things. Secure Boot is fully controllable by the open firmware systems like TianoCore and coreboot. There are still problems, but the problems right now is Linux doesn't do a good job at securing boot processes. There's a talk from Matthew Garrett at Linux Conf AU from a few years back that's a great explainer in the description.
@@Trafotin That talk explains exactly why secure boot is so useless, and in the talk he suggests just going in and turning it off. He even laments that it will be difficult to make a clear guide for naive users to instruct them on how to turn off secure boot because the settings interfaces are likely to be wildly inconsistent between different firmware vendors. Linux will never really do a "good" job at "securing boot processes" as you put it, because this is not very useful. If I can't sign my own kernel and modules, then the system is locked down (anti-user, user-subjugating). But if I can sign them, as you show an example of in your video, then the secure boot scheme is undermined because malware can just sign its rootkit using the same process. Also, other parts of "securing" the kernel involve locking out various otherwise useful interfaces like kmem, so it's a very limiting experience. Secure boot is really designed just for corporate systems where there's a central authority (IT department), or for windows systems where there's a central self-appointed god emperor (Microsoft) enacting its will upon its subjects.
It makes sense in one way but its also a lame solution in another. It's good if you use a normie operating system where its just a product and what you get is what you get. But making it so i have to do stupid script bs in order to install third party kernel stuff or even modify my own kernels is stupid. This is a constant game of manufacturers trying to add encryption to every process of computing. Its defence by locking everything down. In a way its kind of lazy. This is why Apple are "ahead" in this space. Their philosophy is to lock down their devices as much as possible. So much of this security shit is smokescreen for taking power away from the user.
I don't think that an OS interacts with hardware through BIOS. The only role of BIOS is to do POST operation and then hand over the control of HW to OS.
Thank you for this video. I've struggled to get Linux users to understand why secure boot is important and that distros that say to disable it are unsafe.
@dreaper5813 The downside, as mentioned in the video, is significantly reduced baseline security and the potential to get your motherboard rooted in an unrecoverable way. That said, yes a lot of people seem to enjoy playing Russian roulette with their computers...
@dreaper5813 Secure boot protects against device rooting both local and remote. You are demonstrating why so many Linux users are ignorant of security however. Linux is not secure by default. Many distros ship with the firewall switched off. Most users insist on installing apps via a package manager with root permissions vs flatpak/snap/appimage. There is little consideration of supply chain attacks and users willfully downgrade their security as you mention here. The non server Linux user base is a very ripe target, unfortunately.
@@Lu-Die-MilchQ Again,layered security is important to protect against bugs and mistakes. Humans make mistakes, no operating system should have a security posture that assumes developers and packagers are perfect.
Hey thanks for the contribution! That's something that i really wanted to do for my Linux. And after some study of the scripts. Which is the execution order for the scripts? Because I can't find it on the GitLab repo. Thanks.
If you go to my GitLab in the description, you run nvidia-fedora-keygen, you will prompted to create a one-time password. Then reboot, you will be prompted to enter your password and trust your key. Then afterwards, boot in and install the Nvidia drivers as normal with nvidia-fedora-current. EDIT: .sh is a TLD, so removed the extension.
Not if you use Linux, secure boot can and will cause problems. Better way just update BIOS and have at least setup if not admin password for uefi/BIOS.
@@Trafotin That's if you're ever able to boot into the Operating System in which many have had problems booting into the OS with secure boot enabled. It's useless
This is a really important vid for Linux newcomers like myself. Thank you. How well does Debian handle self-signed secure boot keys? Ubuntu sounds like the convenient option
I dual boot windows 11 and Fedora 37 (I haven’t upgraded to 38 yet). On Fedora I haven’t installed any extra drivers (for WiFi). So can I turn on Secure Boot and expect no issues?
Mostly I did not understand anything , only a little bit on the last part of your video... So , generally is good to have UEFI and Secure Boot enabled, this I understood. Regarding UEFI this I think is depending on your hardware. If you have an old laptop/PC , you don't have UEFI and Secure Boot .... If it is newer hardware , is good to have CSM option in BIOS disabled and Secure Boot enabled. If you install only Windows 10/11 on your computer, ENABLE ! Secure Boot and DISABLE ! CSM on BIOS. Then install Windows and .... finish with / can forget about Secure Boot ... The problems appear when you DUAL BOOT , Windows 10 and Linux on an UEFI with Secure Boot ENABLED ! computer , and on the same SSD / HDD ( Windows 10 + Q4OS Linux my case ...) Maybe you can do some videos in this regard .... on a REAL computer, not on a VM ..... I like your "hmmm"-s after a sentence .... Kind of original 🙂
Not a secure boot problem. That was largely OEMs who stopped updating lots of motherboards. The more critical concern was the motherboards in server racks. Do not spread FUD. Secure boot is a necessary part of computing. It's the default on Windows, Ubuntu, and Fedora.
@@Trafotin Secure boot is absolutely not a necessary part of computing, this a ridiculous notion. Computing has been around for many decades prior to secure boot and anything like it.
Год назад
I like how you are making that "villager noise" after sentence.. cute.. anyways I struggle making secure boot to work after I modified my vbios on my amd card *sadge*
As a archlinux user, secure boot is a bit hard 1 of 2 reboot or shutdown it possible that your system don't boot at all with a great led on while boot on my motherboard. so yes i want to know how it possible to add mok key to bios for every OS that i use on my computer depend on my need it's really annoying because i use esxi vmware for server case, archlinux for more day to day workload and finally an tailOS to do some osint stuff and forensics and also truenas to move like 1Tb of data oven networking while keep a great speed. one general script that work for all could be good in my case as this 3 OS work completly diffetrent even in their file system and syscall.
This RUclips video could never be more wrong. Windows has been shown numerous times to have countless more vulnerabilities than Linux despite having secure boot enabled making it the most useless piece of security device on your system. If signing your drivers using boot keys is the only way to get your gpu to work, then all that takes is malware to go inside and replicate that making that entire concept useless. It's all about practicing hygiene when surfing the web and not trusting corporations to do everything for us. And yes I mean not entrusting Microsoft to automatically install updates. But if we don't do that, they block admin privileges because "it's for your own safety." It is merely just to get out of responsibility while trying to control how we operate our devices. Not only that, people that don't have TPM enabled have reported performance improvements and less headaches when installing distros. Telling Linux users that secure boot have security benefits is like telling others that spaghetti can cure cancer. There's always going to be that one person to fall for it. But in the end, it's just snake oil. Btw If Linux is playing catch up, why are people switching to it from Windows?
Great info! But hackers can hack into my computer if they really want to. I make sure that I don't have anything SUPER important or SUPER private. So hack away..I think they will get bored very soon. Or maybe not..they might find some of my downloaded movies entertaining. No system is hack proof. Hope that you don't get hacked. But if you assume that you will get hacked, then you should keep the important stuff offline and off the internet.
Good video. Why are Linux and Windows so far behind Mac and mobile devices? How could Linux and Windows improve so that they are not so far behind Mac and mobile devices?
Apple has more complete verified boot from their mobile platform and control over their hardware, which you can read about if you read their security whitepaper. Windows 11 has verified boot too, but it relies too much on TPM and Linux has to play catch up. The guy I showed talking is Matthew Garrett of Red Hat and has a bunch of talks on RUclips.
Hello, thank for your video you gain a new subscriber and do you know how do add secure boot for kali and parrot Linux I need them but i need to disable secure boot so is there to add for kali and parrot Linux?
I don't know, but will point out Debian does not enroll a secure boot key, so those distros might inherit that behavior. You shouldn't use penetration testing distros as your main operating system, but they are fine as tools.
I think that secure boot is cool but it sucks that it's a pain to set up if you're using Linux unless your distro specifically supports it
@@JessicaFEREM do you know if can I run mint with secure boot enable? Or it will always crash on inicialization?
There are a few things I don't like about Secure Boot.
For people that use/need hibernation support, that is gone with secure boot. There are patches to use a TPM to sign the image but it will be a pain.
Microsoft basically owns the entire Secure Boot space, even the Shim loader has to be signed by Microsoft. (Although I think some UEFI installations allow you to remove factory keys)
But the biggest issue is probably that it's benefits are questionable. The Shim loads a OS that is signed by a user installed key (MOK). The key can be installed via a command from the OS, so there is actually not much from stopping malware from adding the attackers key to the MOK storage region (since the OS can install a mok, the storage region is not locked down). Afaik this was already done by the BlackLotus bootkit where part of it's installation process involved adding the attackers MOK to NvRam so that the shim would load that Bootkit.
It should also be mentioned that UEFI doesn't really authenticate hardware, there are also a ton of other things like Measured boot via a TPM which doesn't really have much to do with Secure Boot. The Hardware/Firmware image authentication is usually done by things like Intels Boot Guard which is a another layer down, preventing the CPU from initializing if the firmware itself isn't signed. This is actually bad in my opinion because it prevents users from installing open source firmware like coreboot or edk2 based firmware. There is currently no solution to run open source firmware if Boot Guard is enabled which is why manufacturers like System76, StarLabs, Purism don't use it.
The only thing Secure Boot stops is a slightly above average script kiddie / bot, so i suppose secureboot is just about statistically minimizing risks. I saw a video recently with a guy plugging a windows 2000 computer to the internet directly without a NAT in between, and within a few minutes it got a crypto miner or something onto it through the deep blue exploit.
I enabled secure boot on my system. It's a dual boot of Windows 11 and KDE Neon, both work with secure boot, altough I did have to run 'dpkg-reconfigure nvidia-dkms', because I have an Nvidia GPU. Then I could reboot and enroll the key for it, so that the nvidia driver would boot successfully. I also had to enroll a key for HackBGRT, because I modified the Windows boot logo.
You have some good points but I think you (vastly) overestimate Secure Boot's actual efficiency, and understimate how easy it is to bypass.
Realistically, considering I will myself make a lot of modifiications to my boot code and how trivial the process of enrolling new keys is anyway, I can't see Secure Boot reducing my attack surface enough to justify the pain of managing it in a responsible way. Especially since your solution is to advice people to force-inject the signature everytime you need to, which would eventually lead the unaware user to validating malicious code himself anyway just to get their computer to boot.
At least you need to explain that signing your own kernel builds without proper and educated review of the modifications made totally undermines its point, before leaving people to tinker with a wrongful feeling of security ^^"
Defense in depth isn't about every barrier being perfect, but instead having many different hurdles an attacker needs to bypass to reach your most important data or completely take control of the device. Secure Boot certainly isn't perfect, but it's one of your stronger defenses and an attacker must have a vuln ready for it to get very far into your system. Chances of that alongside necessary vuln for other barriers is vastly reduced.
I just wanted to say that Secure boot has been mandatory on all my laptops for the past 2 years, secure boot + a password to your bios = good luck on doing whatever on my laptop if you steal it
I use Arch btw
Yep I also do that, but don't be that guy that leaves the bios password in when reselling the device (happened too often) 😅
@@Akab cant you just reset the bios via cmos clear?
@@xCwieCHRISx Some manufacturers like HP make it so that, unless the BIOS controller is replaced, BIOS remains password locked. CMOS flushing or battery replacement won't reset the master password. In my case, it's Insyde, but I'm sure others can also be locked down. It's mostly to do with the systems integrator's laziness, indifference and lack of attention or some combination thereof.
Secure boot is great but what are the chance you get infected with a rootkit
Could we see a tutorial of how to enable Secure Boot with Arch Linux?
get ready to enroll those MOKs
@@Proferk I did, not clear enough on the Arch Wiki. RTFM only works if the manual is helpful enough to the end user.
Secure boot is a headache because I couldn't get arch installed with it enabled (wouldn't even boot from usb) the reason? idk but disabling secure boot fixed it, I also don't have tpm 2, not even in software mode because my mb just doesn't have it, while they are meant as security measures they're most of the time just an awful waste of time (either you work by default or be opt in), the best security measure is not being a dumbass on the internet. I recommend disabling secure boot because unlike your video says it's still a problem to this day if you're not using windows and some distros (most that aren't ubuntu and fedora) require manual implementation from the user.
I will say this. Setting up Secureboot can be a nightmare.
I have setup Fedora + Nvidia proprietary drivers + secureboot in the past, and at least at that point, the process with mokutils etc wasn't documented properly at all. I had to stitch together a few guides for much older Fedora versions and other guides to make it work.
These days I've got a Framework laptop with an Archbased distro, and I can just use 'sbctl' to manage secureboot. Its SO MUCH EASIER than mokutil was. Just not sure if this would work on any Laptop. I think this goes into what you were talking about. The framework as great Linux Support, and it's UEFI supports setting the platform keys (? Or one of these, the one that has Microsoft keys by default).
But still that setup, while at least nicely documented, wasn't without issues. I set this up with other stuff, and then realized that my docking station and ethernet adapter were not working. Turns out you better install the Microsoft keys too if you want support of much of these things, after I did that on a hunch, they suddenly started working again.
If you dual boot on one drive (like a laptop), I have read about this. I refuse to dual boot on one drive out of paranoia Microsoft bricks grub.
@@Trafotin if you mean the enrolling of MS Keys on Archbased to support Hardware, nah, that's not a dualboot system.
Fedora was.
But the setup I've done with sbctl REPLACES some keys that are installed by default. So on my Laptop I don't need to use a tool that MS deigned to sign, I can sign stuff myself. But if I do that I have to add back support for MS Keys, otherwise some stuff doesn't work. Not ENTIRELY sure why, perhaps they are actually signed with certs from Ms, tho that doesn't really make sense to me.
It's also been a while since I've set it up, so I don't really remember. Security stuff like these is sadly complex by nature, and since I hate it I don't do it on a daily basis and forget about it after I have not done it for some time, I just remember the red flags.
@@9SMTM6 If you install the keys without the microsoft keys, you can actually brick your system. Hardware components can run their own code during boot to start up properly and this code also has to be signed. You got lucky that it was only non-essential parts of your system that stopped working - there are reports of people being unable to boot entirely.
The fact that users cannot easily change the keys used by secure boot is why it is such a fatally flawed technology. There are bootloaders with publicly known vulnerabilities that are signed with the Microsoft keys. This allows attackers to bypass secure boot entirely.
@@orbital1337 oh I knew that was safe, based on documentation from Framework.
The situation you're referring to was why I didn't add the MS Keys at first. I was unaware that even plug and play hardware would need them.
The real question is : is using Secure Boot relevant in any way if you basically enroll anything to it ?
I believe the real attack vector is somewhere else, and if your provider or process for installing and updating kernel/firmwares is compromised, using tools to forcefully sign them will render Secure Boot useless in the real world. It's like using a firewall but allowing it to make exceptions everytime you're asked without further review...
Secure Boot has a point for Windows or machines running some LTS Linux, if you're down to the point of regularly using tools to force it to run your builds without a deep understanding of the modifications you've made, it's got nothing for you really.
Hey Trafotin...what are your thoughts on the recent changes to the RedHat universe? Think we can trust RHEL/IBM to keep putting out a good Fedora DE??
Fedora is upstream from RHEL, the decision made by Red Hat does not impact Fedora since RHEL is downstream from it.
People are told to disable secure boot because secure boot is simply an annoying obstacle to work around. The security benefits are slim to none on a system that isn't completely locked down like these freakish modern windows kernels are.
The point engineers from Canonical and Red Hat are making is Secure Boot isn't taking away control or locking away things. Secure Boot is fully controllable by the open firmware systems like TianoCore and coreboot. There are still problems, but the problems right now is Linux doesn't do a good job at securing boot processes. There's a talk from Matthew Garrett at Linux Conf AU from a few years back that's a great explainer in the description.
@@Trafotin That talk explains exactly why secure boot is so useless, and in the talk he suggests just going in and turning it off. He even laments that it will be difficult to make a clear guide for naive users to instruct them on how to turn off secure boot because the settings interfaces are likely to be wildly inconsistent between different firmware vendors.
Linux will never really do a "good" job at "securing boot processes" as you put it, because this is not very useful. If I can't sign my own kernel and modules, then the system is locked down (anti-user, user-subjugating). But if I can sign them, as you show an example of in your video, then the secure boot scheme is undermined because malware can just sign its rootkit using the same process. Also, other parts of "securing" the kernel involve locking out various otherwise useful interfaces like kmem, so it's a very limiting experience.
Secure boot is really designed just for corporate systems where there's a central authority (IT department), or for windows systems where there's a central self-appointed god emperor (Microsoft) enacting its will upon its subjects.
Understood. The channel is backed by Microsoft
😂
Yeah, they love my Panos Panay fan videos. 😂
Microsoft shill 🤓🤓
It makes sense in one way but its also a lame solution in another. It's good if you use a normie operating system where its just a product and what you get is what you get. But making it so i have to do stupid script bs in order to install third party kernel stuff or even modify my own kernels is stupid.
This is a constant game of manufacturers trying to add encryption to every process of computing. Its defence by locking everything down. In a way its kind of lazy. This is why Apple are "ahead" in this space. Their philosophy is to lock down their devices as much as possible. So much of this security shit is smokescreen for taking power away from the user.
Virtually create problems, find virtual fixes to lock down the user. (TPM)
I use MBR boot (no uefi and no efi) if possible.
Great job yet again Mr Matt but what Game Emulators do you use on your Linux Pcs Hope you can make a video about them sometime in the future
Almost all popular emulators distribute a linux version as well, but I'd like to see what he recommends as well😁👍
@@Akab Thanks but we have to wait and see Which Emulators he uses
I don't think that an OS interacts with hardware through BIOS. The only role of BIOS is to do POST operation and then hand over the control of HW to OS.
Thank you for this video. I've struggled to get Linux users to understand why secure boot is important and that distros that say to disable it are unsafe.
@dreaper5813 The downside, as mentioned in the video, is significantly reduced baseline security and the potential to get your motherboard rooted in an unrecoverable way. That said, yes a lot of people seem to enjoy playing Russian roulette with their computers...
@dreaper5813 Secure boot protects against device rooting both local and remote. You are demonstrating why so many Linux users are ignorant of security however. Linux is not secure by default. Many distros ship with the firewall switched off. Most users insist on installing apps via a package manager with root permissions vs flatpak/snap/appimage. There is little consideration of supply chain attacks and users willfully downgrade their security as you mention here. The non server Linux user base is a very ripe target, unfortunately.
@@Lu-Die-MilchQ Again,layered security is important to protect against bugs and mistakes. Humans make mistakes, no operating system should have a security posture that assumes developers and packagers are perfect.
Hey thanks for the contribution! That's something that i really wanted to do for my Linux. And after some study of the scripts. Which is the execution order for the scripts? Because I can't find it on the GitLab repo. Thanks.
If you go to my GitLab in the description, you run nvidia-fedora-keygen, you will prompted to create a one-time password. Then reboot, you will be prompted to enter your password and trust your key. Then afterwards, boot in and install the Nvidia drivers as normal with nvidia-fedora-current.
EDIT: .sh is a TLD, so removed the extension.
Not if you use Linux, secure boot can and will cause problems. Better way just update BIOS and have at least setup if not admin password for uefi/BIOS.
You could just do both... installing the generic Microsoft key using mokutil is a thing.
@@Trafotin That's if you're ever able to boot into the Operating System in which many have had problems booting into the OS with secure boot enabled. It's useless
If turned on, I cannot install debian, so I turned it off
Secure boot doesn’t run with arch based os but ubuntu can run with secure boot
This is a really important vid for Linux newcomers like myself. Thank you. How well does Debian handle self-signed secure boot keys? Ubuntu sounds like the convenient option
Great job! Thank you!
I have been using secure boot with Garuda Linux and I have had no issues.
Hell no, Arch, most Linux distros and the BSDs does not come with secure boot enabled by default or supported at all.
You had some pretty crazy opinions but I don't remember what they were. I did subscribe because you made pretty good videos though.
I dual boot windows 11 and Fedora 37 (I haven’t upgraded to 38 yet). On Fedora I haven’t installed any extra drivers (for WiFi). So can I turn on Secure Boot and expect no issues?
Mostly I did not understand anything , only a little bit on the last part of your video... So , generally is good to have UEFI and Secure Boot enabled, this I understood. Regarding UEFI this I think is depending on your hardware. If you have an old laptop/PC , you don't have UEFI and Secure Boot .... If it is newer hardware , is good to have CSM option in BIOS disabled and Secure Boot enabled. If you install only Windows 10/11 on your computer, ENABLE ! Secure Boot and DISABLE ! CSM on BIOS. Then install Windows and .... finish with / can forget about Secure Boot ... The problems appear when you DUAL BOOT , Windows 10 and Linux on an UEFI with Secure Boot ENABLED ! computer , and on the same SSD / HDD ( Windows 10 + Q4OS Linux my case ...) Maybe you can do some videos in this regard .... on a REAL computer, not on a VM ..... I like your "hmmm"-s after a sentence .... Kind of original 🙂
Hey Trafotin will be making a short video of your recent live video " fedora silverblue and distrobox"
I also enable TPM as well.
WTF is "Thrid-party operating systems like Linux" xddd like why microsoft's bullshit should be the "first party"
Well this aged bad. As of now secure boot is broken on a huge number of pc's
Not a secure boot problem. That was largely OEMs who stopped updating lots of motherboards. The more critical concern was the motherboards in server racks.
Do not spread FUD. Secure boot is a necessary part of computing. It's the default on Windows, Ubuntu, and Fedora.
@@Trafotin Secure boot is absolutely not a necessary part of computing, this a ridiculous notion. Computing has been around for many decades prior to secure boot and anything like it.
I like how you are making that "villager noise" after sentence.. cute.. anyways I struggle making secure boot to work after I modified my vbios on my amd card *sadge*
As a archlinux user, secure boot is a bit hard 1 of 2 reboot or shutdown it possible that your system don't boot at all with a great led on while boot on my motherboard.
so yes i want to know how it possible to add mok key to bios for every OS that i use on my computer depend on my need it's really annoying because i use esxi vmware for server case, archlinux for more day to day workload and finally an tailOS to do some osint stuff and forensics and also truenas to move like 1Tb of data oven networking while keep a great speed.
one general script that work for all could be good in my case as this 3 OS work completly diffetrent even in their file system and syscall.
No
Garuda Linux does not have secure boot
Thanks
This RUclips video could never be more wrong. Windows has been shown numerous times to have countless more vulnerabilities than Linux despite having secure boot enabled making it the most useless piece of security device on your system. If signing your drivers using boot keys is the only way to get your gpu to work, then all that takes is malware to go inside and replicate that making that entire concept useless. It's all about practicing hygiene when surfing the web and not trusting corporations to do everything for us. And yes I mean not entrusting Microsoft to automatically install updates. But if we don't do that, they block admin privileges because "it's for your own safety." It is merely just to get out of responsibility while trying to control how we operate our devices. Not only that, people that don't have TPM enabled have reported performance improvements and less headaches when installing distros. Telling Linux users that secure boot have security benefits is like telling others that spaghetti can cure cancer. There's always going to be that one person to fall for it. But in the end, it's just snake oil.
Btw If Linux is playing catch up, why are people switching to it from Windows?
Because freedom and security are not the same thing. We need secure boot and TPM and the major Linux distros and developers are adopting it as well.
Great info! But hackers can hack into my computer if they really want to. I make sure that I don't have anything SUPER important or SUPER private. So hack away..I think they will get bored very soon. Or maybe not..they might find some of my downloaded movies entertaining. No system is hack proof. Hope that you don't get hacked. But if you assume that you will get hacked, then you should keep the important stuff offline and off the internet.
Good video.
Good video. Why are Linux and Windows so far behind Mac and mobile devices? How could Linux and Windows improve so that they are not so far behind Mac and mobile devices?
Apple has more complete verified boot from their mobile platform and control over their hardware, which you can read about if you read their security whitepaper. Windows 11 has verified boot too, but it relies too much on TPM and Linux has to play catch up. The guy I showed talking is Matthew Garrett of Red Hat and has a bunch of talks on RUclips.
Hello, thank for your video you gain a new subscriber and do you know how do add secure boot for kali and parrot Linux I need them but i need to disable secure boot so is there to add for kali and parrot Linux?
I don't know, but will point out Debian does not enroll a secure boot key, so those distros might inherit that behavior. You shouldn't use penetration testing distros as your main operating system, but they are fine as tools.
@@Trafotin So it is okay to use dual boot for parrot Linux as a penetration when I needed and use Windows as a daily use let me know
@@Light13378 why do you have parrot/kali installed on bare hardware?
@@a-c1081 Because I want to explore cyber security
My WiFi driver doesn't work with secure boot, so there's not much I can do.
That's not how that works...
@@Trafotin explain
Nightmare nightmare nightmare
metaverse avatars are fucking creepy
I don't participate in any metaverses. Not even VR Chat.
Great job yet again Mr Matt but what Game Emulators do you use on your Linux Pcs Hope you can make a video about them sometime in the future