Howdy,

I been thinking.  Yea, that's dangerous.  lol  If I logout of KDE, or
have the screen locked, ctrl+alt=L key sequence, how secure is that if I
have good passwords that are virtually impossible to crack?  My login
manager is sddm.  As a example, if someone breaks into my home, is there
a easy way to get past that?  I recall the old windoze 98 days where a
certain key sequence would bypass the password prompt.  Is there a way
known to crooks and such that can bypass or easily defeat passwords? 

I'm aware that if a person boots up where no password is required, that
will bypass, even as root if I recall correctly.  I'm just looking for something that is even easier than that. 

Also, if I have a encrypted hard drive open and mounted and then cut off
power, doesn't that disable the decryption for the drive?  In other
words, I pull the plug and someone powers it back up, the drive is
encrypted again and requires a password. 

Also, I'm planning to reorganize and encrypt some more stuff here.  I
want to remove one hard drive from my home thingy.  Is it really as easy
as pvmove /dev/sdx the device I want to remove?  From my understanding I
need to reduce the file system first.  Is that correct?  I'm often
amazed at how easy some things can be done with LVM. 

Thanks to all for the thoughts.

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-03-19 03:03, Dale wrote:

I been thinking.� Yea, that's dangerous.� lol� If I logout of KDE, or
have the screen locked, ctrl+alt=L key sequence, how secure is that if I
have good passwords that are virtually impossible to crack?� My login
manager is sddm.� As a example, if someone breaks into my home, is there
a easy way to get past that?� I recall the old windoze 98 days where a certain key sequence would bypass the password prompt.� Is there a way
known to crooks and such that can bypass or easily defeat passwords?�

The only secure lockscreen is XScreenSaver. https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/03/2022 08:03, Dale wrote:

Howdy,

I been thinking.  Yea, that's dangerous.  lol  If I logout of KDE, or
have the screen locked, ctrl+alt=L key sequence, how secure is that if I
have good passwords that are virtually impossible to crack?  My login manager is sddm.  As a example, if someone breaks into my home, is there
a easy way to get past that?  I recall the old windoze 98 days where a certain key sequence would bypass the password prompt.  Is there a way
known to crooks and such that can bypass or easily defeat passwords?

I'm not aware of any such shortcuts. There are always bugs, and design
flaws, and I believe there is such a design flaw in X such that it's
POSSIBLE to bypass a screen-lock.

I'm aware that if a person boots up where no password is required, that
will bypass, even as root if I recall correctly.  I'm just looking for something that is even easier than that.

Actually, systemd is actively working on closing that hole ...

Also, if I have a encrypted hard drive open and mounted and then cut off power, doesn't that disable the decryption for the drive?  In other
words, I pull the plug and someone powers it back up, the drive is
encrypted again and requires a password.

Yes. If you even so much as SUSPEND your system, it's considered a
serious bug for the encryption key to be flushed to disk - it has to be
wiped - and with no key decryption is no longer possible.

Also, I'm planning to reorganize and encrypt some more stuff here.  I
want to remove one hard drive from my home thingy.  Is it really as easy
as pvmove /dev/sdx the device I want to remove?  From my understanding I need to reduce the file system first.  Is that correct?  I'm often
amazed at how easy some things can be done with LVM.

I think you mean pvREmove and, provided you have sufficient unused space
in your PV greater or equal to the size of the drive, yes it really is
that simple. Of course, if you have LESS free space, LVM will be unable
to move everything off sdx and you're going to lose data.

If you're planning to re-organise by adding larger disks, check out
whether LVM has the equivalent of "mdadm --replace ...", where md-raid
will move stuff on a running system.

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anna “CyberTailor” wrote:

On 2022-03-19 03:03, Dale wrote:

I been thinking.  Yea, that's dangerous.  lol  If I logout of KDE, or
have the screen locked, ctrl+alt=L key sequence, how secure is that if I
have good passwords that are virtually impossible to crack?  My login
manager is sddm.  As a example, if someone breaks into my home, is there
a easy way to get past that?  I recall the old windoze 98 days where a
certain key sequence would bypass the password prompt.  Is there a way
known to crooks and such that can bypass or easily defeat passwords? 

The only secure lockscreen is XScreenSaver. https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

I have that installed here.  Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver. 
From my poking around, I don't think I'm using xscreensaver.  I'm trying
to figure out how that works so I can get it to be used with KDE and any
other GUI I use.  Being able to use ctrl+alt=L would be a nice bonus. 

Thanks for that info.  It gets me started. 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anna “CyberTailor” wrote:

On 2022-03-19 06:08, Dale wrote:

Anna “CyberTailor” wrote:

The only secure lockscreen is XScreenSaver.
https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

