Copy&Paste from Gitlab: ****** I want to share with us an issue I have found with my users experience. I am one of the developers of LliureX, a Neon based distribution used by public schools in Valencia, Spain. We have been using ethernet based classrooms since now. Covid-19 event has changed that, well, politicians. Now classrooms are based on laptops connected to WiFi, with either a common password (classic WPA) or enterprise one, where each student has its own user/password. Thing is, wifi passwords can be seen on plain text easily. So once a student sets up his WPA Enterprise connection, it is two clicks distance from seen his credentials in plain text. Even QR codes can be generated with that. Yes, I am aware that no desktop should be left untended without locking, but we are talking about kids or even teachers, with no IT security training at all. Once credentials are stolen, they can use them to impersonate another user and try to access some probably forbidden pages, or even access to cloud services, as credential is shared. I know this is a bit ill-designed from Wireless standard, where no one found important to keep a password secret, but, would be possible to add an extra step in order to show the password? Perhaps, unlocking with login password. ****** Nate asked me on Gitlab how students log in into desktop. Students should log in using their own (private) credentials. Now are ldap backed because laptops are shared between students (we are far from a 1:1 student/laptop ratio), but if a student needs a computer at home, I see no problem with classic local unix accounts. There are some schools using auto-login or some sort of well known user (ie: foo/bar) but of course we advise against this model for obvious security and privacy reasons. I have written this because Aleix asked me to do it. I think it is not Plasma fault here, because hiding passwords on plasma-nm won't stop some smart kid to open a terminal and type: nmcli connection show foo --show-secrets My point is to show that perhaps, we have designed Linux desktops with a safe home environment in mind and we have to spend some time thinking on "hostile" environments. Thank you guys in advance for give me some place to talk about this :D
The use case seems legitimate for this to be an issue. The thing is, ultimately the way a computer is designed to withstand a potentially hostile environment is with the screen locker used aggressively. Like, with a one-minute timeout or something. Because it's going to be next to impossible to secure a local machine against local attacks when the screen is unlocked. You can also train your students to lock the screen when they leave the machine, either with Meta+L or perhaps by putting a Lock/logout widget on their panels, pre-configured to only have the Lock action visible by default. That way it's just one click on something big and obvious to lock the screen. Another question: Do your students have Standard accounts or Administrator accounts?
(In reply to Nate Graham from comment #1) > The use case seems legitimate for this to be an issue. > > The thing is, ultimately the way a computer is designed to withstand a > potentially hostile environment is with the screen locker used aggressively. > Like, with a one-minute timeout or something. Because it's going to be next > to impossible to secure a local machine against local attacks when the > screen is unlocked. You can also train your students to lock the screen when > they leave the machine, either with Meta+L or perhaps by putting a > Lock/logout widget on their panels, pre-configured to only have the Lock > action visible by default. That way it's just one click on something big and > obvious to lock the screen. Of course we encourage both teachers and students to lock screen whenever they leave. Also, LliureX always comes with default inactivity lock screen settings. I would like to be more aggressive here with a single minute of inactivity for locking but teachers already complain about that, so for the moment, we are trying to teach them about the risks rather than enforce them. Thing is, if you leave a linux desktop unattended an attacker will never get your unix password by any means, even with root privileges he will only get a hash. That's true even for email or cloud services, where the "only" thing he would achieve is a password reset. WiFi seems against this philosophy :\ > Another question: Do your students have Standard accounts or Administrator > accounts? No, neither students nor teachers accounts have administration privileges. We have the role of classroom administrator, the only one inside sudoers. Teachers are allowed for some tasks that students aren't but nothing critical. Using system wide NM connections and policy kit rules, users can connect to WiFi but can not see password. Password is stored on plain text on /etc, but at least is root protected. Not great, but good enough for me. We are using this trick to hide student credentials from snoopers.
Maybe for standard user accounts, we could require entering the user's password to show the password of the current wifi network?
(In reply to Nate Graham from comment #3) > Maybe for standard user accounts, we could require entering the user's > password to show the password of the current wifi network? It sounds good to me. However, would be easily accessible from nmcli/dbus. That's why I thought it is not a specific Plasma bug.
Bulk transfer as requested in T17796