Prevent Students changing settings ....especially Network

Support
1

We have a school computer lab currently running almost exclusively Manjaro and need a way to lock machines just a little to prevent students changing all the settings around on a whim.
This is especially critical for network choices and passwords.

What I have observed is that my daily driver LMDE, prevents non-root/non-admin accounts from even accessing the network settings out of the box. Once a wifi setup under the root/admin is made available to all users but they can not even attempt to see network settings ( say to a hotspot run by a student to bypass mandatory school filters).

Manjaro as it is out-of-the-box lets “standard” users see and change all the network settings and passwords… the password isn’t even locked …it can be revealed easily by anyone and all manner of other changes can be made.

I have used sudo gpasswd -d ####username### network …to remove the student account on the machines from network access… it says it is successful but all it seems to do is purge a wallet entry and stop the wifi working…demanding the password entry again and making it obviously visible.

Is there an intermediate option to ADD the option for an encrypted password for wifi for all users … not just the local-only encrypted per user option or the “store password for all users (not encrypted)” option in wifi settings?

Is there a more general way to prevent all settings like the background and USB mounting and many others from being reached at all by students which would also accomplish this more specific network concern and take care of a few other loose threads.

I’m OK with the answer being no … that not the Arch way…and I will just put LMDE on all of the machines and keep going, it’s just that Arch is so much better and I am changing my own LMDE to be daily driver over to Manjaro, I’m so impressed with how it handles all our Arduino and ESP32 programming, 3d printer slicing with Orca, video editing in Kdenlive etc… that I kinda hate to switch to another distro just because I can’t seem to get the same school-necessary user level access control.

If this one thing can be sorted out, I think there is huge potential for Manjaro in educational spaces at a lot of schools who have lab computers that need to run a few modern tools, but are completely blocked from any all updates on their OEM operating systems.

2

I might suggest creating a non-privileged account.

ex;
To check your defaults for useradd;

useradd --defaults

To create the user and its home directory using those defaults;

sudo useradd -m student

You may wish to create a password as well

sudo passwd student

Depending on your configuration this should be a relatively useless account.
On my system this new user is created as part of no groups except its own.
That means it has no sudo access, is not part of the wheel or network groups, etc.

Please let us know if this would accomplish your task.

For more information, including possibly some groups you may wish to add the user to

https://wiki.archlinux.org/title/Users_and_groups

Also security and stuff that will include things like restricting root

https://wiki.archlinux.org/title/Security

PS.
We dont know anything about your desktop and all … this may affect the amount and quality of responses. For a guide covering extra help on how to post such as formatting code see

3

Manjaro is based on Arch and therefore the base install of users is more open to settings and changing stuff by the user. However, this doesn’t mean that a more restricted user can be created, like @cscs already mentioned. I can look into LMDE to see what they set.

Depending on the Destkop Environment there are additional possibilities to restrict access. So we need to know more about how the PCs of the lab got installed.

You can write me a PM or email, so we can discuss further what needs your school and in general is needed to make Manjaro a possible solution for the given problem you have.

Most install medias of Manjaro offer these defaults: lp,network,power,sys,wheel. This can be changed of course based on the use case.

4

Let me get this out of the way …appologies …I thought the account setup questions that asked all the specs of our machines would make that info visible on posts … it seems to be only generally survey overview data for the dev team and not actually visible by those wanting to lend a hand.

So… we are using a bunch of old iMacs
CPU: i5-3470
RAM: 16GB
GPU: NVIDIA GTX 675m
Driver: Nvidia 390
Kernel: 6.5.13-7
MANJARO KDE desktop
Primary applications: Code-OSS(code), KdenLiven, Orca Slicer appimage, Inkscape, Gimp, Blender, Firefox and Chromium browsers both, Arduino I/O board IDE, and Freecad Mechanical added through KDE software manager.

Primary concern is wifi password visibility in system settings for low privileged users and retention of passwords.

Secondary concern is restricting access to other settings access for self same low privileged users.

Many thanks @cscs for recommending the creation of a group-user.

Creating a group-less user worked to hide network settings setup by admin and yet still use that network.
However…
Testing further shows that the user student in the student group can still change other settings …notably they can change the screen and remove security certificates.

If the student account attempts to access a hotspot …they can do it, but upon attempting to go back to the original network set up by admin the password is requested rather than reused.

I chose to store the password admin added as encrypted for that user only so that made sense, wifi isnt kicked out and disconnected when simply logging out to switch accounts without a full shut down.
It turns out student was just bumming the wifi that admin had turned on.

Practically speaking this still has some use as an indicator somthing hinky is going on at a particular computer station because students can’t easily switch back to the school’s wifi from a hotspot to hide the fact they spent class on their personal unfiltered internet.

If I enter the wifi password it works to get online but is not visible. …hooray!

Restarting and only entering the student account with no other users paving the way to network access indicates that the password entered was not stored. …bummer.