I have that installed here.  Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver. 
From my poking around, I don't think I'm using xscreensaver.  I'm trying
to figure out how that works so I can get it to be used with KDE and any
other GUI I use.  Being able to use ctrl+alt=L would be a nice bonus. 

Add a custom keybinding for Ctrl+Alt+L so it executes:

xscreensaver-command --lock

I found a guide, it's in the man page to, here:

https://www.jwz.org/xscreensaver/man1.html

I scrolled down to the KDE bits and at points it got interesting because
KDE moves files around.  Anyway, he pointed to files that are installed
by emerge which gets changed on update.  He even admitted it would.  So,
I found the file in /home/dale/.config/kscreenlockerrc and I copied the original file in case I need to go back.  That shouldn't be affected by updates. 

Everything else was fine in the instructions.  I'm in the middle of
stuff right now so I'll test it out later.  I'll also need to research
that keyboard shortcut.  I remember seeing it in system settings
somewhere.  I think I changed a couple ages ago and it was pretty
straight foreword. 

Thanks for the info. 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wols Lists wrote:

On 19/03/2022 11:08, Dale wrote:

I have that installed here.  Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver.
 From my poking around, I don't think I'm using xscreensaver.  I'm
trying
to figure out how that works so I can get it to be used with KDE and any
other GUI I use.  Being able to use ctrl+alt=L would be a nice bonus.

Try "Windows"-L. It works on my gentoo system here ...

Cheers,
Wol

.

Doesn't work here.  I do have that key on my keyboard tho.  Don't recall
ever using it tho.  May do something.  lol

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/03/2022 11:08, Dale wrote:

I have that installed here.  Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver.
From my poking around, I don't think I'm using xscreensaver.  I'm trying
to figure out how that works so I can get it to be used with KDE and any other GUI I use.  Being able to use ctrl+alt=L would be a nice bonus.

Try "Windows"-L. It works on my gentoo system here ...

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-03-19 06:08, Dale wrote:

Anna “CyberTailor” wrote:

The only secure lockscreen is XScreenSaver. https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

I have that installed here.  Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver. 
From my poking around, I don't think I'm using xscreensaver.  I'm trying
to figure out how that works so I can get it to be used with KDE and any other GUI I use.  Being able to use ctrl+alt=L would be a nice bonus. 

Add a custom keybinding for Ctrl+Alt+L so it executes:

xscreensaver-command --lock

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wols Lists wrote:

On 19/03/2022 08:03, Dale wrote:

Howdy,

I been thinking.  Yea, that's dangerous.  lol  If I logout of KDE, or
have the screen locked, ctrl+alt=L key sequence, how secure is that if I
have good passwords that are virtually impossible to crack?  My login
manager is sddm.  As a example, if someone breaks into my home, is there
a easy way to get past that?  I recall the old windoze 98 days where a
certain key sequence would bypass the password prompt.  Is there a way
known to crooks and such that can bypass or easily defeat passwords?

I'm not aware of any such shortcuts. There are always bugs, and design
flaws, and I believe there is such a design flaw in X such that it's
POSSIBLE to bypass a screen-lock.

Well, I'm working on replacing this with xscreensaver.  Sounds like it
locks and means it.  ;-)

I'm aware that if a person boots up where no password is required, that
will bypass, even as root if I recall correctly.  I'm just looking for
something that is even easier than that.

Actually, systemd is actively working on closing that hole ...

I'm using openrc here.  Hmmmm. 

Also, if I have a encrypted hard drive open and mounted and then cut off
power, doesn't that disable the decryption for the drive?  In other
words, I pull the plug and someone powers it back up, the drive is
encrypted again and requires a password.

Yes. If you even so much as SUSPEND your system, it's considered a
serious bug for the encryption key to be flushed to disk - it has to
be wiped - and with no key decryption is no longer possible.

OK.  If the system is shutdown or plug pulled, hard drive locks up and requires the password to decrypt.  Sounds good.  I was fairly sure it
would since it no longer has the device node that is decrypted. 

Also, I'm planning to reorganize and encrypt some more stuff here.  I
want to remove one hard drive from my home thingy.  Is it really as easy
as pvmove /dev/sdx the device I want to remove?  From my understanding I
need to reduce the file system first.  Is that correct?  I'm often
amazed at how easy some things can be done with LVM.

I think you mean pvREmove and, provided you have sufficient unused
space in your PV greater or equal to the size of the drive, yes it
really is that simple. Of course, if you have LESS free space, LVM
will be unable to move everything off sdx and you're going to lose data.

If you're planning to re-organise by adding larger disks, check out
whether LVM has the equivalent of "mdadm --replace ...", where md-raid
will move stuff on a running system.

Cheers,
Wol

The guide I'm looking at shows pvmove.  This is what I'm looking at:

https://tldp.org/HOWTO/html_single/LVM-HOWTO/#RemoveADisk

If it doesn't scroll to it, it's section 13.5 Removing old disk.  It says:

