The God User
Perimeter recently had Jim Cranston come in to review the IT department and how we do things. One of the things he asked is why we don’t allow administrative access on our desktops. All of the users he talked to want administrative access over their desktop and have complained that they don’t have it. I obviously hadn’t prepared for questions like this, having not been told what we’d be talking about, so I came up with the usual reasons: with users running as admin access viruses propagate quicker, users can install unlicensed software which we may have to prove to software vendors wasn’t installed by PI, it creates a non-standard environment which is harder to troubleshoot, provides an easy way for the user to cause bad things (ie. delete command.com or otherwise break the system) to happen, and security concerns such as keyloggers when sharing the machine, among many other concerns. He responded with “Every desktop is assigned to a user so there shouldn’t be any security concerns.” This made it clear he doesn’t have a good handle on PI, as we hotel our desk space when researchers visit other institutions or go on sabatical and thus the machines in people’s offices are actually shared machines.
This got me thinking about what would be involved in granting admin access to users on their desktops. You certainly could just flick the switch and have chaos, but that wouldn’t be very smart. I’m going to create two classifications, Windows and Linux, as they both have their own quirks.
- Viruses are rampant on Windows platforms. When users are browsing the web and opening email attachments as an Administrator it is much easier for viruses, trojans, etc to install on the machine.
- NFS home directories in Linux would have to go. I don’t see a big problem with local home directories aside from it won’t be backed up, which has potential for huge issues. Other authenticated protocols (AFS, NFS4, CIFS), most of which the NAS doesn’t support, could be investigated for network-based home directories.
- Non-standard linux is hard to troubleshoot given the plethora of ways of doing things in Linux.
- It is debatable whether fire fighting viruses, non-standard environments and user mishaps which breaks the machine would generate more or less help requests. More staffing may be necessary.
- Hoteling of desk space would have to stop. As administrator, the user can install keyloggers and other monitoring tools to catch passwords and other information of the next unsuspecting user. It’s not clear this can happen until the building expansion is complete.
- Machines would have to be imaged when re-deployed (see point above for reason), which involves more staff time.
- Machine maintenance – we would be entrusting the user to do system and application updates and/or not to break or remove our automation to do these tasks
- May wish to have users sign policy stating they will abide by legal constraints (no unlicensed software)
- Machines (according to policy) last 4-5 years, postdocs last 3 years. Since there is not a one-to-one mapping of new machines to new postdocs, some of the machines will have to be upgraded before the postdoc leaves. This can cause headaches for IT and the postdoc if the postdoc has made lots of changes to the system.
Most things considered, I don’t see any show stoppers for giving postdocs and faculty administrative access on their desk machine, aside from the hoteling of desk space issue. The above would have to be addressed. It’s not clear there exists enough staff for a change with one help desk and two sysadmins. Such a change takes time to implement and there isn’t a lot of spare time available. I can’t ever see this change for users that are at PI on a temporary basis and thus hotelling desk space is a necessity (eg. visitors, associates, affiliates, etc.) as that is a definite show-stopper in my opinion.