Slashdot Mirror
Linux Desktop Security for New Users?
theblkadder asks: "Our company is currently undergoing a company-wide transition to Linux on the desktop. While there are numerous excellent guides and tutorials for the admin crowd, I haven't been able to turn up much for the non-technical user. I'm looking for something that would cover such topics as basic desktop do's and don'ts, like 'do choose a non-dictionary password' and 'don't blindly drop to root and install an unverified/unauthenticated RPM that you receive via email,' etc. Anyone seen a guide like this?"
It's called the don't-give-anyone-root.
You don't give anyone root and let them do whatever they want.
I'm looking for something that would cover such topics as basic desktop do's and don'ts, like...'don't blindly drop to root and install an unverified/unauthenticated RPM that you receive via email,' etc.
When you say non-technical and 'basic dos and don'ts,' that example seems pretty technical. You might just as easily say "don't double-click unverified email attachments."
IMO you will probably be in the best position to write this documentation because you know your typical user and probably know what they are and aren't allowed to do already on their new desktop. I'd be interested in seeing what something like this looks like if it does exist...
Todd
don't blindly drop to root and install an unverified/unauthenticated RPM that you receive via email
That would be nice to say to a home user.
But on a work environment, why give the root password to the (non-linux-experienced) users in the first place?
Why would non technical users have root access in a commercial environment. Not even management should have such access, beyond being able to get the password from a sealed package in a safe in an emergency, and then only with checks to ensure that no one can withdraw it without authority. No system is secure unless the root password is restricted to the admin that needs to use it, and ideally that should be a single person.
I'm looking for something that would cover such topics as basic desktop do's and don'ts, like 'do choose a non-dictionary password' and 'don't blindly drop to root and install an unverified/unauthenticated RPM that you receive via email,' etc. Anyone seen a guide like this?
Why?
Do you expect anyone to actually read this document?
Oh, I wish I were being sarcastic.
Either enforce things (your password policy), or wait for people to have trouble so you know what to document (every installation is unique, and you're wasting time trying to predict how your users will react when you could just wait and see).
The only purpose of such a document, in the end, is CYA anyhow. And again, I wish I were being sarcastic. If you can't enforce it, people are going to do it.
The only possible exception is if this is a technical group of users who will be daily and strongly held accountable for violations. Basically, the only group of people who meet these two criteria are Computer Science (or related disciplines) students.
Otherwise, don't bother. Not sarcasm.
With the hype around Linux's security, why are users allowed to do this? Would it not be easier to deny the ability to use a non-alpha+numperic password? This could be easily implemented into any distrobution.
Under the "start" menu on whatever desktop you choose, name all the shortcuts after their Windows counterparts.
e.g.
Clicking on Word launches OO.org Writer.
Clicking Internet Explorer launches Mozilla.
Clicking Outlook launches KMail.
Clicking My Documents launches Nautilus or Konqueror.
etc.
Given that most popular FOSS productivity software is functionally equivalent to its MS counterparts, the only major barrier for the non-technical user is learning new names for everything.
Unknown host pong.
I'm not asking the subject question to poke fun at you or flame. From your description and discerning how you plan to setup Linux on the desktop it sounds like you're missing one of the benefits of Unix because you're looking at it as a Windows admin. But I could be completely wrong.
You can set up desktop as basically a terminal using X. I know, what a waste of a desktop right? But, that's how Unix is built. You can setup a server (or multiple servers of necessary) to act as your main server and each desktop is really logging into the server using XDMCP. Or look at the Linux Terminal Server ProjectYou lock out logging into the local machine and poof! All user files are forced onto the server so there's no pesky phone calls like "Well I saved the file onto c:\pron\pron\pron\pron2\pron2 but the hard disk just went bad! YOU need to get it back for my board meeting in five minutes!" I realize this is a lot of overhead, but you can gain alot of control this way like upgrading OO.org for everyone without having to update every single desktop.
Perhaps XDMCP is too insecure for you or you have so many users that XDMCP would be too difficult. That doesn't mean you can't set it up like I've described. It just gets complicated, which means its beyond my meager expertise, but I've seen it set up that way at school.
Except it doesn't log out. It just kills everything very nastily.
Not too nastily. Less nastily than a kill -9, for sure. The apps still can do whatever shutdown operations they need to.
But let me paint you a picture. A lab where most of the occupants aren't Unix people. Some of them aren't really computer people. They're hardware designers, or embedded systems programmers, or {domain} experts, or other such things. All of them are good at what they're hired for, but may not be good at other stuff. Like using a PC.
Most of these people got their .profile and .xsession by copying somebody else's, if they're not just using the system default. They didn't pick their WM, because they don't really care much about their WM. They've never taken time to learn anything. They have their xterm start up when they log in, and a row of CDE-style buttons to launch other xterms, a web browser, and maybe Citrix. No easy button to log out.
So they'll often log into a box, do what they need, then wander over to some piece of equipment they need to work on, without logging out. There's only six general-purpose PCs in the lab, so it doesn't take long before they run out if people stay logged in when they're not using them There's a new threat: people hitting the Reset switch when they come across a logged-in but unoccupied machine.
Now, the lab manager needs to make a notice to log out. If there aren't concise, clear instructions on lab notices, they don't get followed. So that's the notice.
Now the other end. What's the harm? Apps still get their notice to shut down. They can save user configs, send termination notices to network peers, whatever they need to do as long as it doesn't involve interaction with the X server.
Sure, it'd be nice if everybody knew all about the tools they used. Hell, it'd be nice if they had basic understanding of their WMs. But they don't, and we don't expect most of them to any more than we expect them to play a trumpet. It's just not what they need to do for their job.
Which probably isn't as large a task as you might imagine. It will also give you the chance to customize it to your users, which makes it a whole lot more likely that people will read it. There is plenty of online material to use as a reference, especially when it comes to password choice. Also look around for documents from university computer labs or university computer support services. You may find some ideas there.
You also might want to consider making people pass a quiz in order to get an account. Sure, it's irritating... but it actually does work. Make it part of the regular procedure for getting access, so that you catch new users.
A presentation can also work, if you're a decent speaker or you are willing to hire one. Doing something flashy could be fun. Consider having everyone create an account for themselves on a test machine at the start of the presentation and then having a password cracker grind through them all while the meeting is in progress. If you've got a couple fast machines to spare, you could probably shock the hell out of people by guessing their passwords before the meeting ends. Better have a backup plan, in case your users are more savey than you think.
And, to repeat what's already been repeated many times: you really shouldn't be letting new users choose arbitrary passwords nor giving them root access if you can help it. If you can't avoid giving them root, then try to give it to as few people as possible, and have a nice long talk with them about appropriate procedures first. (And make damned sure you have regular backups, so you can repair things when they screw up.) Sudo is your friend!
It's really not much more complicated like that. If you can get everyone to choose good passwords, change them frequently, and not share them with each other, then you are good to go.
You can hire network administrators to tell you which protocols are safe and which are not, and where you should use them and how. You can hire system administrators to watch your main systems and harden them as well. You can even get some internal tech support people to help out the users and make sure all the machines are up and secure.
But it always comes down to the individual users: Get a good password, change it frequently, and never share it with anyone, period.
The radical sect of Islam would either see you dead or "reverted" to Islam.
If your user account is compromised, you can be tricked into running a different program than you intend.
If my user account is compromised, then I don't really need to be tricked; the attacker can just run the programs directly. Or if he's trying to spoof a password prompt, he can edit my .profile and set my PATH to whatever he wants anyway.
Alternately, if you mess up the permissions on your ~, you can be made to run a different program, compromising the account.
Again, if ~ has bad perms, then the attacker can edit my .profile, so again it's irrelevant what I set my PATH to.
If you disable it in your X config, apps can intercept it, so it's foolish to assume that you're looking at a genuine X/K/GDM after hitting it.
Uh... If the X config has been edited, then that means that root was already compromised. Besides, you can see the monitor mode switch if you hit a C-A-BS and it takes effect.