pvmove /dev/hdb

That's for old IDE but I guess it is the same for sd* drives.  Maybe I'm looking at the wrong section?  Sounds pretty easy.  It doesn't even
mention reducing the file system there but it does in another section. 
So, I assume I'd need to reduce the file system first, run that command
and the next section's command to remove the drive itself and that's it. 

I'm moving to encrypting some directories.  To do that, I need a empty
drive first to put encryption on.  Then I can encrypt, move stuff that
isn't encrypted then add drives back until everything that I want is encrypted.  I'm assuming I can have one large logical volume that is
encrypted across more than one drive.  Right now, I have 3 drives for
/home.  I got space to remove one and then start encrypting and adding
other drives to the encrypted stuff. 

I wish it was to where my user password could do this as I login/unlock
screen etc.  Thing is, I have things running that need to access the
drives even when the screen is locked.  I don't think what I want is
even possible there. 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 19 March 2022 12:33:16 GMT Anna “CyberTailor” wrote:

On 2022-03-19 06:08, Dale wrote:

Anna “CyberTailor” wrote:

The only secure lockscreen is XScreenSaver. https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

I have that installed here. Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver.
From my poking around, I don't think I'm using xscreensaver. I'm trying
to figure out how that works so I can get it to be used with KDE and any other GUI I use. Being able to use ctrl+alt=L would be a nice bonus.

Add a custom keybinding for Ctrl+Alt+L Ctrl+Alt+Lso it executes:

xscreensaver-command --lock

Ctrl+Alt+L locks the screen here, after logging in to Plasma via SDDM. I didn't set that myself, so it seems to be a default value.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Peter Humphrey wrote:

On Saturday, 19 March 2022 12:33:16 GMT Anna “CyberTailor” wrote:

On 2022-03-19 06:08, Dale wrote:

Anna “CyberTailor” wrote:

The only secure lockscreen is XScreenSaver.
https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

I have that installed here. Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver.
From my poking around, I don't think I'm using xscreensaver. I'm trying >>> to figure out how that works so I can get it to be used with KDE and any >>> other GUI I use. Being able to use ctrl+alt=L would be a nice bonus.

Add a custom keybinding for Ctrl+Alt+L Ctrl+Alt+Lso it executes:

xscreensaver-command --lock

Ctrl+Alt+L locks the screen here, after logging in to Plasma via SDDM. I didn't set that myself, so it seems to be a default value.

I think when I logout and back in, it may work better.  I put in a
config file in KDE autostart and when I want to lock the screen, it
triggers xscreensaver instead of the usual KDE lock screen.  That's the
theory anyway.  I just finished my updates so I should be able to test
in a bit. 

The only downside, it activates the screensaver and locks the screen
when I'm watching videos right now.  That may change when I logout and
back in to but right now, I had to stop xscreensaver.  I tend to leave
the screen saver turned off anyway and just lock the screen when I want
it to power off the monitor etc. 

We'll know in a bit.  I'll post updates in case someone else here wants
to switch or googles up this thread. 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/03/2022 13:20, Dale wrote:

I'm moving to encrypting some directories.  To do that, I need a empty
drive first to put encryption on.  Then I can encrypt, move stuff that
isn't encrypted then add drives back until everything that I want is encrypted.  I'm assuming I can have one large logical volume that is encrypted across more than one drive.  Right now, I have 3 drives for /home.  I got space to remove one and then start encrypting and adding
other drives to the encrypted stuff.

I've got dm-integrity running over my bare partition. I guess you could
use dm-security/luks. No reason why not.

Then I use raid-5 over that to combine 3 3TB partitions into a 6TB
device. Which has lvm on that. And then I have my other partitions
(basically just /home) on top of that.

So if I need more space I just add a new drive with dm-integrity, add
that into my raid, and grow the raid, lvm, and my /home ...

"simples", as the meerkats say ...

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dale wrote:

Peter Humphrey wrote:

On Saturday, 19 March 2022 12:33:16 GMT Anna “CyberTailor” wrote:

On 2022-03-19 06:08, Dale wrote:

Anna “CyberTailor” wrote:

The only secure lockscreen is XScreenSaver.
https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

I have that installed here. Question now is, is that what locks my
screen or is KDE/sddm/something else doing that besides xscreensaver.
From my poking around, I don't think I'm using xscreensaver. I'm trying >>>> to figure out how that works so I can get it to be used with KDE and any >>>> other GUI I use. Being able to use ctrl+alt=L would be a nice bonus.

Add a custom keybinding for Ctrl+Alt+L Ctrl+Alt+Lso it executes:

xscreensaver-command --lock

Ctrl+Alt+L locks the screen here, after logging in to Plasma via SDDM. I
didn't set that myself, so it seems to be a default value.

