If you don’t trust your administrators, you’ve already lost


Occasionally, a customer will ask for a way they can restrict what the administrator can do. The short answer to this is, "Um, no, that's why they're called 'Administrator'." You can try to set up roadblocks, say, ACL files to revoke access to a file you don't want the administrator to read, but the Administrator can always take ownership of the file and read the contents that way. At the end of the day, the Administrator owns the local machine.

Often, people ask this question because they want to grant certain employees selected subsets of the full set of capabilities available to the Administrator. The way to do this is not to make the user an administrator and then try to rope off the parts you don't want them to use. Rather, you take the things that you do want them to be able to do and delegate that permission and only that permission to them (discretionary access control).

For more information, check out this column on trustworthy administrators (based, I am told, on a TechEd presentation) by Steve Riley (and his uncredited co-presenter Jesper Johansson).

Comments (34)
  1. I am always surprised at the high number of people who completely fail to understand basic security principles such as this.  Already I have a client asking me for a way to limit a user while maintaining that user’s sovereignty over the machine (i.e. admin rights).  And that makes about the 9th time this year I have been given such a request.

    James

  2. Stu says:

    Ok then, how do you make a user capable of installing software, while not being able to read other users’ files?

    You can’t. Almost all installers won’t work unless you are a member of the Administrators group.

    [You’re asking for a contradiction. If I can install software, then I can install spyware, and therefore I can read other users’ files. -Raymond]
  3. BryanK says:

    Stu:  Try sudo, and configure /etc/sudoers to allow trusted users to run (with either no password or their password) whatever install command is required, but not allow them to run anything else.

    Oh, wait…  ;-)

    (Actually, I wonder if anyone has ported sudo to Windows, or written something that works just like it but that runs on Windows.  Hmm.)

  4. Puckdropper says:

    BryanK,

    There’s "Run as" which you get by right-clicking on an executable.

  5. mjb says:

    sudo has existed for windows for a long time. you can log in as… (user) for any app desire. That’s what the secondary login service is for

  6. Neal C says:

    "Run as" isn’t nearly the same as sudo, because you need a second account’s full credentials to "run as" something.  Once you give a user that password, they have full access to the machine anyway, because they can just log in as that user, or run anything they want with "run as".  And if you don’t give them that password, then you haven’t actually given the user access to anything, have you?

    sudo, on the other hand, doesn’t need another account’s password.  Instead, you get to define a list of commands that users can run with administrative rights, under their own credentials.  This means access can be given, changed, and revoked without having to change anyone’s password, and without having to maintain more than a 1:1 ratio of accounts:users.

  7. Hexatron says:

    Run As fails for at least some ‘complex’ installations (installer calls installer) anyway.  

    Or perhaps this is a kind of security.

  8. Lame Programmer says:

    The weakness of sudo is the "approved" programs must also be security concious and robust.

    How many idiots assume that if you can look at the Security event log, you must be an Administrator?

    That assumption is wrong if log viewing was done with sudo.

    How many non-suid programs have exploitable bugs that are harmless if run by root – because you ARE root – but could be exploited by a regular using using sudo, thereby gaining root privs?

    I like sudo. I just don’t trust software.

  9. Gabe says:

    The problem with sudo is that it requires specific commands. How do I know in advance what command is going to be used to install the software that somebody’s going to need? And what’s to say that they don’t have the "evil" version of that command that installs spyware instead of what they’re supposed to have?

    The only way to keep admins from accessing data they’re not allowed to see is to encrypt it.

  10. Rhomboid says:

    I read somewhere (might have been Jesper’s blog, might have been here, I can’t recall) the slogan "Power Users are just users that have not made themselves Administrators yet."  Or in other words, don’t try to make untrusted users Power Users to let them do certain tasks, instead do what Raymond said above.

  11. Stu says:

    If they can access the machines’ network port, the even apt-get can be subverted.

  12. vince says:

    If they can access the machines’
    > network port, the even apt-get can be > subverted.

    True, if they have physical access to the machine, then you’ve already lost.

    [Physical access to the target machine itself is not necessary. You just need access to the network cable anywhere between the target machine and the Debian server. That’s what makes it a little more scary. I hope the apt packages are digitally signed or checksummed or otherwise resistant to tampering. -Raymond]
  13. Stu says:

    I hope the apt packages are digitally signed or

    >checksummed or otherwise resistant to tampering.

    The official repositories yes, but signitures must be installed manually, meaning that sysadmins might not bother for any third-party repos that they add.

    Also, some version/configurations of apt-get only issue a warning when their is a signiture problem, which an inexperianced or not-paying-full-attention sysadmin might ignore.

  14. Kevin says:

    Asking for restrictions on admin power isn’t new – that’s the whole point of DRM, intellectual property protection, anti-cheat, and so on.

    There are plenty of examples, Microsoft and everywhere alkie, that implement "how do I prevent the owner of a computer from using a debugger" or whatever.

  15. Lame programmer says:

    apt-get accepts "-c" which tells it which config file to use. The config file can specify the HTTP proxy. Point the proxy at localhost, run server to serve up a package that overwrites arbitary files on the system.

    Toast. And you didn’t even need to cut the Ethernet.

    sudo keeps honest people honest and prevents stupid mistakes. sudoers are just power users who haven’t made themselves root yet. :=)

    PS Raymond, I routinely try to install software as a limited user. The software – er, spyware – will work for me but if perms are correct and there aren’t any cracks in Windows, then the spyware will only be able to read MY files. Not anyone elses on the computer.

    Most software houses just don’t understand the per-user concept.

  16. Dean Harding says:

    PS Raymond, I routinely try to install software as a limited user.

    It’s "supposed" to work – there’s nothing inherently "admin-y" about installing software PER-SE. As long as you install it into your own profile folder, and don’t try to install it for all users.

    The problem is that many installers simply refuse to run if you’re not an administrator, or they try to write to HKLM or C:Program Files, and you’ve got way to stop them.

  17. BryanK says:

    Exactly as Neal C just said — sudo doesn’t have to ask you for the administrator’s password (but runas does).  Sudo can be configured to either ask you for your own password, or no password at all.  Or different settings depending on what command you’re running.

    (And "sudo setup best practices" obviously include only setting this up for a small number of specific commands, excluding anything that will give the user a (root) shell.)

    However, reading Raymond’s response to Stu, I’d have to agree.  If you’re allowed to install anything, you can (very likely) install a kernel-mode driver, such as a screen-scraper or a keylogger.  It may be possible to make changes that would limit this capability (and maybe not), but AFAIK nothing exists today in Windows to do that.  So Raymond’s right: even a sudo equivalent wouldn’t help with that.

    (In fact, even on a system that has sudo, it *may* be possible to install a spyware-type program.  Using Debian as an example (just because I know it fairly well), say you allow "sudo apt-get install", and only that, for a certain user.  If that user can find a package in one of the package repositories that are listed in apt-get’s sources.list file, they would be able to install that package.  Of course hopefully Debian wouldn’t include a spyware package in their official package repos, but I wouldn’t want to bet on that being the *only* line of defense, either.)

  18. BryanK says:

    > The problem with sudo is that it requires specific commands.

    Actually, it doesn’t.  You can allow a user access to anything if you want, but then you’ve basically given them root.  (That’s why the "best practices" are to limit by command.  But it’s not a requirement of using the program.)

    Even so, see below.

    > How do I know in advance what command is going to be used to install the software that somebody’s going to need?

    It’ll be "apt-get install <some-package-name>" on Debian, preferably with no other arguments.  (Or possibly "dpkg -i <blah>.deb", but that bypasses the sources.list check, and — IMO anyway — should require root, not just sudo privileges.  Same with "make install".  For that matter, same with anything else that bypasses the dpkg database.  Actually, there’s not that much that *isn’t* available in one official Debian repository or another, so this shouldn’t come up all that often either.)

    Sudo can filter on more than just which program they’re running; it can filter on all the arguments they give to it.

    > And what’s to say that they don’t have the "evil" version of that command that installs spyware instead of what they’re supposed to have?

    They don’t have write permission to /bin or /usr/bin, so they can’t have replaced the apt-get executable.  (Or whichever executable your distro uses to install packages.)  Now, they might be able to install a different apt package that overwrites the binary, then use that to install something else.  Hmm.  But again, this would require that either someone put the evil package’s repository into sources.list, or the evil package got into Debian’s official sources.list.

    Still probably unlikely, but it’s still a single line of defense.  Sudo’s not a panacea, I guess I’m saying, but it is helpful.

  19. Anonymous says:

    Err, what happens if you don’t trust your Administration? For instance, shouldn’t an OS come with checks and balances, so that there are two kinds of Administrators, one (called the Executive) who can do all the usual Admin things, EXCEPT for administering auditing. The other administrator can audit what the Executive has done. That way, if the Executive stores 14 illegal files in his Gitmo folder, the auditor is able to catch him out.

  20. Norman Diamond says:

    but the Administrator can always take

    > ownership of the file and read the contents

    > that way

    That’s only if the Administrator can access the file.  There are still famous occurences where Administrator can’t delete a file because some process (in these cases not usually the System process) has the file locked.  There are still famous occurences where Administrator can’t kill a process (where Task Manager goes through the motions over and over but with no effect).  Just figure out how to cause these situations deliberately and combine the two.

    If Administrator has physical access and can boot the machine to safe mode (or boot a Knoppix DVD) then you’ve still lost.  You need to encrypt your secrets in such a case.

    However, for practical purposes, it might still be meaningful to set roadblocks that slow down the Administrator.  For comparison, untrusted government agents can break into your house at any time, so it’s useless to lock your house, yet you often lock your house anyway.  Even some of my in-laws, once they could afford to build a kind of house which could have doors that could be locked, they started locking their house.

    Thursday, September 21, 2006 3:02 PM by Rhomboid

    > I read […] “Power Users are just users that

    > have not made themselves Administrators yet.”

    True, just like someone who’s a member of the wheel group and who knows root’s password but who hasn’t typed an su command during this session is an administrator who hasn’t made herself an administrator yet.  Anyone who ever noticed that they had to correct one of their own mistakes will want to help themselves out by having the power to become administrator when necessary but not have that power enabled most of the time.

    [I thought we went through this already. The process really is dead, but some buggy kernel component is not cleaning up. It’s a bug, not a feature. -Raymond]
  21. required says:

    Raymond> You just need access to the network cable anywhere between the target machine and the Debian server

    How does Windows Update get around this problem?

  22. Dean Harding says:

    How does Windows Update get around this problem?

    Updates are digitally signed.

  23. sandman says:

    but the Administrator can always take

    > ownership of the file and read the contents

    > that way .

    Doesn’t this what NTFS encryption provide a way to limit the usefulness of this , is for as your key recovery agents/users can be an different set of people from your administrators.

    But in general I agree with Raymond, trying to limit the admin access is foolish, any likely to only lead to trouble. Consider the case of a possibly corrupted file in  a less techno savvy user profile, which is the administrator si restrited from access but is prevent the user logon in some way.

  24. Michiel says:

    [You’re asking for a contradiction. If I can install software, then I can install spyware, and therefore I can read other users’ files. -Raymond]

    I’d be surprised. If a user can install software, he can install spyware that reads his files. Not other users’ files, or the administrators files.

    If you can bypass Read ACLs in spyware, you can almost certainly also bypass Write ACLs, overwrite Notepad.exe with a Trojan and gain admin rights that way. Write permissions are not magically stronger than read permissions. ACLs either work or they don’t. They’re not advisory like the read-only attribute.

    The problem indicated is real. Too many installers require admin access.

    [Now you’re taking the problem out of context. If the program installed per-user then this whole topic wouldn’t exist since there would be no need for these imaginary “Administrators with limited powers”. Clearly the context is “Programs that require administrative privileges to install”. -Raymond]
  25. Amon Houndsbreath says:

    "For comparison, untrusted government agents can break into your house at any time, so it’s useless to lock your house, yet you often lock your house anyway."

    I guess the government is a sort of administrator of the country, i.e. it must be considered to be trusted. E.g. there are lots of things that you might thing the government should be prevented from doing, since if extremists took over the government they may abuse those powers. The problem is that if extremists take over the government they could change the laws to allow whatever they wanted.

    So sometimes you’re better off allowing a government, particularly one you trust, to do things that seem illiberal but help to minimise the chances that extremists can take over.

    Certainly, if you look at the UK in WWII, the coalition government did highly illiberal things like suspending elections, detaining pro German politicians for the duration of the war to  being replaced by an overtly totalitarian Nazi puppet regime. Once the war was over, the coalition split and the Prime Minister’s party lost the election. In many ways, it was a dictatorship in the Roman sense.

    Of course, you have to be careful of the situatuon where extremists win an election and use this argument to set up one kind of totalitarian regime whilst claiming to be defending the status quo against another. On the other hand the US constitution should theoretically protect against this sort of possibility.

  26. BryanK says:

    > apt-get accepts "-c"

    But sudoers doesn’t have to allow "apt-get -c anything" to execute.  Again, it can check *more* than just the command that’s being run; when using sudo, you give sudo the entire command you want it to run, and it will check all arguments.

    As for apt’s repository:  The packages are all hashed (with either MD5 or SHA-1, can’t remember which).  Then the list of hashes is signed by the official GnuPG-key-of-the-year.  So assuming your gpg binary is OK, and assuming you’ve installed the key-of-the-year (this is a problem, as Stu points out; IMO it should be more automatic than it is, but others may not agree), you can verify that the packages have not been tampered with between the server and you.

    I believe that current Debian installs will add the current year’s signing key automatically (or at least, the box we have here did that), but that’s still only good until the end of the current year.

    (Of course, if someone *wants* to install spyware, then they could just hit "Y" to the "this package is failing verification" message, too.  If that’s still an option, anyway.)

  27. BryanK says:

    Thinking about this some more, encryption isn’t the answer to preventing administrators from seeing your files’ contents either.  At least not NTFS encryption (aka EFS), and not CryptProtectData() either.

    EFS and CryptProtectData() are based on your user password (basically; I’m omitting a bunch of details here).  If you’re logged on as you, you get access to your EFS files, and you can CryptUnprotectData() anything that you’ve CryptProtectData()ed in the past.

    However, your admin can do all kinds of things to figure out your password — my favorite is installing a password-change hook DLL on the local DC that writes the new password out somewhere.  (We actually do that here, both because people keep forgetting their passwords, and because we sometimes need to log on as them — or unlock their screen without forcibly terminating all their programs — when they’re not here.  The target directory has *very* restrictive ACLs on it, of course, and of course it’s a local directory, so the information isn’t floating out over the network.)  And if your admin has your password, they can log on as you and see your encrypted files (or CryptUnprotectData() your data).

    The only way to stop this is to use an encryption program (or function) that isn’t based on your user credentials, because the admin has those.  Also, you’ll have to make it require you to type in some passphrase value before it’ll decrypt anything.  Then don’t use a passphrase that’s the same as your password, and don’t write it down anywhere.

    Certainly possible, but not as simple as some are claiming either.

    (And herein, I am assuming that "administrator" means "domain admin, with admin access to the DC".  This is valid for any machine on a domain.  It’s not valid for any machine in a home environment, but in a non-domain setup, the administrator can just install their password-change filter DLL on the local machine instead of the DC.  The only setup that EFS *might* help with is against a local admin who is *not* a domain admin.  Maybe.)

  28. Ulirc says:

    yikes, did someone just use a blog entry about computer security management to make a political statement?  I think I’ll go take a shower.

  29. dilemma says:

    Many windows program require the user to be "administrator". How do I solve this without allowing them to do harmful things?

  30. BryanK says:

    dilemma — You can’t.

    You can try complaining to the author of the software, but that rarely does any good.

  31. Mary says:

    Good design!

  32. Ivan says:

    Well done!

  33. Patrick says:

    Nice site!

  34. Chris_R says:

    So why does Vista have UAC then?

    [Type <site:microsoft.com Vista UAC> into your favorite search engine. One of the hits is this page. I have no idea what your question has to do with one administrator trying to stop another administrator. -Raymond]

Comments are closed.

Skip to main content