Users subverting security on purpose, Kerberos the only answer?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Users subverting security on purpose, Kerberos the only answer?
I have an environment with multiple projects that have a variety of government and commercial sponsors. We have been satisfied to this point with a netapp serving nfs/cifs and keeping a tight reign on nfs exports.
Some of these projects have started asking us to provide access restricted sub-folders of the project space based on different groups that contain a user subset of the primary group.
this works until...
We have a linux machine that serves as a version control front end to the netapp, mounting the project spaces via nfs. People are now mounting their project space via sshfs to this "front end" and sharing the root password of this sshfs client with everyone in their project, in turn creating a security hole to access the so called restricted sub-folders. I know all the obligatory responses referring to irresponsible user behavior but would like to see how others have addressed something like this where user behavior seems out of control.
I believe having a well defined security policy would be the best place to start, once users have been informed regarding their responsibilities action can be taken on any further misuse etc..
If people are sharing passwds, that's a management issue, not a technical one. You have to talk to your mgrs and the project sponsor mgrs. There's no technical solution imho.
I suppose you try RSA fobs ie 2 factor auth, 1.something you know (passwd) & 2.something you have (RSA fob), but they could share those..
Maybe ssh auth keys instead of passwds ?
In any case, I'd still talk to the mgrs; in most companies sharing passwds is a very serious offence, in some cases you get sacked (eg banks).
@frndrfoe: Why do the project managers need the root password?
These are their laptops and desktops where they develope, we have to allow them full access to that machine. If we didn't they would wipe and rebuild them themselves.
Then help me understand the complete picture a little better. They're sharing their desktop root passwords. How does that allow them to subvert NFS security? From your first post, it sounds like the real issue is the version control server is letting them get around NFS security.
Alternatively, if the issue is that they're mounting a filesystem to their workstation and then letting others ssh into their workstation, you might need to lock this down at the network/transport layer (i.e. using an intelligent switch).
---
Thinking on it some more, though, there is a fundamental problem. Unless I'm missing something, I'm going to have to agree with post #3. The security policy needs to be shored up, and these managers need a good kick in the arse. That requires buy in from someone above their pay grade.
No matter how many technical bandaids you slap on this problem, determined users can get away with all kinds of dumb shenanigans. (How about passing around usb thumb drives containing sensitive data? That'll beat many of your best tech implementations.)
Yep. Unless these project managers own the whole COMPANY, they are circumventing data-security policies. And as to the whole 'they wipe their hard drives and rebuild', same thing...these are the COMPANYS machines, not their own personal ones. Unless they are sysadmins, and are responsible for the integrity and operation of the machines and networks, they leave it alone. If not, get your management to come down on them, hard. If they don't, put the issue in writing, and get your managers to sign off on it.
When the systems die, remind them of your warning, and be sure to leave on time that night. If any of the project managers complain, tell them TFB, they caused the problem, and now they can wait.
Really, this is a management issue. And if your direct manager doesn't take action, go above them, and let them know you're doing it, too. At the end of the day, YOU are responsible for keeping the systems up...not your boss, not the project managers. They'll be home with their feet up, with family and friends, while you're undoing their mistakes. I've been in that situation in the past, and I make damned sure to avoid it now. And really, you're not being unreasonable...you're looking out for the COMPANY interests, which is what they pay you for.
Did i mention this is a Higher Education/University environment? Project managers are often tenured faculty. I think I will kill sftp to derail the sshfs antics.
Then help me understand the complete picture a little better. They're sharing their desktop root passwords. How does that allow them to subvert NFS security?
1. Front end server nfs mounts export from netapp
2. export contains subfolder with more restrictive group
1. user1 sshfs mounts to front end server on machine with shared root
2. user2 can "with malice" su as other user to access restricted subfolder or create local groups to override ldap groups.
am I making sense?
Project managers want to have ZERO responsibility regardless of what they do and expect us to provide security in spite of ...whatever.
BTW: this is looking like a management battle as expected, we can offer security that will make them realize that personal responsibility is easier than the echelon approach.
1. Front end server nfs mounts export from netapp
2. export contains subfolder with more restrictive group
1. user1 sshfs mounts to front end server on machine with shared root
2. user2 can "with malice" su as other user to access restricted subfolder or create local groups to override ldap groups.
am I making sense?
Project managers want to have ZERO responsibility regardless of what they do and expect us to provide security in spite of ...whatever.
Well, I want to have truckloads of money dropped off in my driveway every morning, while lingerie models rub my feet, but that's not likely to happen. What they WANT is different from what they can GET.
Quote:
BTW: this is looking like a management battle as expected, we can offer security that will make them realize that personal responsibility is easier than the echelon approach.
Yep. And again, get management to put it IN WRITING, and sign off on it. Put EVERY objection you can think of in writing, along with what the consequences of ignoring you will be. Get signatures, from management, and the project managers. They don't sign? Then YOU decline responsibility for the server(s), because they're expecting you to be accountable, while not giving you the power to make sure it's done right.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.