| |||||||||||||
GNU Guix launchesGNU Guix launchesPosted Nov 26, 2012 15:11 UTC (Mon) by pspinler (subscriber, #2922)In reply to: GNU Guix launches by davidescott Parent article: GNU Guix launches
As a professional sysadmin, I can add a couple more cases here:
d) When the user installs their own packages and it breaks, they still call me. I don't have any idea what they're doing and can't debug it. Yet all too often, the user views the brokenness as my fault and my responsibility (and yes, that includes escalating their problems up the management chain). Ergo, I'm not going to let said user cause problems for me in the first place.
e) All too often, the user does something very ill thought out and irresponsible with their own installs, such as using a HPC cluster to spam a corporate database not designed to handle that load or sending confidential data out with insufficient security and controls (we're subject to HIPAA and Sarbanes-Oxley, at a minimum). I find it necessary to insert myself into this process as a basic design check on what the user is doing.
It's the classic trade off between free innovation and rational controls. Yes, rational controls significantly slows down the process of free innovation, but recall that most new ideas don't actually work, something like 90% of new ideas and/or companies fail in a quite short amount of time, many of them dramatically.
For the "do whatever you want" systems, we give users heavily sandboxed cloud resources with a very explicit contract "you break it, you fix it, and IT security knocks on your door, not mine"; or we just send them out to amazon or similar.
-- Pat
(Log in to post comments)
GNU Guix launches Posted Nov 26, 2012 16:50 UTC (Mon) by pboddie (subscriber, #50784) [Link] d) When the user installs their own packages and it breaks, they still call me. Admittedly, there's not much you can do about this other than to get them to provide details of exactly what they did, so that you can then tell them that it is a problem of their own making. On various mailing lists for Free Software projects, this is typically handled by asking things like whether the user is using any plugins or extensions, and getting them to actually include real output in their reports instead of paraphrasing the problem. I know this is hard work, but I imagine that you can't avoid this even if you lock down as much as you can because there's almost always some unforeseen variable that has to be identified. sending confidential data out with insufficient security and controls People can still get up to this kind of mischief without installing their own software, though. or we just send them out to amazon or similar For more and more organisations, there are going to be awkward conversations in the years ahead as upper management discover that large parts of their systems don't actually reside under the control of that dedicated department any more, but actually live in some cloud somewhere. You see this happening already as people go outside their institutional systems and use mass-market products instead (just as you have people using their own phones and computers instead of the ones provided by their employer). At that point, the question "What do we pay those people for?" is going to be even more threatening, especially after all the anecdotes have been heard about how people couldn't do what they needed or were put off until something "official" was ready for a particular task. (You see these symptoms in any large organisation where the resources to enable new services or activities are constrained by the tendency to shoehorn such things into the existing ways of working, thus eliminating the competitive advantage of the large, well-resourced organisation.) I'm not really arguing against systems administration policies, but it really baffles me that instead of entertaining and encouraging workable compromises and perhaps loosening the leash on captive users, organisations and developers would rather keep the leash as tight as possible even though history shows that the leash will break as a result.
GNU Guix launches Posted Nov 27, 2012 0:28 UTC (Tue) by davidescott (guest, #58580) [Link]
> I'm not really arguing against systems administration policies, but it really baffles me that instead of entertaining and encouraging workable compromises and perhaps loosening the leash on captive users, organisations and developers would rather keep the leash as tight as possible even though history shows that the leash will break as a result.
I think the relevant question is what is worse, having the leash break or just letting the dogs run free?
I don't think anyone (certainly not myself) is suggesting that policy is perfect, just that having policy is better than not having it. If you have no policy in place and anyone can install anything on any system then you have no guarantees that people are doing things correctly. And if your policy is that the end user gets to make the technical decisions based on their own assessment of their knowledge and capabilities in order to keep the business agile then you get some idiot who read "PHP for Dummies" making a website and keeping passwords in plaintext.
Dealing with the constraints on our group enforced upon us from systems was my #1 reason for leaving my last job, but I don't think the firm was crazy to have those restrictions in place. It made the firm less agile, but I also believe it prevented more problems than it caused. I had tacit permission from my boss to go off-policy in a number of areas, and the mere fact that I was going off policy made me consider every decision very carefully, and document what exactly I was doing in a way I wouldn't have if there were no rules.
One can do a lot of damage with software if they don't know what you are doing. I thought I was extremely careful and had a good idea of what the correct choices were, despite this I made some bad design and technology choices that somebody is going to have to back out within the next few years. So I'm all for trying new ways of organizing systems groups, and I don't know what the answer is, but I don't think it is giving everyone the ability to install anything in the package archive.
Another analogy would be that policy and controls on what can be installed is like having a curb on the side of the road. Sure you can jump the curb and drive on the sidewalk if you know what you are doing. If you are James Bond you might even drive up the stairs and onto the roofs of the building, but we aren't all James Bond, and having those curbs discourages many from doing things that are very dangerous.
GNU Guix launches Posted Nov 27, 2012 13:53 UTC (Tue) by pboddie (subscriber, #50784) [Link]
I'm not advocating that "the dogs run free". The dogs do run free, however, when technical measures to achieve their goals have been exhausted and they adopt social or political measures to achieve them in another way.
It's funny that you mention people deploying Web sites after reading "PHP for Dummies". I once had a discussion with someone who had pointed out that a Web site I had become responsible for - not in PHP nor developed by dummies, mind you - was running on a "high port" which in turn made his systems people uneasy, and he wondered whether it might one day be made available on port 80 instead. After a fairly small amount of work, the site was deployed within the existing port 80 infrastructure and I was able to get back to the guy within a day or so. This apparently made him simultaneously overjoyed at the prompt progress in the matter and frustrated that something similar would take weeks to get done in his organisation.
Having such restrictions are understandable - I have been aware of lots of crazy things going on in large organisations including some that were perpetrated by systems administrators themselves - but it does no-one any good if those restrictions are consistently implemented at the expense of people doing their work in a responsible fashion. When someone wants to run a program like Inkscape, to take a random desktop application that isn't in its normal form going to DDOS various Web sites as part of a botnet, surely the logical "first stop" is for the user to take advantage of the existing package available for the system and not to have to "manualize" the process by making a human being whose time is presumably precious run the install command on that user's behalf. (And virtualising the whole thing as a solution instead of supporting a non-privileged installation of packaged software just confirms that the software isn't inherently dangerous, anyway, because it shouldn't be the case that the host system is more insecure and that Inkscape could do more evil in that environment than on what will inevitably be a network-connected virtual host just to reduce the level of inconvenience involved.)
Anyway, I think I've made my point, as has everybody else in this discussion, and I just think that we all have different perspectives on the matter.
GNU Guix launches Posted Nov 27, 2012 16:33 UTC (Tue) by pspinler (subscriber, #2922) [Link]
We're also talking about two separate cases here: managing servers, and managing interactive machines (most probably desktops).
Managing servers you typically take a more conservative approach to. I'm more in the server than the desktop profession, but I can see the need to be more permissive with desktops.
With desktops I can see a use for a package manager that allows non-root installations in arbitrary paths, for instance to a network home directory that would then be available in any workstation you logged in at.
Even on (most) desktops, I can see not allowing normal office workers full root on the machines. However, there would likely need to be exceptions for certain classes of users -- basically people doing experimental stuff with their desktops. I'd perhaps setup an automated request mechanism for doling that out, so a) I'd have a record of who did it, and b) Id' have at least a chance to talk to the users and see what they're doing, and if they really actually need root, or could do with something else.
-- Pat
GNU Guix launches Posted Nov 27, 2012 18:21 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> Even on (most) desktops, I can see not allowing normal office workers full root on the machines.
what's the practical difference on a desktop machine between giving the user of the machine root (or sudo style package manager access like Ubuntu does) and allowing them to install arbitrary packages as "non-root installations in arbitrary paths"?
It seems to me that the latter is much more complicated (where did this user install this package...)
GNU Guix launches Posted Nov 28, 2012 1:12 UTC (Wed) by pspinler (subscriber, #2922) [Link] what's the practical difference on a desktop machine between giving the user of the machine root (or sudo style package manager access like Ubuntu does) and allowing them to install arbitrary packages as "non-root installations in arbitrary paths"? Lots. For instance:
Anyway, point is, there's lots and lots of administrative advantages to limiting user customizations to limited areas and to stuff that requires no privs. Heck, I do this on my own workstation where I do have full privs. -- Pat
GNU Guix launches Posted Nov 27, 2012 16:47 UTC (Tue) by pspinler (subscriber, #2922) [Link] one other thought I'm not advocating that "the dogs run free". The dogs do run free, however, when technical measures to achieve their goals have been exhausted and they adopt social or political measures to achieve them in another way. I think this logic is faulty. To use an analogy "they're going to break security anyway, so why do XXXXX ...". The point isn't to be perfect, you can't ever be. The point is to put layers in place, each of which adds something toward the final goal. This applies to procedures and people as much as to systems and security. So, if, at a corporate level, I want people to comply with certain policies to protect what the company sees as its best interest, then yes, one layer will be technical restrictions of various sorts. Other layers will include policy manuals and websites, required annual training, easy contact points to the sysadmins and policy makers, scanning software, proxies and filtering software, and etc. Sure, people will still work around that, but with stuff like this in place it makes these people think about it, and hopefully brings what they're doing to other people's attention. This is a good thing: it might mean that their solution gets adopted, that procedures get changed, or that an actual stupid thing gets squashed. To use your example, "Oh, Janet installed inkscape! Hmmm ... do people need to be creating SVG's? Maybe we need to look at a wider solution for that. Oh, Fred installed a web server, and look, the logs show a bunch of external hits, uh oh, we need to squash that ... My personal philosophy: people doing stuff isn't necessarily good or bad, but people doing stuff in isolation is most definitely bad. Corollary: people are lazy, and if they don't have to do something (like, say, tell someone else and document it), they won't. And yes, I'm like this, too. :-) -- Pat
GNU Guix launches Posted Nov 27, 2012 1:35 UTC (Tue) by pspinler (subscriber, #2922) [Link] I'm not really arguing against systems administration policies, but it really baffles me that instead of entertaining and encouraging workable compromises and perhaps loosening the leash on captive users, organisations and developers would rather keep the leash as tight as possible even though history shows that the leash will break as a result. The issue is what management is willing to pay for. Sure, I can act as issue catcher and general hand holder, but then that takes a lot more of my time and the ratio of sysadmin to machine goes down. Management looks at that and says "what with all this automation, what's the problem?" Ergo, we took a pretty firm stance what we'd allow users to do on systems we administered, and management, by policy, required that production apps were on systems that were officially administered. Our compromise was that we still gave people sandboxes to play in where they could do anything to the system. We just took a very strict hands off to those sandboxes, and frowned mightily at using free play sandboxes for serious production work. -- Pat
GNU Guix launches Posted Nov 27, 2012 1:55 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
having worked at a company where things have devolved a couple of times into the "no restrictions" mode, you also end up finding that production reliability suffers drastically as well.
everybody thinks that they are above average in their ability to decide what to run, and this gets people in trouble.
Preventing them from installing packages doesn't solve all the problems by any means, but it does put people on notice that they aren't supposed to be doing that.
This sort of problem doesn't scale linearly with the number of users either. If you need one admin to help 5 people, 5 admins can't keep up with 25 people. It seems like they should be able to, but in practice they can't.
If you aren't willing to live with this sort of restriction on your work computer, find a job at another company, and be prepared to do so again in a few years as that company either grows and starts to implement restrictions, or goes the other direction.
Or become valuable enough that they make exceptions to their policies for you, but this takes having a track record of doing things right and not causing problems.
GNU Guix launches Posted Nov 27, 2012 15:35 UTC (Tue) by lambda (subscriber, #40735) [Link] If you don't allow people to install their own packages, they will just download, compile, and install them into their own directory (or run software written in scripting languages that don't require compilation), and now they have an outdated copy sitting in their home directory that's hard to update, and it's hard to find out that they're even doing this without looking. Why is it so threatening for users to be able to run their own software? They will do it anyhow; providing a framework for them to do so, while sharing dependencies, having a central database that the administrator can audit and tell people when they need to upgrade because of security issues (or forcibly upgrade them if need be) seems a lot preferable to having random pieces of software in who knows what state scattered around in home directories. Why is PHP so popular? It's certainly not its technical merits. One reason is that a user can just untar an application in their site directory and it will work; they don't have to ask a sysadmin to install it for them, request that their hosting provider install it and wait 3 months for it to actually happen, or the like. Nowadays environments like Rails are similar; there's a standard interface to the web server, and you can bundle all of your dependencies in with your application (other than the version of Ruby itself), so you can just stick a directory tree in an appropriate place on your server and it will just work. People install their own packages all the time in this manner. Why should this be restricted to web apps written in dodgy languages like PHP (or somewhat less dodgy environments like Ruby on Rails)?
GNU Guix launches Posted Nov 27, 2012 17:49 UTC (Tue) by davidescott (guest, #58580) [Link]
> If you don't allow people to install their own packages, they will just download, compile, and install them into their own directory (or run software written in scripting languages that don't require compilation), and now they have an outdated copy sitting in their home directory that's hard to update, and it's hard to find out that they're even doing this without looking.
In in ideal world: yes that would be better, but you are assuming that all software that might be installed through the package manager is regularly updated. What if the user installs something from a dead or dying project? The package might not be out of date (because no new release is forthcoming), but the sysadmin still needs to know enough about the program to know if it is a security risk.
Requiring explicit permission from root to install anything ensures that anyone who circumvents root's authority to approve/deny software installs is clearly doing something wrong. If its too urgent to bring through normal approval channels and they screw up the install and leave a security whole, then you can fire them. If they aren't confident that the tools they want to install are safe then they can do it the slow way with approved tools.
> Why is it so threatening for users to be able to run their own software? They will do it anyhow
Part of the problem is that you and I are talking about us. We know how to ./configure --prefix=...; make; make install; so WE can circumvent the policy, but WE are also fairly capable of recognizing good safe software from bad unsafe software, WE try to keep track of what we are doing, WE remove stuff we don't need, WE keep our software up to date, and WE appreciate having a tool to automate that process.
I'm not concerned about us, I'm concerned about THEM. The THEM who don't know a phishing scam from a real email, the THEM who think ftp is secure. I don't want THEM installing software. I want THEM to bring a use case forward, and a candidate application for installation so that people like us can guide them in finding the best supported way of accomplishing their goals.
GNU Guix launches Posted Nov 28, 2012 1:00 UTC (Wed) by hummassa (subscriber, #307) [Link]
It's a simple fallacy separating "we" (us?) from "them". We sometimes click on wrong links. We drive to the wrong neighborhood. One who has root can still veto some installed package or upgrade it and force the upgrade to the users' profiles. The facility here is that, instead of downloading a tarball and ./configuring make install, the user apt-gets (nixes, guixes) it from the repository where things are better controlled.
GNU Guix launches Posted Nov 28, 2012 13:47 UTC (Wed) by pboddie (subscriber, #50784) [Link]
You made my point much more concisely than I managed to do. :-)
Again, it's a matter of whether one can concede a degree of control in order to maintain a degree of supervision, or whether people will eventually feel obliged to break out and go to external entities for the goodies, leading to all sorts of recriminations afterwards (especially if something went wrong).
GNU Guix launches Posted Nov 27, 2012 23:54 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] If you don't allow people to install their own packages, they will just download, compile, and install them into their own directory (or run software written in scripting languages that don't require compilation), and now they have an outdated copy sitting in their home directory that's hard to update, and it's hard to find out that they're even doing this without looking. Assuming you have users who are capable of compiling from source or who have scripting languages installed on their machine. And that kind of user is probably capable enough that they ought to be given some kind of control over the software on their system, if for no other reason than that you can't stop them anyway. But those users are not the only kind that sysadmins need to be worried about. Put bluntly, some users really shouldn't be allowed to put software on their own machines. Not every user is capable and trustworthy enough to be given full control over their machine. Some systems contain sensitive information that must be protected from disclosure for legal or contractual reasons, and those machines really should be running only authorized, vetted software. Other machines may be provided in specific places for narrowly tailored purposes, like information kiosks, and should be running only software intended for that purpose. Real world admins need to be able to deal with those kinds of users and situations, and there should be tools that allow them to lock down machines to prevent unauthorized software from being run on them.
|
|||||||||||||