I think when I logout and back in, it may work better.  I put in a
config file in KDE autostart and when I want to lock the screen, it
triggers xscreensaver instead of the usual KDE lock screen.  That's the theory anyway.  I just finished my updates so I should be able to test
in a bit. 

The only downside, it activates the screensaver and locks the screen
when I'm watching videos right now.  That may change when I logout and
back in to but right now, I had to stop xscreensaver.  I tend to leave
the screen saver turned off anyway and just lock the screen when I want
it to power off the monitor etc. 

We'll know in a bit.  I'll post updates in case someone else here wants
to switch or googles up this thread. 

Dale

:-)  :-) 

OK.  This isn't going well.  It still goes into screen saver even tho I
have it disabled completely in settings and does it after one minute
even with smplayer actively playing a video.  That's not going to work
for me at all.  Big time problem.  Basically, all I want is to lock the screen when I tell it to lock.  That's it. 

Another issue, ctrl+alt+L doesn't trigger xscreensaver but still
triggers KDE's screen saver.  It can likely be fixed but the problem
above has to be fixed first. 

At the moment, I've taken xscreensaver out of the loop.  Got some other
stuff to deal with at the moment anyway. Got a new fishing rod and
reel.  :-D

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Mar 19, 2022 at 1:50 PM Dale <rdalek1967@gmail.com> wrote:
<SNIP>

Another issue, ctrl+alt+L doesn't trigger xscreensaver but still
triggers KDE's screen saver. It can likely be fixed but the problem
above has to be fixed first.

<SNIP>

System Settings -> Workspace Behavior -> Screen Locking ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-03-19 01:03, Dale wrote:

Howdy,

I been thinking.  Yea, that's dangerous.  lol  If I logout of KDE, or
have the screen locked, ctrl+alt=L key sequence, how secure is that if I
have good passwords that are virtually impossible to crack?  My login manager is sddm.  As a example, if someone breaks into my home, is there
a easy way to get past that?  I recall the old windoze 98 days where a certain key sequence would bypass the password prompt.  Is there a way
known to crooks and such that can bypass or easily defeat passwords?

They don't even need to defeat a password. If they have root, it's
trivial to unlock a locked session without knowing the password - just FYI.

I had to use that method when compiling updates and the screen saver
broke, and yes it did work. I can't recall what the command was now -
but I did test it on a working-normally system and it worked as well.

The screen locks in linux are security by obscurity, if something is
that sensitive, don't stay logged in all the time.

Dan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Mar 20, 2022 at 12:05 PM Daniel Frey <djqfrey@gmail.com> wrote:

They don't even need to defeat a password. If they have root, it's
trivial to unlock a locked session without knowing the password - just FYI. ...
The screen locks in linux are security by obscurity, if something is
that sensitive, don't stay logged in all the time.

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.

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.

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.

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
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.

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.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 21, 2022 at 12:17 PM Laurence Perkins <lperkins@openeye.net> wrote:

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.

While I can see this being useful if for some reason you don't have
support for encryption on the software side, something like this seems
like it wouldn't actually solve the unattended boot problem, since you
have to enter a PIN. If you don't require the PIN and leave the RFID
tag sitting next to the drive all the time, then anybody can walk in
and take the drive and the tag and then read the data off the drive
bypassing the OS. So it offers at best the same protection as a LUKS passphrase entered at boot, and at worst no protection at all. It
would have the advantage that you wouldn't be able to attack the
passphrase itself as no doubt the PIN only offers limited attempts and
would be very difficult to bypass.

The advantage of the TPM in the computer is that you can do unattended
verified boot, so the disk can only be decrypted if the OS boots
normally without tampering. Obviously you're still open to OS
vulnerabilities, but the drive itself cannot be accessed except via
the OS. The TPM chip can actually supervise the boot process.

Still an interesting product though. I could see it being useful if
you had to run some specific OS that doesn't support disk encryption
natively.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 21, 2022 at 2:30 PM Laurence Perkins <lperkins@openeye.net> wrote:

Having it remain unlocked and capable of rebooting unless the accelerometer showed movement I think was an option since the TPM kept monitoring even if the mains power was interrupted.

Yeah, there might still be ways to accomplish it with features like this.

Could probably do something similar these days with one of those $3 bluepill boards and one of those new 3d printers capable of embedding metal though.

Or you could just use the TPM that is probably already in your computer... :)

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 21, 2022 at 8:03 PM Laurence Perkins <lperkins@openeye.net> wrote:

The TPM in most computers doesn't dump the keys if someone tries to open the case to install hardware sniffers.

That's a good point, though if somebody with the ability to sniff the
RAM or (to a lesser degree) GPU traffic is after you, then you
probably want to be on the lookout for rubber hose decryption.

If you're a big spender the AMD Secure Memory Encryption feature would
probably help there, assuming they ever get it working on Linux.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)