Administrator access: Right or privilege?

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?