| 1 |
>> |
| 2 |
>> |
| 3 |
>>-----Original Message----- |
| 4 |
>>From: Rich Freeman <rich0@g.o> |
| 5 |
>>Sent: Sunday, March 20, 2022 11:03 AM |
| 6 |
>>To: gentoo-user@l.g.o |
| 7 |
>>Subject: Re: [gentoo-user] KDE, sddm etc security. Plus LVM question. |
| 8 |
>> |
| 9 |
>>On Sun, Mar 20, 2022 at 12:05 PM Daniel Frey <djqfrey@×××××.com> wrote: |
| 10 |
>>> |
| 11 |
>>> They don't even need to defeat a password. If they have root, it's |
| 12 |
>>> trivial to unlock a locked session without knowing the password - just FYI. |
| 13 |
>>> ... |
| 14 |
>>> The screen locks in linux are security by obscurity, if something is |
| 15 |
>>> that sensitive, don't stay logged in all the time. |
| 16 |
>> |
| 17 |
>>If somebody has root access to your box, then they are going to be able to get at your data. They don't have to unlock your session to do it - they have access to the memory of all your processes, everything on disk, and so on. If you're using encryption at the account level and it is well-implemented then root probably can't get at your data while you aren't logged in, but they certainly can get it the next time you log in. |
| 18 |
>> |
| 19 |
>>It is true though that linux screensavers are often not well-implemented. Honestly, I'm not sure if any of them are - it seems to be more of an afterthought in the design layered on top. I haven't made a study of them, so maybe there are some which are, but something like this really needs to be designed into the system to be secure, and some of that needs to be treated as security-critical code. |
| 20 |
>> |
| 21 |
>>Now, if you want to make an argument for leaving systems powered down except when needed if they contain sensitive data that would certainly reduce the opportunity for intrusion, but you still need the OS to keep people from gaining root in the first place. |
| 22 |
>> |
| 23 |
>>As others have mentioned at the start of the thread, if you're concerned with physical security then full disk encryption (or at least encryption of data combined with airtight authentication of the |
| 24 |
>>OS) has to be part of the solution. In 99% of linux-based solutions that requires entering a password at boot. In theory the linux kernel has support for TPM verified boot, so you could implement something like Bitlocker/etc on Linux, but I'm not aware of any distros that have done so (unless you want to count something like ChromeOS). For a desktop system a boot password isn't as much of a problem, but if you want an unattended server to be able to boot on power restoration then a TPM-based solution would be better. It certainly is prettier on the desktop, and allows for more recovery options, which is why just about all corporate laptops I've seen do it this way. Of course without a boot password you're only as secure as your OS, as any attacker can still boot the OS and attack it while it is running, which they can't do if the disk requires a password to decrypt it. |
| 25 |
>> |
| 26 |
>>If you're running Windows on a system with a TPM the simplest solution to all this stuff is to turn on Bitlocker, though this is not available on the Home edition of Win10. |
| 27 |
>> |
| 28 |
>>-- |
| 29 |
>>Rich |
| 30 |
>> |
| 31 |
>> |
| 32 |
|
| 33 |
There was the ORWL project a few years ago. Self-encrypting SSD drive with a TPM that would unlock it only in the presence of an encrypted RFID tag plus tapping in a code on the keypad, with all the sensitive bits wrapped in an active mesh system that would destroy the data if it detected any tampering.
|
| 34 |
|
| 35 |
Plus it could be set to lock down if the accelerometer went off, or after inactivity, which would disable whatever set of external ports was set.
|
| 36 |
|
| 37 |
Don't seem to be made any more, which is a pity. But the design was getting to be a bit dated. Schematics are theoretically still available somewhere if you want to build one.
|
| 38 |
|
| 39 |
LMP |
Archives