Administrator access: Right or privilege?
A cautionary tale
Workshop Here’s a story, which may or may not be true. A long, long time ago, a UNIX sys admin was having a problem with some of his users, who thought it was really funny to download explicit photos from the then still-fledgling Internet and pop them up on other people’s screens.
It wasn’t funny of course, but when the administrator deleted the photos, the users simply found clever ways of hiding them – for example creating directories called ‘ .’ (space-dot) or ‘. ‘ (dot-space) so they wouldn’t appear obvious on a manual search. When the administrator started to get wise to this, the users created directory paths such as ‘. / .’ and so on. How very cunning.
It wasn’t long before the exasperated administrator was writing scripts to delete such directories. But there is a twist to this tale. Not only had the file servers been set up (using ‘.rhosts’ etc) to allow privileged commands to be executed by remote machines, for example from the administrator’s own workstation, but also, and unfortunately, the scripts had been written without taking into account that command lines would be modified when they were run remotely.
And how. Quite simply, the command line ‘find –R “. / .” –rm –f’ was translated into ‘find –R . / . –rm –f’ when remotely executed, stripping off the quotes. For you normal people, what that means is that the ‘find’ command would first look for the current directory and delete it; then it would look for the top-level directory and delete that as well; then it would look for the current directory again and try to delete it – but of course it would fail, leaving a string of ‘directory not found’ errors.
You’ll no doubt be pleased to know that the administrator had been taking regular backups, so little information was lost. But this cautionary tale does beg a number of questions. Top of the list is one for administrators worldwide – is there such a thing as too much power?
I know I’m being a party pooper, just as I know there’s all kinds of reasons why you do need super-user access. But isn’t it a bit of a blunt weapon to say either you are treated as a general user with limited access rights, or you get the keys to the electronic city in its entirety?
In this (ahem) hypothetical example, the problem could be said to have been exacerbated by three factors: a lack of training in terms of what the commands would do; inadequate testing when it came to running a pretty high-risk script; and a poorly configured environment which was set up for ease of maintenance, at the expense of risk.
All of these are solvable problems, at least for the future. At least, they would be, if it weren’t for the fact we live in the real world. IT environments can be complex, fragmented and full of historical baggage that doesn’t fit with ideas of ‘doing the right thing’. The result – increased dependency on administrators, both in terms of what they hold in their heads about how things really work, and their reach and ability to fix things wherever they may be going wrong.
In other words, removing rights for administrators may seem like a good idea in principle – but in practice, it would be impossible to implement in many organisations without limiting the ability of administrators to do their jobs. This doesn’t rule out working in a reduced-access mode of course, where administrators log in with minimum access rights for routine work and only use additional privileges when required (eg by using the ‘su’ command in UNIX/Linux). But that wouldn’t have prevented the above scenario.
Perhaps, then, it would be a good idea to be more careful about who we have as administrators in the first place, for example through pre-vetting and subsequent training and certification. Training should be relatively easy to enact – apart from the fact that training budgets are the first things to go when the going gets tough.
And as for vetting – this is more of a human resources issue, in that IT management can’t really be expected to conduct background checks on its staff. It wouldn’t be appropriate even if they knew what they were looking for, and of course, our increased reliance on contractors and external suppliers makes things more complicated still.
Perhaps matters will be taken out of everyone’s hands through the encroaching demands of compliance. Already, the likes of security standards ISO 27001 and PCI DSS require a level of vetting aimed at protecting sensitive data such as customer records. And to be fair, the UK data protection act does have an implicit requirement on staff managing information.
But for reasons already given, not least the complexity of IT today, it is unlikely that regulation will ever be sufficient to guard against examples such as this one. Which means that administrator access privileges look set to remain a thorny topic.
Should privileged access be kept for all but a highly trusted core of administrators, or would this cause the whole of IT to grind to a halt? If you do have any counterpoints, or indeed anecdotes, we’re all ears.
COMMENTS
Oh how easily...
...everybody forgets the other angles of approach to this sort of problem.
Whats wrong, for instance, with the human angle, or at least the HR angle. Sod all these scripts, and processes, when you simply inform your staff that disciplinary action may be taken against them if regularly found to be carrying out stupid, non work related, or downright totally NSFW actions. At the very least they can be reported to their line manager.
Thats the first thing that sprang to mind about the story at the top of the article, so why was a solely technical or operational procedural solution employed when you could simply approach them about it (talk about matching the 'IT crowd' stereotypes!). Are theses people who look after data not expected to be responsible, adult individuals, after all??
Select * From Users Where Clue > 0 ?
Bit of a geeky responce i know but we have this kinda thing where i work.
1. Tell HR about the perp, if he/she is a repeat offender show him/her the door.
2. Gimp their login so they cant access the internet/set up a Squid server and block access to sites.
3. Employ Admins that think befor they decided to run truncate scripts.
Admins need to be super users to sort out the idiots :D
Paris because she would be an awsome super admin!
Another view.
I'm sure I don't agree. Yes, UNIX is nearly 40. Yes, there are uglies in the way that you administer it, and also in the crude security model, but what are you holding up as a shining example of something better? I've seen administration tools that looked prettier, but they generally end up being so locked down as to be largely useless, or so complex to set up (I'm thinking CDE with it's cross-system authentication here) that you have to be a real propeller-head in order to get it working.
UNIX has seen off so many alternatives, and still lives on, while everyone else learns the hard way over-and-over again that hidden complexity leads to difficult-to-manage systems. The more layers of 'gloss' you add to 'simplify' administration, the more problems you build in when it goes wrong. (I'm coining Gathercole's Law as being "Apparent simplicity causes hidden complexity" )
If you need something better for users, then Gnome and KDE will provide you something just as pretty as other OS's (and a product from the 1980's called Looking Glass, which predates usable Windows systems also springs to mind), so the so called unfriendly* command line is not necessary for those who don't need it. Sometimes you ought to look and see what it is possible to do with the simplicity of the shell command line as practiced by real power users. It may not LOOK pretty, but it is elegant and functional.
I have frequently stunned managers and younger colleges by piping together several small tools with simple stream processors (think awk or sed) to achieve in a matter of minutes things that they were prepared to commit days of work to do. This is especially true in clusters or networks of near homogeneous systems, which is where UNIX excels.
It is a testament to the original design criteria of the shell and the base UNIX command set that most of the commands I use on a daily basis came out of Bell Labs. Version 7 UNIX, dated 1976. This has been augmented over the years, but you would still recognize that system as UNIX today. This may mark me out as a dinosaur, but hey! I'm still working, and I appear to have the respect of my peers who keep asking me to do things they cannot work out an easy way to do.
In my view, what is wrong with the example quoted WAS a UNIX design flaw, that of allowing spaces in filenames (space should have been made a banned character), but the very flexibility of the shell and filesystem interface allowing almost any character in filenames has allowed multi-byte character set languages to be integrated into UNIX with comparatively little effort.
(*) Often, the reason why it was seen as unfriendly is that most users were too lazy to learn the dozen or so commands that were the core set needed to do their job. They got frightened because two-and-three letter abbreviations were not close enough to english (e.g. cat - catinate is and English word, but one many people are not familiar with). This was a matter of perception and training. Possibly the only OS that got it right on the command line was VAX/VMS with DCL, which allowed you to use full command names, or any unique abbreviation. But this made the command processor one of the largest tasks in the system and was still not English!
P.S. I'm really not looking forward to a time when role-based security (which is already present in the few genetic UNICES left and also Linux since the 2.6 Kernel) becomes the norm. I predict that we will see stories of administrators who don't fully understand the importance of local privileged accounts locking themselves out of their systems when the LDAP or ActiveX directory servers cannot be contacted to authenticate them to fix the problem.
Admins Are Not The Problem
...Rather it is "normal" users doing stupid things like clicking on attachments or divulging passwords in a "social engineering" attack.
The data center seems to be quite secure as compared to individual PCs, because most admins are well-aware of risks and the proper countermeasures. Also, they don't surf the internet with their mainframe or Unix server and they certainly won't install a random download from the internet for their machines. PC users *do* the last two things.
An article about "Securing a Corporate PC" would have been much more interesting. Questions like
* is a Virus scanner effective and required ?
* should a PC processing sensitive data be conntected to the internet ?
* should there be a "social PC" in every office ?
* how can I contain the threat-vectors comming in through common office programs ?
* what can the firewall do for security ?
* what can't the firewall do for security ?
* should companies use Managed Security Providers or do security themselves ?
would be interesting.
With power goes responsibility...
...and in this case, the sysadmin's first and greatest responsibility was to know what he was doing. If you aren't competent to write scripts that will do exactly what you intend - no more and no less - then you certainly are not fit to be given root access.