I’ve noticed that forcing KDE wallet to use the same wallet for “local passwords” , manually entering the password, and restarting still forgets the wifi…so it was hidden but far too dependent on admin starting up wifi first …O can’t do that for every machine every day.

…but I may have a temporary solution that leverages the groupless account still…

While not ideal, I removed all wifi networks under all users and then re-added the intended network, then allowed unencrypted password storage for all users while logged in as admin.
This guaranteed that the password was available to the student account, no need to provide it every restart…but of course it was now visible.

So I found a forum mention of encrypting this password in a form that is still usable as plaintext.

The konsole command …
wpa_passphrase

Returns a lengthy encrypted string.

This massive string of gobbledygunk characters replaces the original passkey in system settings network manager and it gets interpreted identically as the original thus working as unencrypted plaintext for the admin …and for the groupless unpriveleged studnet account.
What everyone sees is in plaintext is gobbledygunk … but everyone is allowed on the wifi.

What remains to be determined at this late hour of the night is if that long string which is totally visible to the student account can be decrypted easily in some cut and paste website or using some other konsole command they can google-up in a few seconds. I’m hoping its not that easy… or why have it at all?

I’m never an advocate for security-through-obscurity so for now I’ll begrudgingly call this a temporary solution at best until I can find a way to harden things more concretely.

At the very least I can stave off a time consuming reimaging of all the lab machines for another weekend as this keeps things from being as obvious as the nose on students’ faces.

The topic of a “kiosk mode” came up when I ran this up the flagpole among some local friends so I’ll have to investigate the options for that type of desktop environement limitation later. My memory of kiosk linux usage was as a one app full screen effect that couldnt be exited without a special keyboard combination. …not exactly compatible with ditching chromebooks for a modern OS that can run a variety of multiple FOSS apps for various school projects.

Tommorow I’ll read up on manually editing parameter files since the advanced control of system settings permissions are all grayed out even for admin and root …understandably so.

Thanks for the fast reply …this has been great to learn about … que the Manjaro support forum auto reponse AI bot telling us all we did this entire exchange all wrong …

5

I am not super familiar with this, but to my knowledge this uses the the SSID and Passphrase to create a hashed 256 bit PSK… meaning it cannot be used to find the current or future passphrases.

Extra note: While nothing can be reconstructed from the hash … it itself is reusable … so anyone with access to it will similarly be able to use it to gain access from other points/times.

1 Like
6

Why not store the wifi password “unencrypted” in the NM system connection file. A unprivileged user can’t read that file. Which means a student can’t read the password form this file. But the wifi connection can be started by all users including unprivileged user.

7

KDE provides a KIOSK mode on which you can restrict even more: Introduction to Kiosk | Developer. I also checked LMDE and the standard user only gets added to the users group. A normal admin is added to cdrom, floppy, sudo, audio, dip, video, plugdev, users, netdev, bluetooh, scanner

1 Like
8

And this is quite dated.
It may make sense on Debian … but not so much here.

https://wiki.archlinux.org/title/Users_and_groups#Group_list

9

You could remove NetworkManager and only use systemd-networkd in combination with wpa_supplicant.

Then, your config resides in /etc which can’t be written (or read) by users, if configured correctly.

There is no GUI to connect to another network and you would need sudo.

However, this should be done by a proper sysadmin. And you should trust your students more. (Let’s not discuss this here.)

10

My educated guess is that all the things other OS devs do to effectively grant the ability to look inside and poke aroung another user’s settings denying them access to core baked-in capabilities ie “manage accounts” …run completely against the ethos of the Arch system… and I’d never want that to change no matter how convenient that would be for my specialized use-case.

Arch and Manjaro are awesome because they go the opposite way and break the chains holding things back ( especially for hardware support) …literally for our lab Manjaro KDE is almost twice as fast on our old hardware as other distros like LMDE …app for identical app things just work and work faster ( see specs posted above in my response to CSCS).

It just seems like from time to time not everything needs to be wide open and can bow to a valued need like security.

For instance RE the original post…just as a global default …the ability to switch off password revealing seems useful for general-purpose security whether we are looking at wifi passwords in network manager …or anywhere else . I’ve never relied on revealing a password to spell check my typing or remind myself what an ancient password was because I forgot.

Much like the heart of Arch, the ethos of KDE Plasma seems similarly aligned with mind boggling amounts of customization as a core tennant of it’s existence …again the oppposite of a clamped and super restrictive one-choice-fits-all look and feel. I cant fault either dev group for delivering outstanding products that encourage users to roll up their sleeves and dive deeper and I havent seen a community effort anywhere urging for more of what woild be purpose build back doors.

The more I think about it, the tasks of clamping down a school environement are probably better suited to a purpose built distro. Unfortunately those I’ve tried were terrible …probably owing to the central belief in gross ( almost Mac-like) oversimplification and/or restrictions that make things downright impossible.

No surprise really that no one is banging that drum loudly …or at all.

I think forsight dictates I recind the request for school adaptation tools as it would surely lead us all down a path of tearing our hair out and accomplish very little of what was intended.

