Slashdot Mirror
Locking Down Linux Desktops In an Enterprise?
supermehra writes "How do you move 300 desktops, locked down with Windows ADS Group Policies (GPO), over to Ubuntu desktop? We have tried Centrify, Likewise, Gnome Gconf, and the like. Of course, we evaluated SuSe Desktop Enterprise and RedHat Desktop. Samba 4.0 promises the server side, however nothing for desktop lockdown. And while gnome gconf does offer promise, no real tools for remotely managing 300 desktops running gnome + gconf exist. All the options listed above are expensive, in fact so expensive that it's cheaper to leave M$ on! So while we've figured out the Office suite, email client, browser, VPN, drawing tools, and pretty much everything else, there seems to be no reasonable, open source alternative to locking down Linux terminals to comply with company policies. We're not looking for kiosk mode — we're looking for IT policy enforcement across the enterprise. Any ideas ladies & gentlemen?"
Why not use LSTP? That way you only have to worry about whatever image(s) you keep on the server.
so expensive that it's cheaper to leave M$ on!
If you want to be taken seriously, please lern 2 spel currektly. I'm not a Microsoft fan, but it sure is annoying seeing it spelt like that.
if you are talking stand alone desktops then it's not so great. linux doesn't really have anything as good as group polices and active directory, it's part of the reason corperate networks are mostly windows.
If you mod me down, I will become more powerful than you can imagine....
I guess the first question is: what are you trying to accomplish? Are you trying to prevent users from installing additional software locally? Are you trying to insure that particular applications get particular preferences set and users are prevented from changing those settings? What? Just saying "lock down the desktops" doesn't say what you're trying to actually do.
Remember that Unix is, in large part, designed to work correctly without needing to be locked down. Much is controlled simply by the system-wide configuration files. The rest tends to be controlled on the server side, so that users simply can't do unacceptable things regardless of how they configure their local user account.
In linux world, there is yet to be a quick, 3 question and 1 button way to add the computer to a domain and then receive straight away:
- group policies - security and software install
- single password store (with cached passwords for notebooks that go away from the network)
- Patch update policy
The only thing linux does right is work on technologies such as DHCP that were written for OTHER unix O/S'.
Ubuntu is not interested in those things, they're more interested in making stories about koalas and hiding popup boxes.
Gnome is dead, Mono and moonlight took all their brains away.
kde is making a next-gen desktop but have yet to understand why so many IT shops have kept Windows at the office.
This is all depressing. Windoze will never be replaced at the current rate.
And now you know why Windows dominates the enterprise market.
Good luck.
Instead of spending $$$ on bondage and discipline, how about treating your users like adult human beings?
Because a number of them will wind up installing aps that put the company at risk?
I'm a consultant - I convert gibberish into cash-flow.
You set up the machines to all boot over the network, from a common image, and to load all system files from a NFS share.
The only thing on the workstation is the user's $HOME directory, and some local stuff like /tmp, /var, etc.
Your users don't get root on their workstations. They shouldn't need it. This isn't like Windows, where a huge number of apps don't run correctly if you don't have admin rights. Linux is designed under the assumption that users don't have admin rights.
Maybe I'm being naive, but what more do you need?
I hate it when I make a joke and I get modded "+5 insightful". Mod the stupid comments "funny", not "insightful", pleas
I remember an article about KDE's long term strategy to be just that: an enterprise ready Desktop with fine grained policies, central administration and all the fluff that makes windows enterprise-ready and the de facto standard for the desktop.
IToday, we have a colorful disaster that isn't even as usable as its predecessor. Developers should have focused on the need for an enterprise desktop that could actually make a dent in MS corporate sales. Instead we got useless eye candy.
The fault, of course, lies with the big distributions that pride themselves on providing enterprise ready Linux. Enterprise sans le Desktop. Useless wanking. The requirements for an enterprise ready desktop are out there for anyone to see and it's not just "applications" as everyone usually points out. It's the ability for administrators to create and maintain a usable desktop according to official corporate policies. No more and no less.
locking down Linux terminals to comply with company policies
Sooo, what exactly ARE these company policies?
That's a Microsoft paradigm, born from forcing the square peg of multi-user shared resources onto a single-user-owns-the-world system. Linux and other Unix operating systems were designed from the ground up to be secure multi-user operating systems. (And all you Microsoft-paid astroturfing fanbois who want to dispute that can FOAD. Just look at the mess that's UAC and the need for Microsoft to break it for their own use.)
Just set up default menus, and if a user mucks them up blow away the .g* (or whatever) configuration files/directories in the user's home directory.
Because anyone who knows what they're doing can run "unsupported" apps on any computer they can log onto anyway.
Ya, NO linux based company would EVER do something like that.
www.redhat.com
What's Ubuntu's LTS support? 5 years? And how long has XP been supported? Right...
Probably because you can't guarantee that the users will ACT like adult human beings.
Any corporate policy that relies on "Let's just hope users don't do bad things" is doomed to fail.
If you need web hosting, you could do worse than here
You think using technology to help enforce an IT policy and respecting your employees are mutually exclusive aims? I strongly disagree.
A small contingent of 'bad apples' can do serious harm if you do not effectively enforce IT policies. It's not possible to guarantee there is no one like this in your company, so you should protect the company and other staff from from them.
Respecting staff won't stop douchebags being douchebags and screwing up your systems.
Finally! Thank you. I can't believe I had to read so many posts on slashdot of all places before someone points out the obvious. I recommend the OP googles "root over NFS." To reiterate, don't try to do Linux the Microsoft way. Also, please disregard all these stupid AC posts about Linux not being ready for the corporate desktop. Unemployed MCSEs are just yanking your chain.
Let us not become the evil that we deplore.
While I _mostly_ agree with this, a nice policy management (configuration management mostly) tool is also essential when dealing with lots of boxes. You want a new setting for all Gnome desktops, simply add it to the policy tool and let it distributed any required config files or run commands to change the setting, etc. This type of thing used to be done with things like: for h in $all_my_hosts; do ssh $h /tweak/some/setting; done
CFEngine and Puppet and friends are a nicer way of doing this. They're "self documenting" in that your write the code and then you can later very easily see when you added some configuration bits, etc...version control your configuration management scripts and you get even better tracking of who did what and when. (A side question: How does one do the version control type stuff in AD?)
While kickstart is great (I use it), it only goes so far. Having a policy manager on top of that (installed and configured in the kickstart) is a beautiful thing!
-Ben
Or, am I missing something?
Yeah managing this for 300+ people in an environment that changes daily without spending your entire IT budget on admins and the sneakernet support staff.
despite our desire to act like open source is the cure for all ills this is the type of problem we need to solve. You MUST lock down some enterprise environments (or have a CEO who is willing to go to jail) and you MUST be able to manage this without breaking the company piggy bank. He's asking for solutions to these two requirements not how to keep ONE person on ONE desktop from doing ONE of the many forbidden things.
And as for the guy/gal who suggested we treat everyone nice and hope they act right. That's fine for your 10 person IT shop...not so much for a multi-billion dollar public company that needs public trust and investment and is governed by a whole mess of federal regulations in numerous national jurisdictions around the world.
Want to lock stuff down? Don't give users root.
Knowing what policies they're talking about might be helpful because I had the same question. What policies would require root level access? White list the proxy. Backups, share drives, printing...we have all those services on our Linux desktops. We can remote in and install any software they need...??? What policies can't be handled by a user account?
Maybe I've been away from Windows networking too long, but I can't think of why you'd need to do this.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Have you ever met a sales person, or watched them try to use a computer? Seriously, watch them try to send a 500MB powerpoint presentation as an e-mail attachment, or ask for tech support on their limewire install, and marvel at the risk to your company.
Err, you can still run interpreted programs on a filesystem mounted noexec:
~$ python myprogram.py
A sufficiently clever user could use an interpreter to write his own dynamic linker and thereby run binaries too.
But I agree: locking down the desktop is the wrong approach. Better is to separate sensitive information from things that aren't sensitive, and have a standard user environment to restore to if the user does manage to mess up his configuration.
You kids still think that what the OP is asking for has anything to do with "preventing users from doing something harmful to the computer".
Get it out of your heads. Many of the things group policy can do has nothing to do with "security" or "preventing users" from doing anything. It has a lot to do with quickly standardizing departments, offices, rooms, or whatever your business structure is.
When you move a computer to a different department you simply drag the computer in AD to the different OU and BAM! That computer now gets everything new with its policies. There's no bringing the computer in to the IT department and reloading its configuration with "Configuration A for Department B".
Want to make a change to how a whole department does things? There's no pushing a script out later on to the whole department. You simply change it in group policy and the entire thing gets taken care of automatically.
You can spend more time focusing on actually getting shit done than fussing around with HOW to solve the problem with roundabout tool sets.
If it's cheaper to stay with a Microsoft-based infrastructure, then stay with that. Creating massive infrastructure-wide group policies that go from desktop to web browser is sort of a windows thing. If you're going to maintain security policies in a linux-based system, you better be prepared to start thinking in Unix- that means remembering that you're using a network-based system, not a locally-oriented system on a network.
If you're setting an IT infrastructure, the costs you're cutting on licensing will probably bite you in either support, security, training, or usability/productivity. There's no such thing as free software, I'm sorry.
CFEngine can be used to enforce IT policies on UNIX desktops, servers, etc.
It's free and works quite well. All of the large enterprises I've ever worked on use this extensively.
http://www.cfengine.org/
Normal business is when a virus spreads. Scanning for viruses is not a bad thing and performance should not trump security. This is called being pro-active which is ideal when dealing with computer security. Only scanning for virus's at night is call reactive, which is bad when dealing with computer security.
Also, the IT department is responsible for the network and security of the network. If they make a policy that no linux machines can be on the network then what is the issue? Tight control over computer resources by IT staff is certainly best practices for a secure network.
Granted, Linux desktops are more likely to be safe than Windows desktops, but administration time is also very important. Centralized policies such as a Windows Domain is much easier to manage than a hodgepodge of various desktops with no way to enforce policy.
Ok, first though, these are ordinary workers. They aren't blackhats, they don't want to screw up their system, and if they know how to do that, they most likely work in the IT department.
Don't treat your employees like criminals, if they break enough things all the time, fire them for incompetence, but there is no need to totally lock down everything.
Taxation is legalized theft, no more, no less.
Actually, browsing Slashdot, The Old New Thing, lwn.net and so on has made me more productive overall. Preventing users from accessing "time wasters" is a losing strategy: not only is the blocking technically futile, but by treating employees like children, you kill morale. Instead of micromanaging their days, treat employees like responsible adults and evaluate them based on their work and its results.
By blocking them out of root access, they can't download a package like a .deb or an .rpm & install it. If they somehow manage to figure out how to download and compile a tarball, all they can install it to is their own home directory. I'd say, best way to do it is make sure they don't have compiler access. So, take them out of the sudo users group.
Understanding the scope of the problem is the first step on the path to true panic.
Instead of spending $$$ on bondage and discipline, how about treating your users like adult human beings?
THIS is why those tools don't exist. Because every time you ask, some self-righteous idealist responds like this. Unfortunately, those self-righteous idealists are often also the really good programmers who have the ability to create such tools.
You grown-up still think what you are talking about is hard in linux.
Get it out of your head It is super-easy to make things standard in Linux, and if windows doesn't do it the way you like, you can still do it with linux.
When you move a computer to a different department you simply boot it up. Have a service to check which rpms should be installed for the department and install those and BANG BANG! The computer now gets everything with new policies. There is no bringing the computer to the IT department and reloading the configuration, or even having to deal with MS licensing!
Of course you have to make your own rpms, but that is dead simple. Want to make a change for a whole department. Just recreate the rpm in your repo the way you want it, and install it.
With Linux you sometimes have to spend a few extra minutes to make things work, but when you are done it is a million times more flexible than windows. You know how it works, and you don;t have to worry about any BSA audits. Not having to worry about the BSA means you can save tons on the licensing department in you giant organization.
Many of the things group policy can do has nothing to do with "security" or "preventing users" from doing anything. It has a lot to do with quickly standardizing departments, offices, rooms, or whatever your business structure is.
When you move a computer to a different department you simply drag the computer in AD to the different OU and BAM! That computer now gets everything new with its policies. There's no bringing the computer in to the IT department and reloading its configuration with "Configuration A for Department B".
A lot of this can be done by netbooting the computer and letting it grab its configuration from the filesystems it points to.
The configuration files (mainly in /etc) can contain the default startup scripts for the department's configurations. If you REALLY need to limit what apps the user can run, point to binary and library directories that don't contain anything the user mustn't have.
Move it to a new department? Change the entry for the machine on the DHCP server. No need to pull it in for retweaking.
This also means you don't need to have the OS and apps on the machine's own disk. You have a single copy of each kernel, utility, and library on your fileservers. You can use the whole disk for swap and /tmp. No individual
installs. No local copies. Save the disk for stuff where fast access is needed but is all volatile. Meanwhile the cache take care of unloading the fileservers and network.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Unfortunately, few people in the Windows world seem to grasp that LDAP has been around for many years in the *nix world, and has all the functionality you would find in Group Policies when linked into PAM on the client side.
For a couple years, I maintained a company-wide network that supported unified "home" directories and unified login/password capabilities between Windows workstations, Linux workstations, and Solaris servers, all tied back to Fedora Directory Server. It was hell to set up, and sweet to watch in action.
Active Directory and Group Policies aren't bad for simple installations, but really turn into a mess quickly depending on your setup. LDAP and *nix systems that support PAM are a snap to set up, work fairly well and took significantly LESS time to get working properly than the Windows side did.
There's a lot of research that goes into setting up either side of the equation. Linux/Unix has been more ready for the "enterprise" desktop than Windows has, though, and that's a cold hard fact.
In Linux it's done with policies in LDAP that are used to set variables for login scripts. Using standard Linux tools (written 20+ years ago for UNIX systems), the login process can report back what machine, IP address, etc a user is accessing. That coupled with the group structures in LDAP are used to set environment variables that dictate everything a user can access.
If it weren't for the boneheaded point-n-click gui that windows crams down every admins throat, even windows admins would see that their precious AD is just ldap with environment variables modified by scripts.
You talk about converting 300 seats. I converted 2000 to LTSP desktops. All driven by only 33 servers. See here for details: http://www.localnetsolutions.com/press.html
If you are still stuck, my contact info is on the site. I consult.
Just because you have python and perl interpreters on the system does not mean you allow users access to them.
You can use file permissions to restrict access to your executable interpreters.
Re: sudo vi conf/file.conf
a) whoever set up that sudo should be fired. Look at rvim
b) anyone who would exploit such a whole should be fired
c) port forwarding wtf
That breaks functionality that uses those interpreters. For example, I see python running on my system for a printer applet. There are a number of things in a "modern" desktop that use python and perl (and ruby and ...).
Also, if you change the permissions, your system package manager will probably at least complain, if not change them back the next time the packages are updated.
As other posters pointed out, you have to stop thinking the One Microsoft Way.
With a Unix system, you NFS mount the /home and /usr directories and you noexec /home. That is about all there is to it. The machine just needs to boot up minimally - the rest it gets over the network from a central server, so you manage ALL your machines in ONE place.
It is much easier to administer a bunch of Unix machines than Microsoft machines.
Different scenarios. What if your user is using his account on a central machine via remote X11?
End users *are* responsible for telling developers what they're doing wrong.
Thanks for being intelligent and providing useful answers. Already I have learned about cfengine, bcfg2 and FreeIPA today - all of which look like bridging these gaps. Not that I want them to, really, since effectively Microsoft pays my salary ;-)
Yet, everyone is using it.
Goes to show how much it is needed.
Unfortunately few people in the *nix world seem to grasp that LDAP is just a protocol (that's the P bit of the acronym). It's just a standard way of accessing directories - which is what Active Directory is (as is OpenLDAP etc etc). LDAP means nothing as a reference to a directory - OpenLDAP might in your case. So what you meant to say was "directories (that are accessible via LDAP) have been around for years". Whether they do everything the particular implemention of Active Directory does is up for question - some may, some may not. It depends on implementation...
Lets examine the threats here:
Viruses? Hardly any.
Rampant piracy? Of open source? haha. Of movies? Block bit torrent
People opening up ports on their desktops to the world? Get a firewall.
People h@x0ring root? Tripwire+logging.
Dissemination of company secrets? Was always a threat. Force everyone through a proxy.
Anything else?
I wrote my first program at the age of six, and I still can't work out how this website works.
"Depending on the support contract, RedHat costs you anything from US$500 to US$thousands per year for updates."
Nope. Sorry. Simply not true. Updates are available regardless. Get over it. The whole model is not comparable to MS. Though millions of dollars change hands because lots of folks, including IT folks, just don't get it. Geez, I wonder if it is worth looking up the thread from maybe 4 years ago with IBMers who thought their support contract was a user license and they had to have it in place before they could use SLES.
But we in the community appreciate you dumping the money out there, even if it is on totally bogus assumptions.
They aren't competent because they have no incentive to be -- if they screw up their computers, that's IT's problem. If it suddenly became their problem, they might see things a little differently.
Just for fun, here's a car analogy: A car is a rather complex piece of machinery, and takes a lot of training -- typically an entire class of driver's education. While some people go on to master it and become stunt drivers, or simply improve their skills and get a truck license, etc, most are content to at least reach some level of competence.
But if you never bother to reach that much, you end up driving into a tree, or a telephone pole, or another person, and it's generally your fault.
Aside from the fact that cars are actually dangerous, and can cause bodily harm, I'll go with the fact that it is entirely the responsibility of the driver to be properly licensed and at least competent, and if they can't do that, it's entirely on their own head, both literally and financially.
Now, granted, many corporations don't like the idea of having to fire their best salesmen because said salesmen are morons about computers. But that only perpetuates the myth that it's somehow hard to attain some level of competence, and allows the salesmen to continue to see computer knowledge as somehow beneath them.
Don't thank God, thank a doctor!