Re: Rescatux 0.41b1 released with UEFI rescue options
El 24/04/17 a las 20:02, Lee Fisher escribió:
> On 04/22/2017 02:25 PM, adrian15 wrote:
>> Hi Debian-efi list,
> [...]
>> Last week I released Rescatux 0.41b1 with a bunch of new UEFI rescue
>> options. I just wanted to share with you some technical details about
>> those options so that I can get some feedback from you.
> [...]
> Any feedback is welcome.
> [...]
>> Thank you for any feedback you can give me back!
>
> Hi,
>
> Nice to see more pre-boot diagnostics available! Here are a few things
> I'd like to see in a Rescatux (or inside D-I for that matter):
>
> 1) Have boot option to boot into UEFI shell.
> Instead of only booting into Rescatux Linux, have a boot option to boot
> into UEFI Shell. Include the UEFI Shell on your boot image. ALT Linux
> Rescue does this -- or at least supposedly, it hasn't worked for me. It
> is a nice option if you need to manually run a UEFI Shell app -- a
> firmware update from a vendor, etc. Similar to the need to occasionally
> run a shell from inside an OS installer. In addition to UEFI Shell and
> full set of shell commands, also include CPython for UEFI and CHIPSEC
> for UEFI (see next item). With CPython installed, also have an option to
> jump into Python shell, that'll be more familiar to some than the UEFI
> Shell.
Is there an standard UEFI shell somewhere packaged for Debian that I can
use?
I guess uefi-chainloading from Grub2 will be trivial.
>
> 2) Have a mode to let users run CHIPSEC.
>
> 2a) Have a boot mode that enables root Linux shell with CHIPSEC
> installed, so user can run appropriate CHIPSEC commands.
>
> 2b) Have a boot mode that lets user boot into the UEFI Shell with
> CHIPSEC installed, so user can run appropriate CHIPSEC commands.
>
> Both the OS-present Linux version as well as the UEFI Shell version of
> CHIPSEC would be useful to have, at times they have slightly different
> abilities.) For example, you need to dump PCI option roms at boot-time,
> not after OS is loaded.
>
> CHIPSEC is the only firmware vulnerability scanner around, and AFAIK it
> is the larger OSS project without mainstream packaging, due to concern
> of the CHIPSEC kernel driver having lots of access and little to control
> it, see the WARNING.txt in the CHIPSEC code for more details. However,
> since that warning, CHIPSEC has gotten the ability to run a subset of
> it's abilities withOUT the driver being loaded, which is not reflected
> in that warning.
>
> Today, CHIPSEC installs via Python's PIP installer (which calls 'make'
> to build/install a kernel driver, in addition to the Python
> installation). There is current Debian packaging for CHIPSEC under way,
> see CHIPSEC github code.
>
> One way to reduce impact of CHIPSEC misuse by attacker is to scope it's
> use, not keeping the driver running, is to have it as a menu optin in a
> rescue distro. IMO, having CHIPSEC available in a rescue distro is ideal
> for that audience. Rescuing broken systems aside, this would add a new
> use for Rescatux, analyzing new (or used) systems for security profile.
> Intel (now McAfee) CHIPSEC team also likes idea of putting CHIPSEC as a
> menu option in D-I, which is similar to a rescue distro menu entry.
> https://lists.01.org/pipermail/chipsec/2015-July/000004.html
>
> Today, CHIPSEC is run by Linux UEFI Validation's LUV-live, but in batch
> mode, and you have to manually go view a logfile after all the batched
> tests are done. While this is useful, an interactive use of CHIPSEC's
> security tests would be immediately useful (and interactive use lends to
> colorized output, so you can better see the red failures, than in a
> batch log.)
>
> Extra credit: 2c) Have an automated, non-interactive boot option to run
> CHIPSEC, save a dump of the system firmware (chipsec_util spi dump
> rom.bim), and generate a hash of that image. For both UEFI Shell and
> Linux versions of CHIPSEC. :-)
Well, first time that I learn about CHIPSEC.
Rescatux's audience is newbies but I'm open to add packages such as
gparted, gpart or testdisk for more experienced people.
First of all Rescatux does not support 'Secure Boot' yet because I was
expecting on reusing or relying on Debian's 'Secure Boot' but it seems
it won't be for initial Stretch release (maybe an update release will
have it).
Were you assuming that Rescatux was going to support 'Secure Boot' or not?
So, I'm not sure how useful it would be to run CHIPSEC if Rescatux boot
itself is not self-verified by the UEFI.
If you know how to write something so that this is easily integrated
into Rescatux (e.g. a CHIPSEC enabled kernel package) then I'm open for
it. I can add it.
What I'm not going to do is to learn how to build CHIPSEC, how it's
supposed to work (I would have to check if it actually works as expected
or not), and more things.
But if you know how to install these suite manually and what you are
missing is a live cd that includes it then I can help you. I can be that
live cd.
I won't also work on colorized output.
I can help on adding Rescapp options so that you can run the different
CHIPSEC tests individually from Rescapp if you want to.
As Rescapp already puts the commands output into a log file you could
then share that log into a forum or a pastebin very easily with two clicks.
>
> 3) Have an option to run FWTS interactively, like FWTS-live does.
> In addition to CHIPSEC, FWTS, Canonical's FirmWare TestSuite is also a
> good set of pre-boot tools to run, especially for ACPI. Running FWTS in
> a boot option, like FWTS-live does would be ideal. BTW, please pdate
> FWTS's Secure Boot test to support Debian and Rescatux keys, it only
> currently supports Ubuntu key. In addition to Intel,
Is this program available from a ppa?
I could easily add it then.
Yeah, well, 'Secure Boot' I already commented before.
> FWTS also supports
> ARM and OpenPOWER, so you have some more images to create. :-)
I already have too much struggle with amd64 and x86 where source code is
not well packed from the live-build project.
>
> 4) Other LUV tests?
> LUV-live may have a few other tests you might want to think about
> running as boot options in Rescatux. BITS, for example.
If it's just a matter of adding a package or a simple script that you
can guide me I'm open for it but I won't work actively on it.
>
> 5) Use Intel TXT on your system, so we can trust anything you say. If
> attacker has taken over a system, all test results (eg, CHIPSEC security
> test results) can be faked.
Once again you can instruct me on how to do that and depending how
difficult it is (and also how much bigger Rescatux becomes. I don't want
it to be more than 700 MB if possible) I might add it or not.
>
> Hope this helps.
>
> Thanks,
> Lee Fisher
> https://preossec.com/
> personal blog: https://firmwaresecurity.com/
>
> 6) Check UEFI DBX revocation file for bad Secure Boot certs
Same as before.
BTW, Rescatux includes SELinux for the sole purpose of being able to fix
SELinux systems such as RedHat, Fedora and so on. Unfortunately due to
jessie bugs ssh-server package is not installable when booted in that mode.
Thank you very much for your feedback. I learnt some stuff I wasn't
aware of.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Reply to: