Prevent access to internal harddisk of the PC [SOLVED]

Technical issues/questions of an intermediate or advanced nature.
User avatar
user0815
Black ninja
Black ninja
Posts: 63
Joined: 22 Jan 2019, 11:46
Distribution: CINNAMON-v4.0-x86_64

Prevent access to internal harddisk of the PC [SOLVED]

Post#1 by user0815 » 02 Feb 2019, 17:31

Dear All,
Can someone please advise how to completely deny access to the built-in hard disk of the computer? I tried the cheat code nohd, but I believe this code just leave the hard disk unmounted. GParted still have access to the hard disk when opened. When working in an insecure environment, I want to leave the hard disk completely "untouched", so no malware can be loaded from/to hard disk. It should work similar to the bankix project from Ct magazin https://heise.de/-284099, sorry that it is available only in german. Does anyone know a good way how to do it? Thanks.
using CINNAMON-v4.0-x86_64 with updated kernel porteus-4.16.8

User avatar
AcnapyxoB
Samurai
Samurai
Posts: 191
Joined: 24 Dec 2014, 10:15
Distribution: Porteus 5.01
Location: Planet Earth

Re: prevent access to internal harddisk of the PC

Post#2 by AcnapyxoB » 02 Feb 2019, 17:38

Try with noauto cheatcode.
Porteus v5.01 KDE x86_64

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: prevent access to internal harddisk of the PC

Post#3 by Rava » 03 Feb 2019, 00:23

https://www.heise.de/ct/artikel/Sichere ... 84099.html says
Wir empfehen, c't Bankix mittels UNetbootin auf einem USB-Stick mit Schreibschutzschalter oder einer SD-Speicherkarte zu installieren – wobei es insbesondere bei SD-Karten entscheidend ist, den Schreibschutz zu überprüfen, da dessen Funktion einzig vom verwendeten Kartenleser abhängt. Alternativ können Sie das ISO-Image auf eine DVD brennen
I presume you are not bothered by that issue named in the above quote? Especially the one that you have to make sure the read-only switch on a SD-card depends on the card reader alone and is not a hardware switch that really sets the card itself into a read-only, no writing mode?
Projekt c't Bankix ist eingestellt
c't Bankix war ein von Ubuntu abgeleitetes Live-Linux-Betriebssystem, das speziell für sicheres Online-Banking konzipiert wurde. Es wurde von Mitte 2008 bis 2016 entwickelt und unterstützt, genauere Informationen zum Projektende finden Sie in den Kommentaren.
So, it is no longer maintained since mid of 2016.

I know the anti virus / virus scan CDs or DVDs ct packed with some special anti virus / virus scan magazines for some time, these they have not been able to offer without the magazine due to the restrictive licenses of some of the virus scanners provided.

But I presume there should be no such issues with bankix. Do you know of a source where one could download the most recent bankix? At least when we have one to test, we might figure out if this system differs from Porteus when started with the cheatcode "noauto hohd".
_____________________________________________

Then again, the article states explicitly
Die wichtigste Sicherheitsfunktion ist, dass die im Rechner verbauten Festplatten (SATA, PATA) von c't Bankix aus unerreichbar sind – dazu haben wir eine spezielle Änderung in den Linux-Kernel integriert.
Of course, since Linux can only have one kernel, it is not possible for Porteus to have that patch included in the standard Porteus flavour. I presume you will understand why that cannot be.

When it comes to such issues with a specialized Porteus Kernel Builder kernel, especially one that has a rare patch like the mentioned (and sadly they don't go into any details in that article, but maybe the ct magasin you still have with such bankix has more details on that patch), I suggest you head over to one of neko's posts. A good start might be this one Porteus Kernel Builder He is the resident Porteus Linux kernel guru and might be able to either direct you to the patches needed, or maybe is even willing to create such a patched Porteus Linux kernel for you. But that depends on him, I can not guarantee anything, what free time he has for such extra adventures I don't know, but usually he is helpful to all polite requests concerning Porteus special kernels.

Then again, our main developer, brokenman, is quite interested in my for now abandoned approach in creating modules for a Porteus that turns it into a security audit. See my post here: Vulnerability scanners
having a specialized kernel with disabled reading of the harddisk would not help here, since some of these tools are for analysing the hardware and having an audit of what malware was found.
___________________________________

Anyway, when it comes to possible malware infected machines? You know of the latest trend (that is now already some years old…) in that "business", creating a virtual machine during boot time that loads prior the kernel or any other code loaded from any OS, including Linux?
The "real OS" is just running in that malware VM. When the PC you are concerned about does have such malware already installed, you will be out of luck, since this malware already controls everything on that machine, and usually no malware scanner can detect anything since the VM of the malware has complete control over what any later started software is able to see, or not to see.
Cheers!
Yours Rava

User avatar
user0815
Black ninja
Black ninja
Posts: 63
Joined: 22 Jan 2019, 11:46
Distribution: CINNAMON-v4.0-x86_64

Re: prevent access to internal harddisk of the PC

Post#4 by user0815 » 08 Feb 2019, 16:45

@AcnapyxoB: noauto wouldn´t really help, since it just "..does not mount any devices during startup.
Every disk needs to be mounted manually in order to access it". The internal hard drive can still be mounted by accident or a malware. I am looking for an option to deny access on kernel level. I know it´s a bit "paranoia", and there are things such as changing default passwords, switch firewall to strict mode etc which you can do, but I want a safe live usb system which you can use in an environment with high risk of malware infection. The ctbankix was once a good option to do this, but now they stopped maintenance years ago.
@Rava
The main reason why I am exploring Porteus is that I like it more than ctbankix. It´s much more light weight, boot faster, and the idea of copy2ram ensures after removing the usb flash drive makes sure no malware can touch your Porteus settings and you will have a fresh version next time. The only remaining Achilles heel is the access to internal hard drive. Thank you for the detailed advice. I will try to build the kernel myself. There is a hint given by the author of ctbankix how to do it for Ubuntu here
https://www.heise.de/forum/c-t/Kommenta ... 7862/show/.
It is just a one-line change when building the kernel:

Code: Select all

--- linux-2.6.28/include/linux/libata.h 2008-12-25 00:26:37.000000000 +0100
+++ linux-2.6.28/include/linux/libata.h 2009-08-05 17:43:25.000000000 +0200
@@ -1257,7 +1257,7 @@

 static inline unsigned int ata_dev_enabled(const struct ata_device *dev)
 {
-       return ata_class_enabled(dev->class);
+       return dev->class == ATA_DEV_ATAPI; /* optical drives only (mid) */
 }
 static inline unsigned int ata_dev_disabled(const struct ata_device *dev)
I have no idea whether this will work for Slackware.

Cheers.
using CINNAMON-v4.0-x86_64 with updated kernel porteus-4.16.8

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: prevent access to internal harddisk of the PC

Post#5 by Rava » 08 Feb 2019, 17:45

user0815 wrote:
08 Feb 2019, 16:45
I have no idea whether this will work for Slackware.
Kernel patching is independent when it comes to the distribution. This

Code: Select all

--- linux-2.6.28/include/linux/libata.h 2008-12-25 00:26:37.000000000 +0100
+++ linux-2.6.28/include/linux/libata.h 2009-08-05 17:43:25.000000000 +0200
@@ -1257,7 +1257,7 @@

 static inline unsigned int ata_dev_enabled(const struct ata_device *dev)
 {
-       return ata_class_enabled(dev->class);
+       return dev->class == ATA_DEV_ATAPI; /* optical drives only (mid) */
 }
 static inline unsigned int ata_dev_disabled(const struct ata_device *dev)
looks like a diff to me. And it heavily depends on the source code of the kernel you try to patch. It is done here for linux-2.6.28/include/linux/libata.h which is a quite outdated kernel.

But you could, instead of applying the diff directly, just replace

Code: Select all

return ata_class_enabled(dev->class);
with

Code: Select all

return dev->class == ATA_DEV_ATAPI; /* optical drives only (mid) */
When the recent code has something else instead of

Code: Select all

return ata_class_enabled(dev->class);
patching the kernel is not that easy. Remember, recent stable kernel is 4.20.7, that is a long way from 2.6.28.
Cheers!
Yours Rava

User avatar
user0815
Black ninja
Black ninja
Posts: 63
Joined: 22 Jan 2019, 11:46
Distribution: CINNAMON-v4.0-x86_64

prevent access to internal harddisk of the PC

Post#6 by user0815 » 02 Mar 2019, 17:01

Dear All,
Sorry it takes so long that it looks like this thread is dead. Finally, I found a much easier way. I was studying the cheatcodes.txt which is attached to porteus iso. In the final note there is a hint that there are more info on kernel.org/doc/Documentation/kernel-parameters.txt, this link is dead, however, I found the new one under https://www.kernel.org/doc/html/v4.14/a ... eters.html that mentions libata.force. After looking around to find the correct syntax to disable internal hard disk, I found this https://askubuntu.com/questions/554398/ ... ard-drives

For those interested in and have same security need as I do, you need to find out the ATA address, which is a number by using

Code: Select all

dmesg | grep ata
, then use

Code: Select all

libata.force=XX.00:disable
as cheatcode in your porteus.cfg (XX=ATA number). For me, the ATA no. is 3, and it is now disabled as below, no access is possible, even gparted cannot see it.

Code: Select all

guest@porteus:~$ dmesg | grep ata
[    0.000000] Command line: libata.force=3.00:disable from=UUID:e15c7603-2c74-4ff8-a7d3-59bc764d2d18 changes=UUID:e15c7603-2c74-4ff8-a7d3-59bc764d2d18/profiles/xfce load=003-xfce;firefox initrd=/boot/syslinux/initrd.xz BOOT_IMAGE=/boot/syslinux/vmlinuz 
[    0.000000] BIOS-e820: [mem 0x00000000ab6ec000-0x00000000ab739fff] ACPI data
[    0.000000] ACPI: SSDT 0x00000000AB72CE88 00046D (v01 SataRe SataTabl 00001000 INTL 20120913)
[    0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xb2 (or later)
[    0.000000] Kernel command line: quiet libata.force=3.00:disable from=UUID:e15c7603-2c74-4ff8-a7d3-59bc764d2d18 changes=UUID:e15c7603-2c74-4ff8-a7d3-59bc764d2d18/profiles/xfce load=003-xfce;firefox initrd=/boot/syslinux/initrd.xz BOOT_IMAGE=/boot/syslinux/vmlinuz 
[    0.000000] Memory: 7833712K/8044680K available (8204K kernel code, 669K rwdata, 1744K rodata, 976K init, 412K bss, 210968K reserved, 0K cma-reserved)
[    0.130119] libata version 3.00 loaded.
[    0.281435] ata1: SATA max UDMA/133 abar m2048@0xe1253000 port 0xe1253100 irq 124
[    0.281437] ata2: SATA max UDMA/133 abar m2048@0xe1253000 port 0xe1253180 irq 124
[    0.281439] ata3: SATA max UDMA/133 abar m2048@0xe1253000 port 0xe1253200 irq 124
[    0.303017] usbcore: registered new interface driver ums-datafab
[    0.592114] ata1: SATA link down (SStatus 4 SControl 300)
[    0.903192] ata2: SATA link down (SStatus 0 SControl 300)
[    1.215683] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.216652] ata3.00: FORCE: horkage modified (disable)
[    1.216656] ata3.00: unsupported device, disabling
[    1.216659] ata3.00: disabled
[    1.219251] Write protecting the kernel read-only data: 12288k
[    1.222439] rodata_test: all tests were successful
[    2.299412] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[    3.763224] wmi_bus wmi_bus-PNP0C14:00: WQBC data block query control method not found
[    3.850656] cfg80211: Loading compiled-in X.509 certificates for regulatory database
using CINNAMON-v4.0-x86_64 with updated kernel porteus-4.16.8

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: prevent access to internal harddisk of the PC

Post#7 by Rava » 19 Mar 2019, 07:20

Thanks user0815 for the heads up.
I have no Porteus capable PC with me - just my Android smartphone but plan on checking your technique out as soon as I have access to a Porteus PC. :)
Cheers!
Yours Rava

Kerosene
Ronin
Ronin
Posts: 1
Joined: 19 Mar 2024, 09:04
Distribution: Porteus-MATE-v5.01-x86_64

Prevent access to internal harddisk of the PC [SOLVED]

Post#8 by Kerosene » 19 Mar 2024, 09:26

Although it's an old thread, I signed up just to thank user0815 for this info. It took me 3 days to find it.
I think it should be added to a FAQ. I was about to give up on Linux yet again, but this solution has turned me around.

I tried just about everything to disable my internal drives while running from USB.
UUID stuff, nohd, noauto. etc etc. None of it worked.

This was all I needed:

Find the ATA numbers for my internal drives using:

Code: Select all

dmesg | grep ata
And then disable the drives in porteus.cfg:

Code: Select all

APPEND libata.force=1.00:disable,5.00:disable
I have tried endless distros over the last 10-15 years, and have never lasted more than a week.
Porteus is the only one that I am genuinely enjoying and can see myself using on a daily basis. Good work everyone!

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Prevent access to internal harddisk of the PC [SOLVED]

Post#9 by Ed_P » 19 Mar 2024, 16:03

Thank you Kerosene. :)

It might be helpful to other users if you could post the output of your dmesg | grep command so they can understand what to look for. It can also be noted that the dmesg command needs to be run as root.

Added in 4 hours 30 minutes 47 seconds:
In my old notebook I have a single harddrive. This is what I see:

Code: Select all

root@porteus:/home/guest# dmesg|grep " ata"
[    0.310449] ata1: SATA max UDMA/133 abar m2048@0xd1133000 port 0xd1133100 irq 123
[    0.310453] ata2: SATA max UDMA/133 abar m2048@0xd1133000 port 0xd1133180 irq 123
[    0.617387] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    0.617855] ata1.00: supports DRM functions and may not be fully accessible
[    0.617863] ata1.00: ATA-11: Samsung SSD 860 EVO 1TB, RVT04B6Q, max UDMA/133
[    0.618518] ata1.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    0.621443] ata1.00: Features: Trust Dev-Sleep NCQ-sndrcv
[    0.622077] ata1.00: supports DRM functions and may not be fully accessible
[    0.625744] ata1.00: configured for UDMA/133
[    0.628384] ata1.00: Enabling discard_zeroes_data
[    0.629840] ata1.00: Enabling discard_zeroes_data
[    0.936877] ata2: SATA link down (SStatus 4 SControl 300)
How do I know which ata represents my hardrive? And what does the other ata represent? :hmmm:

Added in 29 minutes 52 seconds:
On my current notebook I have a single drive also and this is what I see:

Code: Select all

root@porteus:/home/guest# dmesg | grep ata
[    0.000000] BIOS-e820: [mem 0x0000000064d72000-0x0000000064ffefff] ACPI data
[    0.044463] Memory: 7810228K/8125220K available (18432K kernel code, 1203K rwdata, 5000K rodata, 2384K init, 1932K bss, 314736K reserved, 0K cma-reserved)
[    0.303415] libata version 3.00 loaded.
[    0.458777] usbcore: registered new interface driver ums-datafab
[    0.522250] Write protecting the kernel read-only data: 24576k
[    0.522582] Freeing unused kernel image (rodata/data gap) memory: 1144K
[    3.936180] wmi_bus wmi_bus-PNP0C14:02: WQBC data block query control method not found
[    3.976342] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    9.600045] iwlwifi 0000:00:14.3: 0x00005E04 | data1
[    9.600045] iwlwifi 0000:00:14.3: 0x00001000 | data2
[    9.600046] iwlwifi 0000:00:14.3: 0x00000000 | data3
[    9.600098] iwlwifi 0000:00:14.3: 0x00000063 | umac data1
[    9.600099] iwlwifi 0000:00:14.3: 0xDEADBEEF | umac data2
[    9.600099] iwlwifi 0000:00:14.3: 0xDEADBEEF | umac data3
[    9.600133] iwlwifi 0000:00:14.3: 0x00005863 | IML/ROM data1
[    9.600349] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[ 3184.253918] iwlwifi 0000:00:14.3: 0x00005E04 | data1
[ 3184.253919] iwlwifi 0000:00:14.3: 0x00001000 | data2
[ 3184.253921] iwlwifi 0000:00:14.3: 0x00000000 | data3
[ 3184.254455] iwlwifi 0000:00:14.3: 0x00000063 | umac data1
[ 3184.254457] iwlwifi 0000:00:14.3: 0xDEADBEEF | umac data2
[ 3184.254458] iwlwifi 0000:00:14.3: 0xDEADBEEF | umac data3
[ 3184.254604] iwlwifi 0000:00:14.3: 0x0000592C | IML/ROM data1
[ 3184.257039] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
root@porteus:/home/guest# 
No atas found. So what would I use?
Ed

Post Reply