That being said, I might pop over to the pull requests section and suggest that password revealing is not always a vital necessity and could be either off by default or on by choice.

As for meme background changeout and hotspot bypasses sucking time out of my day to deal with …some targetted automation and repurposing of pre-existing apps that may not have been used in those ways …yet
…could be a fruitful line of discussion to branch into.
There is probably some "perfect’ tool I’m just not catching in my searches on the app mananger because its used elsewhere.

The need for smart capable computing tools is only going to accelerate faster than most schools can cope, I fear, as the variability of BYOD (Bring Your Own Device) at schools or the mass issuing of chrombooks, that are nearly useless offline and destined to line a landfill in short order, continue to dumb kids down and leave them unpreppared for anything other than entertaining themselves with computers.

Some students actually come back from college urging me to cover more computing tools earlier because they already see the gaps and I am in the unenviable position of totallly agreeing with them while laregley being powerless to implement those great ideas.

We are either going to see currated computer labs return in a big new way ( an opportunity for Linux) or we will see schools mandating machines with better specs and newer updates than many families can afford. Pragmatism suggests labs will likely win that debate in most districts.

Hopefully some other folks out there find the temporary solution above useful. I spent about two weeks reading and tinkering on my own unsuccessfully before I broke down and admitted I was stumped then jumped on here and I’m very glad that I did…it rapidly got me farther ahead than my attempts alone.

Cheers and thanks, you guys did your good deed for the day and helped a crusty old tech teacher keep up with the times.

1 Like
11

In Denmark there is an opensource project used for central administration and operation of public computers. It was started in 2013 by the municipalities of Aarhus and Silkeborg.

https://os2borgerpc-image.readthedocs.io/en/latest/

1 Like
12

Apple, Google and Microsoft try to lure their future customers into their ecosystems by talking to schools and “offer” them solutions to teach IT or STEM. The result is not teaching but more or less using products you have no control over in the end and are dedicated to be used in your adult life based on what they have taught you at school.

Arch on the other side is more the set of Lego bricks of which you can build the world as needed. Manjaro tries to lower the entry level into that ecosystem called Linux Distributions.

Most decisions are done Top to Bottom and the lower the food chain the less influence you have on which software gets suggested and used. Most don’t even use the stuff which they decide. It is more Money talk. You get those stuff for less than a penny. But you have to be very careful on “free” stuff. Long term goal is always future customers by big tech.

KDE is simple by default and powerful when needed. There might be even a setting to hide or not reveal passwords if you dig really deep enough or ask the right person of the developers team.

There is no Manjaro for Education, but no one will hinder to work on such a solution. It needs to be specified what is needed and checked if that is already possible with given software.

If wanted we can schedule a video call to check what is needed and how we can help. And yes our community and folks using and developing Linux Distributions are helpful and mostly friendly of sorts. It simply needs more adoption to be successful.

4 Likes
13

Wow! … more depth to investigate and test, I’m … looking forward to getting back in the lab on Monday…thanks to everyone who added more to this thread this morning! ( or later than I stayed up last night)

This looks promising, I think I’ll chase down a procedure for storing in NM and also try the /etc path restriction others mentioned first before trying some of the other ideas.

Regarding reaching out to KDE forums…

I came accross a Debian specific post where line 55 of ce-page-wifi-security.ui is set to FALSE…which effectively edits away the password revealing eyball icon…exactly what I am advocating for. And what I’ll be championing over at the KDE forum.

(Because links are not allowed) The askubuntu thread is titled …
hide-show-wifi-password-don-let-show-wifi-password

Obviously this is not directly applicable but indicates an intriguing solution …albeit a reversible one as Rinzwind points out.

In terms of overall strategy …
Timeshift has been a reasonably fast way to undo a lot of damage so far. Too bad there is not a hardware ID agnostic way to do the same thing from a single image, right now I have a timeshift incrememntal backup for each machine on a local (in the lab) server.
That is a technical topic for another post but image deployment and backups are a pretty sizable part of school lab management.

I do want to trust students more but far too many of them have unlimited data plans and hotspots on their phones, despite constant communications with parents that this just enables a never ending stream of distractions shifted to their computers when they don’t have easy access to phones.

The uniquitous use of Chromebooks came about almost entirely because of this issue at schools and neither MS or Apple tools did anything to address the problem. The same folks who advocate for free access to “move fast and break things” are rarely the ones who have to clean up the messes left behind.
And I’ve rarely met any of those folks who would openly advocate that preteens and their underdeveloped prefrontal cortexes should be on screens for 6 hours a day. That ideology is hoisted by its own petard when it’s their own kids.

Another nail in the coffin for educational specific operating systems and tools is that once you go down that path and “target” education explicitly… the legal liability requirements get intense …I mean really Realy REALLY intense, rather quickly.

I used to work in the defense, aerospce, and medical industries and only the medical regulations come close to the educational kid safety regs.

14

This topic was automatically closed 3 hours after the last reply. New replies are no longer allowed.